Alan Cox wrote: >> The ACPI interface to use can only be safely determined one way - and >> that is to see what methods the BIOS has attached to the device and use >> those. >> >> Take the ACPI handle, go look for _GTF, _SDD etc and believe the >> firmware. Nothing else works. > > Actually its even worse a mess than I thought 8( > > We have to look at the BIOS method offered and we have to know if we > changed the mode of the controller. > > If the BIOS mode of an IDE controller is SFF and we flip it into AHCI > mode then we can no longer use the BIOS provided methods because they are > the wrong ones. > > For the sane cases (where we don't frob the device) we can ask the BIOS > what methods it has to guess what to use. If we change the mode of the > controller we need to look for methods that match our change, and be > aware we may have totally hosed the ACPI method support by changing the > chip config. > > Bletch, ACPI, its like openprom crossed with european law, a million > times larger than needed, and full of holes. Here are what I've seen till now. * Many older boards only supply IDE style ACPI nodes and don't bother to switch them off when the controller is put into ahci mode (whether it's done by the BIOS itself or by the OS). * Newer ones have both in their SSDTs. Probably selects one or the other according to BIOS setting. I haven't seen them in action and not too familiar with asl so dunno. * Laptops which make heavy use of ATA ACPI features usually locks the controller into single programming mode and supply the matching ACPI hierarchy. So, I think we'll be okay if we follow the spec here. -- tejun - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html