On Mon, Feb 24, 2014 at 9:58 AM, Oliver Neukum <oneukum@xxxxxxx> wrote:
> On Mon, 2014-02-24 at 08:55 -0800, Dan Williams wrote:
>> On Mon, Feb 24, 2014 at 2:17 AM, Oliver Neukum <oneukum@xxxxxxx> wrote:
>> > On Fri, 2014-02-21 at 16:10 -0800, Dan Williams wrote:
>> >> From: Lan Tianyu <tianyu.lan@xxxxxxxxx>
>
>> >> +* 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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
