On Tuesday, May 29, 2012, Alan Stern wrote: > On Tue, 29 May 2012, Rafael J. Wysocki wrote: > > > 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. > > 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. > > > 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. > > 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
