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