On Tuesday, May 29, 2012, Alan Stern wrote:

On Sun, 27 May 2012, Rafael J. Wysocki wrote:

quoted

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