On Thu, 12 Nov 2009, Matthew Garrett wrote: > On Thu, Nov 12, 2009 at 08:41:11AM +0100, Oliver Neukum wrote: > > Am Donnerstag, 12. November 2009 01:33:12 schrieb Matthew Garrett: > > > On Wed, Nov 11, 2009 at 06:09:24PM -0500, Alan Stern wrote: > > > > That's okay. There's no harm in trying to enable remote wakeup on a > > > > device which doesn't support it. > > > > > > There's harm if we're using the ability to generate remote waleups as a > > > condition for whether we can perform runtime pm on the device... > > > > That I would consider backwards. If the user enables runtime power management > > of a device, he has to live with remote wakeup being enabled. At most > > the kernel might resume and switch off remote wakeup on the device, > > but we might also leave this to user space. > > My point was that if we don't have remote wakeup support at runtime, we > can't enable runtime PM of the device. So we need to be able to > distinguish between runtime remote wakeup and system sleep remote > wakeup. You are mixing up two different scenarios. The real trouble arises if we can't tell whether runtime remote wakeup is available, or we think it is available when in fact it isn't. But if we know accurately that remote wakeup isn't available at runtime then there's no problem -- the driver simply doesn't use runtime PM. Even if the "wakeup" attribute in sysfs is enabled. Alan Stern -- 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
