peer chen wrote:
Yes, link - http://lkml.org/lkml/2007/10/8/93 add the AHCI legacy support to sata_nv when IDE/RAID mode been set in SBIOS and Device IDs are not in ahci.c at this moment. To do so, when a new chipset come out and DIDs haven't been submited to LKML,user still can use ahci driver to handle it when setting AHCI mode in BIOS, using sata_nv when setting RAID/IDE in BIOS. For example, ahci driver in Fedora 7 doesn't include the DIDs of MCP78, so if you set the IDE/RAID mode in BIOS, os installation onto SATA drive will fail. But if Fedora 7 include this patch, installation will be successful.
The problem with this change is that sata_nv picks it up through the default entry, and then later on, ahci picks it up as well.
Rather than the confusion of "which driver is the user running on this hardware?" it is easier to take steps to ensure the user is always running in AHCI mode.
Therefore, I think the best idea is to follow the same policy as drivers/net/forcedeth.c (Ayaz @ NVIDIA) and Intel AHCI, and simply provide the individual PCI IDs in advance of product release.
If you wish to avoid this, then take steps to make sure drivers/ata/ahci.c has the appropriate wildcard entry in its pci_device_id table.
Really, look at the sata_nv bug reports that keep popping up. We want to move away from that driver long term, and always drive the SATA interface in AHCI mode.
The proposed sata_nv patch does the opposite -- guarantees we must support the continually problematic legacy IDE interface ad infinitum. Such patches are OK for the test lab, but in this specific case users /suffer/ when not running AHCI mode.
Jeff - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
