From patchwork Thu Jul 1 22:18:12 2010 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Mark Lord X-Patchwork-Id: 57604 X-Patchwork-Delegate: davem@davemloft.net Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by ozlabs.org (Postfix) with ESMTP id 827C21007D1 for ; Fri, 2 Jul 2010 08:19:24 +1000 (EST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1759792Ab0GAWSU (ORCPT ); Thu, 1 Jul 2010 18:18:20 -0400 Received: from ironport2-out.teksavvy.com ([206.248.154.181]:13387 "EHLO ironport2-out.pppoe.ca" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1759815Ab0GAWSP (ORCPT ); Thu, 1 Jul 2010 18:18:15 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApIBAG+xLExLd/sX/2dsb2JhbAAHgxbLcpEQhDNyBA X-IronPort-AV: E=Sophos;i="4.53,522,1272859200"; d="scan'208";a="69316364" Received: from rtr.ca (HELO [10.0.0.6]) ([75.119.251.23]) by ironport2-out.pppoe.ca with ESMTP/TLS/DHE-RSA-CAMELLIA256-SHA; 01 Jul 2010 18:18:13 -0400 Message-ID: <4C2D1424.4050407@teksavvy.com> Date: Thu, 01 Jul 2010 18:18:12 -0400 From: Mark Lord User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-GB; rv:1.9.1.10) Gecko/20100512 Thunderbird/3.0.5 MIME-Version: 1.0 To: Jeff Garzik CC: IDE/ATA development list , Tejun Heo Subject: [PATCH 3/3] libata: reduce blacklist size even more (v2) References: <4C2CB497.3000701@teksavvy.com> <4C2CEB70.3090209@pobox.com> <4C2D0F05.6040706@teksavvy.com> <4C2D13AE.6090701@teksavvy.com> <4C2D13F1.9030408@teksavvy.com> In-Reply-To: <4C2D13F1.9030408@teksavvy.com> Sender: linux-ide-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-ide@vger.kernel.org Take further advantage of the new glob_match() function to reduce the blacklist size. There are even more savings possible, but how far do we want to go with this? Signed-off-by: Mark Lord --- (re-diff'd against latest -git, and also attached to bypass mailer issues) Take further advantage of the new glob_match() function to reduce the blacklist size. There are even more savings possible, but how far do we want to go with this? Signed-off-by: Mark Lord --- linux-2.6.35-rc3/drivers/ata/libata-core.c 2010-07-01 18:12:46.488008047 -0400 +++ linux/drivers/ata/libata-core.c 2010-07-01 18:12:52.471339139 -0400 @@ -4167,15 +4167,13 @@ { "WDC AC23200L", "21.10N21", ATA_HORKAGE_NODMA }, { "Compaq CRD-8241B", NULL, ATA_HORKAGE_NODMA }, { "CRD-8400B", NULL, ATA_HORKAGE_NODMA }, - { "CRD-8480B", NULL, ATA_HORKAGE_NODMA }, - { "CRD-8482B", NULL, ATA_HORKAGE_NODMA }, + { "CRD-848[02]B", NULL, ATA_HORKAGE_NODMA }, { "CRD-84", NULL, ATA_HORKAGE_NODMA }, { "SanDisk SDP3B", NULL, ATA_HORKAGE_NODMA }, { "SanDisk SDP3B-64", NULL, ATA_HORKAGE_NODMA }, { "SANYO CD-ROM CRD", NULL, ATA_HORKAGE_NODMA }, { "HITACHI CDR-8", NULL, ATA_HORKAGE_NODMA }, - { "HITACHI CDR-8335", NULL, ATA_HORKAGE_NODMA }, - { "HITACHI CDR-8435", NULL, ATA_HORKAGE_NODMA }, + { "HITACHI CDR-8[34]35",NULL, ATA_HORKAGE_NODMA }, { "Toshiba CD-ROM XM-6202B", NULL, ATA_HORKAGE_NODMA }, { "TOSHIBA CD-ROM XM-1702BC", NULL, ATA_HORKAGE_NODMA }, { "CD-532E-A", NULL, ATA_HORKAGE_NODMA }, @@ -4255,12 +4253,7 @@ /* Devices which get the IVB wrong */ { "QUANTUM FIREBALLlct10 05", "A03.0900", ATA_HORKAGE_IVB, }, /* Maybe we should just blacklist TSSTcorp... */ - { "TSSTcorp CDDVDW SH-S202H", "SB00", ATA_HORKAGE_IVB, }, - { "TSSTcorp CDDVDW SH-S202H", "SB01", ATA_HORKAGE_IVB, }, - { "TSSTcorp CDDVDW SH-S202J", "SB00", ATA_HORKAGE_IVB, }, - { "TSSTcorp CDDVDW SH-S202J", "SB01", ATA_HORKAGE_IVB, }, - { "TSSTcorp CDDVDW SH-S202N", "SB00", ATA_HORKAGE_IVB, }, - { "TSSTcorp CDDVDW SH-S202N", "SB01", ATA_HORKAGE_IVB, }, + { "TSSTcorp CDDVDW SH-S202[HJN]", "SB0[01]", ATA_HORKAGE_IVB, }, /* Devices that do not need bridging limits applied */ { "MTRON MSP-SATA*", NULL, ATA_HORKAGE_BRIDGE_OK, },