Re: libata-acpi: summary, problems, questions and proposal

[Matthew Garrett <mjg59@srcf.ucam.org>]

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@srcf.ucam.org