Tejun Heo wrote:
Matthew Garrett wrote:
Hi,
We've got an ich6m system (a Toshiba Portege S100). ata_piix attempts
to drive the chipset, but fails - however, it doesn't bail out. As a
result it remains bound to the device and ahci isn't loaded.
I've attached the lspci output for the chipset. A few things to note are:
1) The AHCI BAR is set
2) The SCC register identifies it as an AHCI controller
3) Bits 2 and 0 of the PCS are set, which the spec claims indicates
that the port is to be controlled as an ahci device.
So, my question is effectively: why does ata_piix attempt to disable
ahci rather than simply letting the ahci driver bind? Points (1) and
(2) seem to be checked by the code, but I'm guessing that in the case
of (3) it should just return ENODEV and let ahci be run instead. If
so, should I code up a patch?
I'm not very sure but it might be historical. ahci got implemented
after ata_piix and in the meantime ata_piix must have handled all it
could. Can you verify whether modifying the code to return -ENODEV work
for your machine? If so, that could be the correct solution but I'm a
bit worried because it could change probing order or fail to enable
devices it used to. Maybe we need a hack to return -ENODEV iff ahci is
there to handle the device.
It's definitely historical. I'm pretty frazzled now so I don't
remember. It may be that on ICH6, AHCI mode does not cause the PCI IDs
to change, so driver load order winds up dictating what gets used.
Jeff
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
