Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Content-Type: text/plain;
        charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3601.0.10\))
Subject: Re: [PATCH] usb: Allow USB device to be warm reset in suspended state
From:   Kai-Heng Feng <kai.heng.feng@canonical.com>
In-Reply-To: <Pine.LNX.4.44L0.1911051200570.1678-100000@iolanthe.rowland.org>
Date:   Wed, 6 Nov 2019 02:18:14 +0800
Cc:     Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        Mathias Nyman <mathias.nyman@intel.com>,
        USB list <linux-usb@vger.kernel.org>,
        Kernel development list <linux-kernel@vger.kernel.org>
Content-Transfer-Encoding: 8BIT
Message-Id: <325CE337-2467-4DBF-AF23-E4E5E11EAEFB@canonical.com>
References: <Pine.LNX.4.44L0.1911051200570.1678-100000@iolanthe.rowland.org>
To:     Alan Stern <stern@rowland.harvard.edu>
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk


> On Nov 6, 2019, at 02:07, Alan Stern <stern@rowland.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@canonical.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
>