Messages in this thread | | | Date | Wed, 13 Jan 2010 08:59:31 -0600 | From | David Milburn <> | Subject | Re: [PATCH 2.6.32.3] ahci: AHCI and RAID mode SATA patch for Intel Cougar Point DeviceIDs |
| |
Jeff Garzik wrote: > On 01/12/2010 11:40 PM, Robert Hancock wrote: >> On 01/12/2010 07:00 PM, Seth Heasley wrote: >>> This patch adds the Intel Cougar Point (PCH) SATA AHCI and RAID >>> Controller DeviceIDs. >>> >>> Signed-off-by: Seth Heasley<seth.heasley@intel.com> >>> >>> --- linux-2.6.32.3/drivers/ata/ahci.c.orig 2010-01-06 >>> 15:07:45.000000000 -0800 >>> +++ linux-2.6.32.3/drivers/ata/ahci.c 2010-01-07 13:55:23.000000000 >>> -0800 >>> @@ -560,6 +560,12 @@ >>> { PCI_VDEVICE(INTEL, 0x3b2b), board_ahci }, /* PCH RAID */ >>> { PCI_VDEVICE(INTEL, 0x3b2c), board_ahci }, /* PCH RAID */ >>> { PCI_VDEVICE(INTEL, 0x3b2f), board_ahci }, /* PCH AHCI */ >>> + { PCI_VDEVICE(INTEL, 0x1c02), board_ahci }, /* CPT AHCI */ >>> + { PCI_VDEVICE(INTEL, 0x1c03), board_ahci }, /* CPT AHCI */ >>> + { PCI_VDEVICE(INTEL, 0x1c04), board_ahci }, /* CPT RAID */ >>> + { PCI_VDEVICE(INTEL, 0x1c05), board_ahci }, /* CPT RAID */ >>> + { PCI_VDEVICE(INTEL, 0x1c06), board_ahci }, /* CPT RAID */ >>> + { PCI_VDEVICE(INTEL, 0x1c07), board_ahci }, /* CPT RAID */ >>> >>> /* 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, >> >> The RAID mode entries would be needed if the device indicates RAID class >> in that mode, but in plain AHCI mode it should indicate SATA AHCI class >> which will get picked up by this catch-all so those entries shouldn't be >> needed: >> >> /* 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 }, >> >> Likely a lot of the existing specific PCI IDs could be removed from the >> driver because of this (many likely predate the addition of the >> class-based catch-all). The only reason to need a specific entry if the >> device uses AHCI class is if it needs special handling or workarounds, >> which isn't the case here. > > 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.
It is helpful for the specific device IDs to show up in "modinfo ahci" and modules.pcimap.
David
> > Comments welcome, though... > > Jeff > > > > > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/
| |