[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <m3my0i6nou.fsf@intrepid.localdomain>
Date: Wed, 13 Jan 2010 16:15:29 +0100
From: Krzysztof Halasa <khc@...waw.pl>
To: Jeff Garzik <jgarzik@...ox.com>
Cc: Robert Hancock <hancockrwd@...il.com>,
Seth Heasley <seth.heasley@...el.com>,
linux-ide@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2.6.32.3] ahci: AHCI and RAID mode SATA patch for Intel Cougar Point DeviceIDs
Jeff Garzik <jgarzik@...ox.com> writes:
> Well, two lines of thinking here:
>
> * some of lines of Intel chips do not separate AHCI into a separate
> PCI ID rather legacy IDE interface. When an AHCI interface exists and
> AHCI/IDE share the same PCI ID, we default to using AHCI. Thus, some
> of those PCI ID matches in ahci.c's PCI table may not get caught by
> the generic PCI class match at the end of the table.
>
> * the cost carrying redundant PCI IDs seems low, harmless, and
> potentially helpful.
Also people may use things like this:
diff --git a/drivers/ata/ahci.c b/drivers/ata/ahci.c
index a3241a1..0616bbb 100644
--- a/drivers/ata/ahci.c
+++ b/drivers/ata/ahci.c
@@ -561,9 +561,11 @@ static const struct pci_device_id ahci_pci_tbl[] = {
{ PCI_VDEVICE(INTEL, 0x3b2c), board_ahci }, /* PCH RAID */
{ PCI_VDEVICE(INTEL, 0x3b2f), board_ahci }, /* PCH AHCI */
+#ifdef DOESNT_WORK_FOR_ME
/* JMicron 360/1/3/5/6, match class to avoid IDE function */
{ PCI_VENDOR_ID_JMICRON, PCI_ANY_ID, PCI_ANY_ID, PCI_ANY_ID,
PCI_CLASS_STORAGE_SATA_AHCI, 0xffffff, board_ahci_ign_iferr },
+#endif
/* ATI */
{ PCI_VDEVICE(ATI, 0x4380), board_ahci_sb600 }, /* ATI SB600 */
@@ -667,9 +669,11 @@ static const struct pci_device_id ahci_pci_tbl[] = {
/* Promise */
{ PCI_VDEVICE(PROMISE, 0x3f20), board_ahci }, /* PDC42819 */
+#ifdef DOESNT_WORK_FOR_ME
/* Generic, PCI class code for AHCI */
{ PCI_ANY_ID, PCI_ANY_ID, PCI_ANY_ID, PCI_ANY_ID,
PCI_CLASS_STORAGE_SATA_AHCI, 0xffffff, board_ahci },
+#endif
{ } /* terminate list */
};
--
Krzysztof Halasa
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists