On Mon, Feb 24, 2014 at 9:58 AM, Oliver Neukum <[email protected]> wrote: > On Mon, 2014-02-24 at 08:55 -0800, Dan Williams wrote: >> On Mon, Feb 24, 2014 at 2:17 AM, Oliver Neukum <[email protected]> wrote: >> > On Fri, 2014-02-21 at 16:10 -0800, Dan Williams wrote: >> >> From: Lan Tianyu <[email protected]> > >> >> +* wakeup note: the implementation does not allow a port connected to a >> >> + device with wakeup capability to be powered off. >> > >> > The capability may be there. It just mustn't be enabled. >> >> I'm not sure I grok this comment? Specifically I am referring to this logic: >> >> usb_port_suspend() { >> [..] >> if (status == 0 && !udev->do_remote_wakeup && udev->persist_enabled) >> { > > do_remote_wakeup does not mean that the device can do remote wakeup. > It means that some interface driver has requested remote wakeup to be > enabled at the next suspend. Some drivers don't use remote wakeup > under some circumstances even though the device does support it. > The best example for this is btusb. > If you do "hciconfig down" remote wakeup will not be requested. > > Your description suggests that it depends on the device's capabilities. >
Got it now, thanks for the clarification. -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
