usb: handle warm-reset port requests on hub resume

usb: handle warm-reset port requests on hub resume

[Jan-Marek Glogowski]

On plug-in of my USB-C device, its USB_SS_PORT_LS_SS_INACTIVE
link state bit is set. Greping all the kernel for this bit shows
that the port status requests a warm-reset this way.

This just happens, if its the only device on the root hub, the hub
therefore resumes and the HCDs status_urb isn't yet available.
If a warm-reset request is detected, this sets the hubs event_bits,
which will prevent any auto-suspend and allows the hubs workqueue
to warm-reset the port later in port_event.

Signed-off-by: Jan-Marek Glogowski <glogow@fbihome.de>
---

The original thread is "USB-C storage device not detected on USB 3.1 Gen 2
host when plugged in after boot". A different patch, suggested by Mathias
Nyman, didn't work for me. This patch was just rebased on usb-next, but not
re-tested. Original tests are based on 5.0-rc.

v1: This always warm-resets the ports in hub_activate, independent of the
"enum hub_activation_type". Just had a single device to test.

v2: I had the idea about the working device, if there is already a device
connected to the hub and that a resume only on "type == HUB_RESUME" should
be sufficient. This still works for me, but I didn't follow all the
hub_activate callers everywhere and I'm definitly still missing a lot of
knowledge about USB stuff. There is also HUB_RESET_RESUME with a slightly
different code path. I don't know how to trigger this.

v3: code unchanged to v2.

v4: instead of handling the warm-reset directly from hub_activate by calling
hub_port_reset, this defers the reset by setting the hubs event_bits of the
port.

---
 drivers/usb/core/hub.c | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index bb0830c..8d4631c 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -108,6 +108,8 @@ EXPORT_SYMBOL_GPL(ehci_cf_port_reset_rwsem);
 static void hub_release(struct kref *kref);
 static int usb_reset_and_verify_device(struct usb_device *udev);
 static int hub_port_disable(struct usb_hub *hub, int port1, int set_state);
+static bool hub_port_warm_reset_required(struct usb_hub *hub, int port1,
+		u16 portstatus);
 
 static inline char *portspeed(struct usb_hub *hub, int portstatus)
 {
@@ -1137,6 +1139,11 @@ static void hub_activate(struct usb_hub *hub, enum hub_activation_type type)
 						   USB_PORT_FEAT_ENABLE);
 		}
 
+		/* Make sure a warm-reset request is handled by port_event */
+		if (type == HUB_RESUME &&
+		    hub_port_warm_reset_required(hub, port1, portstatus))
+			set_bit(port1, hub->event_bits);
+
 		/*
 		 * Add debounce if USB3 link is in polling/link training state.
 		 * Link will automatically transition to Enabled state after

Re: [PATCH] usb: handle warm-reset port requests on hub resume

[dann frazier]

On Fri, Feb 01, 2019 at 01:52:31PM +0100, Jan-Marek Glogowski wrote:
> On plug-in of my USB-C device, its USB_SS_PORT_LS_SS_INACTIVE
> link state bit is set. Greping all the kernel for this bit shows
> that the port status requests a warm-reset this way.
> 
> This just happens, if its the only device on the root hub, the hub
> therefore resumes and the HCDs status_urb isn't yet available.
> If a warm-reset request is detected, this sets the hubs event_bits,
> which will prevent any auto-suspend and allows the hubs workqueue
> to warm-reset the port later in port_event.

Hi - just a heads-up while we continue to debug - we've received a
regression report in Ubuntu after pulling this in from stable. It was
bisected down to this commit and still reproducible w/ 5.5-rc2:

  https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1856608

  -dann

> Signed-off-by: Jan-Marek Glogowski <glogow@fbihome.de>
> Acked-by: Alan Stern <stern@rowland.harvard.edu>
> ---
> 
> The original thread is "USB-C storage device not detected on USB 3.1 Gen 2
> host when plugged in after boot". A different patch, suggested by Mathias
> Nyman, didn't work for me. This patch was just rebased on usb-next, but not
> re-tested. Original tests are based on 5.0-rc.
> 
> v1: This always warm-resets the ports in hub_activate, independent of the
> "enum hub_activation_type". Just had a single device to test.
> 
> v2: I had the idea about the working device, if there is already a device
> connected to the hub and that a resume only on "type == HUB_RESUME" should
> be sufficient. This still works for me, but I didn't follow all the
> hub_activate callers everywhere and I'm definitly still missing a lot of
> knowledge about USB stuff. There is also HUB_RESET_RESUME with a slightly
> different code path. I don't know how to trigger this.
> 
> v3: code unchanged to v2.
> 
> v4: instead of handling the warm-reset directly from hub_activate by calling
> hub_port_reset, this defers the reset by setting the hubs event_bits of the
> port.
> 
> ---
>  drivers/usb/core/hub.c | 7 +++++++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
> index bb0830c..8d4631c 100644
> --- a/drivers/usb/core/hub.c
> +++ b/drivers/usb/core/hub.c
> @@ -108,6 +108,8 @@ EXPORT_SYMBOL_GPL(ehci_cf_port_reset_rwsem);
>  static void hub_release(struct kref *kref);
>  static int usb_reset_and_verify_device(struct usb_device *udev);
>  static int hub_port_disable(struct usb_hub *hub, int port1, int set_state);
> +static bool hub_port_warm_reset_required(struct usb_hub *hub, int port1,
> +		u16 portstatus);
>  
>  static inline char *portspeed(struct usb_hub *hub, int portstatus)
>  {
> @@ -1137,6 +1139,11 @@ static void hub_activate(struct usb_hub *hub, enum hub_activation_type type)
>  						   USB_PORT_FEAT_ENABLE);
>  		}
>  
> +		/* Make sure a warm-reset request is handled by port_event */
> +		if (type == HUB_RESUME &&
> +		    hub_port_warm_reset_required(hub, port1, portstatus))
> +			set_bit(port1, hub->event_bits);
> +
>  		/*
>  		 * Add debounce if USB3 link is in polling/link training state.
>  		 * Link will automatically transition to Enabled state after