On Thu, Mar 29, 2007 at 10:42:03AM +0900, Tejun Heo wrote: > Yeap, I think it's in the right direction but we need to go further. > > * I'm not sure whether the complex walk libata-acpi is doing is justifiable. Yeah, that may well be less than ideal. > * You'll end up doing _STM/_GTM on ahci controller on some BIOSen - 1. > it can be dangerous 2. you might get partial or incorrect mapping - > think about ICH8-split-to-two-PCI-fn-in-piix-mode case. So far I haven't seen any DSDTs that include _GTM and _STM methods for controllers that come up flagged as ahci, though I'm perfectly willing to believe that they're out there... > I think PM functions in libata-eh is better place and you also need to > do _GTF after _GTM during resume. Well, "need" - I haven't actually found hardware that seems upset about the missing _GTF call :) But you're right, it ought to be done. Can you point me at the right bits of the libata-eh code? I was trying to work through it earlier, but keeping track of the conditional paths is a bit tricky. > >I think this is just a matter of making sure that the sata and pata > >handle matching code matches reality now :) > > Currently 1/2 of libata-acpi code is dealing with the above. I'm trying > to figure out why it needs to be that complex. I wrote a patch at one point that simplified this to an extent (http://lkml.org/lkml/2005/12/7/425), but it got somewhat bogged down in discussion about where the right place to do the binding was. Personally I'd prefer to handle this in a similar way to PCI - that is, register the ata bus with ACPI and then find handles as and when new ata devices are added to that bus. This has the advantage that it's easy to tie ACPI events to specific ata devices, which could then be integrated with the bay and dock drivers. -- Matthew Garrett | mjg59@xxxxxxxxxxxxx - 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
