Re: [RFT] PCI changes related to wakeup (was: Re: [linux-pm] ehci_hcd related S3 lockup on ASUS laptops, again)

["Rafael J. Wysocki" <rjw@sisk.pl>]

On Tuesday, May 29, 2012, Alan Stern wrote:
> On Sun, 27 May 2012, Rafael J. Wysocki wrote:
> 
> > So, do you think we should apply [1/4] and [2/4] and try to work around the
> > BIOS bug from https://bugzilla.kernel.org/show_bug.cgi?id=43278 (I suppose
> > we can do that by double checking if the target state returned by ACPI is
> > in agreement with the capabilities returned by the PCI layer)?
> 
> Here's one possible approach.  It only solves part of the problem, but
> it ought to help with Bugzilla 43278 (Dâniel's case).  I suggest that
> we don't believe the output from _SxW if the PCI PM capability
> indicates that PME is supported in a higher-numbered D state than _SxW
> says.
> 
> On Dâniel's smachine, _SxW returns D2

No, it doesn't.  In fact, _SxW is not present for that device in his DSDT.

> but the controller supports PME in D3; therefore we would use D3.

Yes, we can do that.  This goes along the lines of what I said in the bug
entry.

> This still leaves the original problem.  It seems clear that ACPI
> won't be sufficient to solve this -- at least, it won't help in the
> case where the controller isn't enabled for wakeup.
> 
> Therefore we really do need a quirk, probably in ehci-hcd like the 
> original patch.  If it is restricted to apply only in cases where the 
> DMI information lists ASUSTeK as the manufacturer, perhaps that will be 
> sufficient.  (For some reason, the manufacturer field in Dâniel's BIOS 
> isn't initialized.)

Yeah.

I'll have a deeper look at this later today, I think.

Thanks,
Rafael
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html