linux-kernel - Re: [PATCH] USB: Increment wakeup count on remote wakeup.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 19 Apr 2018 17:50:01 -0700
From:   Ravi Chandra Sadineni <ravisadineni@...gle.com>
To:     Alan Stern <stern@...land.harvard.edu>
Cc:     Ravi Chandra Sadineni <ravisadineni@...omium.org>,
        gregkh@...uxfoundation.org, martin.blumenstingl@...glemail.com,
        chunfeng.yun@...iatek.com, johan@...nel.org,
        arvind.yadav.cs@...il.com, Dmitry Torokhov <dtor@...gle.com>,
        anton.bondarenko.sama@...il.com, f.fainelli@...il.com,
        keescook@...omium.org, mathias.nyman@...ux.intel.com,
        felipe.balbi@...ux.intel.com, ekorenevsky@...il.com,
        peter.chen@....com, joe@...ches.com,
        Todd Broch <tbroch@...gle.com>, linux-usb@...r.kernel.org,
        linux-kernel@...r.kernel.org, Rajat Jain <rajatja@...gle.com>,
        Benson Leung <bleung@...gle.com>
Subject: Re: [PATCH] USB: Increment wakeup count on remote wakeup.

Hi Alan,
Thanks for reviewing the change. Appreciate your time.  I tried to
address your comments in the V2 of the patch.

On Thu, Apr 19, 2018 at 8:01 AM, Alan Stern <stern@...land.harvard.edu> wrote:
> On Wed, 18 Apr 2018, Ravi Chandra Sadineni wrote:
>
>> On chromebooks we depend on wakeup count to identify the wakeup source.
>> But currently USB devices do not increment the wakeup count when they
>> trigger the remote wake. This patch addresses the same.
>>
>> Resume condition is reported differently on USB 2.0 and USB 3.0 devices.
>>
>> On USB 2.0 devices, a wake capable device, if wake enabled, drives
>> resume signal to indicate a remote wake (USB 2.0 spec section 7.1.7.7).
>> The upstream facing port then sets C_PORT_SUSPEND bit and reports a
>> port change event (USB 2.0 spec section 11.24.2.7.2.3). Thus if a port
>> has resumed before driving the resume signal from the host and
>> C_PORT_SUSPEND is set, then the device attached to the given port might
>> be the reason for the last system wakeup. Increment the wakeup count for
>> the same.
>>
>> On USB 3.0 devices, a function may signal that it wants to exit from device
>> suspend by sending a Function Wake Device Notification to the host (USB3.0
>> spec section 8.5.6.4) Thus on receiving the Function Wake, increment the
>> wakeup count.
>>
>> Signed-off-by: ravisadineni@...omium.org
>> ---
>>  drivers/usb/core/hcd.c |  1 +
>>  drivers/usb/core/hub.c | 12 ++++++++++--
>>  2 files changed, 11 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/usb/core/hcd.c b/drivers/usb/core/hcd.c
>> index 777036ae63674..79f95a878fb6e 100644
>> --- a/drivers/usb/core/hcd.c
>> +++ b/drivers/usb/core/hcd.c
>> @@ -2375,6 +2375,7 @@ void usb_hcd_resume_root_hub (struct usb_hcd *hcd)
>>  {
>>       unsigned long flags;
>>
>> +     pm_wakeup_event(dev, 0);
>
> Instead of dev, you probably want to use hcd->self.sysdev.  Or maybe
> hcd->self.controller, although the difference probably doesn't matter
> for your purposes.

Trying to increment the wakeup count for the roothub. So pointed dev
to &hcd->self.root_hub->dev. Hope this is fine.

>
> On the other hand, this wakeup event may already have been counted by
> the host controller's bus subsystem.  Does it matter if the same wakeup
> event gets counted twice?
>
> (This is inevitable with USB devices, in any case.  If a device sends a
> wakeup request, it will be counted for that device, for all the
> intermediate hubs, and for the host controller.)

We are o.k. with the wake-up count getting incremented for the
intermediate hubs. We just want to identify the leaf hid devices, if
they are cause of the remote wake. This way, we can differentiate user
triggered wake from a automatic wakes (Ex: wakes triggered by WOLAN
packets from USB ethernet adapter).

We are also o.k. with the wake-up count getting incremented twice. All
we look for is a change in the wake-up count for the interested
devices.
>
>> @@ -3432,10 +3437,13 @@ int usb_port_resume(struct usb_device *udev, pm_message_t msg)
>>
>>       usb_lock_port(port_dev);
>>
>> -     /* Skip the initial Clear-Suspend step for a remote wakeup */
>>       status = hub_port_status(hub, port1, &portstatus, &portchange);
>> -     if (status == 0 && !port_is_suspended(hub, portstatus))
>> +     /* Skip the initial Clear-Suspend step for a remote wakeup */
>
> What is the reason for moving the comment line down after the
> hub_port_status() call?
Sorry. This was a mistake. Changed this back in V2.
>
> Alan Stern
>
>> +     if (status == 0 && !port_is_suspended(hub, portstatus)) {
>> +             if (portchange & USB_PORT_STAT_C_SUSPEND)
>> +                     pm_wakeup_event(&udev->dev, 0);
>>               goto SuspendCleared;
>> +     }
>>
>>       /* see 7.1.7.7; affects power usage, but not budgeting */
>>       if (hub_is_superspeed(hub->hdev))
>>
>

Thanks,
Ravi