Alan Cox wrote:
If a driver supports a device with dual interfaces, then it better
reserve both sets of ports to prevent the generic driver from trying to
use them.
That isn't the problem. The generic driver doesn't know if there is
another valid driver for the ports - how can it - and the other driver
may not be loaded first so cannot reserve the ports. If you load the
generic driver last then you should be fine, and the link order for IDE
and libata puts acpi, pci generic and legacy at the end for good reason.
Libata pata_legacy has some smarts in this area but they are only good
for the common cases.
Always loading generic or ata_generic used to be safe. It's still
pretty safe but not as much as before. Nowadays, there are good number
of controllers which have dual interfaces. Usually an ahci interface
and a legacy one but there are other controllers which also implement
dual interface.
Because PCI BARs usually contain IO regions for legacy interface in PCI
BAR 0-4, the native driver can work it out by claiming all PCI BARs on
attach, which I learned the hard way after seeing the generic driver
borking the native one on certain configurations. The thing I'm worried
about is that there are a lot of vendors making this type of controllers
nowadays and a lot of BIOS implementations for each of them. And of
course each BIOS implementation has its own many ways of configuring the
dual mode (or more thanks to fake RAIDs) controller.
I wouldn't be too surprised if one of those plethora of configurations
gets the compatible IO port and BAR configurations mismatched.
Especially when the controller is put into native mode. It's entirely
possible to leave the compatible IO ports enabled while not setting the
PCI BARs accordingly. Some of them might even think that's better to
prevent IDE drivers from attaching to it.
So, I don't really want to depend on that. I don't know. Do I sound
paranoid?
--
tejun
--
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
