http://bugzilla.kernel.org/show_bug.cgi?id=6892
------- Comment #17 from [EMAIL PROTECTED] 2007-10-24 00:23 ------- I was wondering why all those patches all got dropped. It's customary to let people know _why_ that's done... It seems like one issue was a behavioral change: making devices wake by default. That would be easy to change, if necessary, though it would be IMO inadvisable. (And that would only affect _one_ of the several patches which were dropped.) Note also that you're wrong about this being a "regression". It could not be a "regression" unless there a bug was introduced. In this case, any such bug would necessarily be a latent one in some PCI device driver which couldn't handle the wake events it requested ... which previously would never arrive. I don't recall any bugs being reported to me (and you didn't mention any in your comment). Another incorrect comment there is that "when the wakeup bit is set, ACPI enables the wakeup GPE so that PME can wakeup the device at runtime". Untrue, as evidenced by this bug report: there's no runtime wakeup support in ACPI. The only ACPI code enabling wakeup GPEs kicks in during system suspend. The point of the bug report is that the PCI mechanism to support runtime wakeups just doesn't work with ACPI. I can't see a semantic difference in terms of the device. In both cases, the device issues a wake event. When a user expects a wake event to have an effect, the system state should be irrelevant. (The user should not need to know or care about the system state when using a peripheral. They may not even be able to know that information...) Expecting that to matter is needless complexity, and would violate the "principle of least surprise" as well as several other principles of good system design. Re what MS-Windows does ... that should not be a significant issue for Linux. And I'll observe that "turn off device to save power" says nothing at all about wakeup, or about using *functional* device low power states. At best, that's a comment that MS-Windows is confused about runtime PM. I read it as just permission to put devices into ACPI D3 states, which might not be desirable in some cases because of concerns like "only BIOS knows how to turn it back on". Those concerns are not part of the design center for Linux-based open systems; at best they're bugs to work around. Re "drivers should call pci_enable_wake" ... for now, only during system suspend state transitions. In the future, as part of entering runtime low power states. NEVER as a direct consequence of enabling wakeup through the driver model flag; for example, enabling wake from PCI_D0 could cause much confusion. Agreed that those ACPI flags should vanish, but the entire reason they exist seems to be because of Bug #6892 (this!) whereby the current ACPI stack ignores PME# except optionally during system sleep states. -- Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ acpi-bugzilla mailing list acpi-bugzilla@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/acpi-bugzilla
