linux-kernel - Re: [PATCH] usb: Allow USB device to be warm reset in suspended state

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 for Android: free password hash cracker in your pocket

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

Message-Id: <325CE337-2467-4DBF-AF23-E4E5E11EAEFB@canonical.com>
Date:   Wed, 6 Nov 2019 02:18:14 +0800
From:   Kai-Heng Feng <kai.heng.feng@...onical.com>
To:     Alan Stern <stern@...land.harvard.edu>
Cc:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Mathias Nyman <mathias.nyman@...el.com>,
        USB list <linux-usb@...r.kernel.org>,
        Kernel development list <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] usb: Allow USB device to be warm reset in suspended state



> On Nov 6, 2019, at 02:07, Alan Stern <stern@...land.harvard.edu> wrote:
> 
> On Wed, 6 Nov 2019, Kai-Heng Feng wrote:
> 
>> On Dell WD15 dock, sometimes USB ethernet cannot be detected after plugging
>> cable to the ethernet port, the hub and roothub get runtime resumed and
>> runtime suspended immediately:
>> ...
> 
>> ...
>> 
>> As Mathias pointed out, the hub enters Cold Attach Status state and
>> requires a warm reset. However usb_reset_device() bails out early when
>> the device is in suspended state, as its callers port_event() and
>> hub_event() don't always resume the device.
>> 
>> Since there's nothing wrong to reset a suspended device, allow
>> usb_reset_device() to do so to solve the issue.
> 
> I was sure I remembered reading somewhere that suspended devices were
> not allowed to be reset, but now I can't find that requirement anywhere
> in the USB spec.

I don't find it in the USB spec either.
That said, the following usb_autoresume_device() before reset may resume the device.
I've also tried using pm_runtime_get_noresume() and it works equally well for my case but I am not sure if we want to change the behavior here.

> 
>> Signed-off-by: Kai-Heng Feng <kai.heng.feng@...onical.com>
>> ---
>> drivers/usb/core/hub.c | 3 +--
>> 1 file changed, 1 insertion(+), 2 deletions(-)
>> 
>> diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
>> index 05a2d51bdbe0..f0194fdbc9b8 100644
>> --- a/drivers/usb/core/hub.c
>> +++ b/drivers/usb/core/hub.c
>> @@ -5877,8 +5877,7 @@ int usb_reset_device(struct usb_device *udev)
>> 	struct usb_host_config *config = udev->actconfig;
>> 	struct usb_hub *hub = usb_hub_to_struct_hub(udev->parent);
>> 
>> -	if (udev->state == USB_STATE_NOTATTACHED ||
>> -			udev->state == USB_STATE_SUSPENDED) {
>> +	if (udev->state == USB_STATE_NOTATTACHED) {
>> 		dev_dbg(&udev->dev, "device reset not allowed in state %d\n",
>> 				udev->state);
>> 		return -EINVAL;
> 
> You forgot to update the kerneldoc for this function.

Ok, will do that in v2.

Kai-Heng

> 
> Alan Stern
>