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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
