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

On Tue, 29 May 2012, Rafael J. Wysocki wrote:

quoted

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

quoted

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.

Oh -- I guess I got the machines mixed up.  Since _SxW isn't present
and _SxD is, we accept the value of _SxD as the only state in which
wakeup is supported.

Precisely.

ACPI apparently doesn't have any way to express: "The device is allowed 
to be in either D2 or D3 during S3 sleep, but it supports wakeup only 
in D3."  And trying to express the inexpressible, the BIOS ended up 
being buggy.

Yeah.

ACPI also apparently doesn't have any way to express: "The device is 
allowed be in D2 but not D3 during S3 sleep, even if wakeup is not 
enabled."

That's my understanding too.

quoted

quoted

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.

quoted

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.

It's easy enough to write such a check (or perhaps more reliably, check
for a product name matching "P8Z68-V").

I think we should try to express it as a PCI quirk in quirks.c, though.

More difficult is knowing whether it's the right thing to do.  We don't
know the extent of the underlying problem.

Well, we can only learn that by experience, so we should address the know
cases and then try to find patterns, if they exist.

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