On Wednesday 11 November 2009, Alan Stern wrote: > On Wed, 11 Nov 2009, Oliver Neukum wrote: > > > Am Mittwoch, 11. November 2009 18:08:17 schrieb Alan Stern: > > > On Wed, 11 Nov 2009, Oliver Neukum wrote: > > > > > > That seems to be a bit harsh. If you do not specify that a device be > > > > able to wake the whole system, why would it be good for a request > > > > coming from it to abort a system sleep transition? > > > > > > The way you specify that a device be able to wake the whole system is > > > by enabling its remote wakeup attribute. If this attribute is not > > > enabled then the device will not send remote wakeup requests, so the > > > scenario described above will not occur -- no IRQ will be generated. > > > > But what happens if a driver has requested remote wakeup requests > > to do runtime power management? > > The driver mustn't tell the device to send remote wakeup requests if > the remote wakeup attribute isn't set. If this means it can't do > effective runtime PM, then so be it. > > Now, this does raise another point, which has been mentioned before. > To wit: devices really ought to have _two_ remote-wakeup attributes, > one for runtime PM and one for system sleep. Yes, they do and there's another reason. Namely, there apparently are devices which can wake up the system from a sleep state and that are unable to generate runtime wakeup events. > But that would introduce yet more complexity and opportunities for > confusion. Nevertheless. 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
