All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jan-Marek Glogowski <glogow@fbihome.de>
To: linux-usb@vger.kernel.org
Cc: Greg KH <gregkh@linuxfoundation.org>,
	Alan Stern <stern@rowland.harvard.edu>,
	Mathias Nyman <mathias.nyman@linux.intel.com>,
	Nicolas Boichat <drinkcat@chromium.org>,
	Oliver Neukum <oneukum@suse.com>
Subject: [v3] usb: warm-reset ports on hub resume, if requested
Date: Fri, 18 Jan 2019 12:28:09 +0100	[thread overview]
Message-ID: <0ae1181c-1ee3-f813-825e-043fefb72418@fbihome.de> (raw)

Just adding some CC of commit signers from get_maintainer.pl

Am 16.01.19 um 18:07 schrieb 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 that hub and the 
> hub resumes, so we don't call port_event, which would otherwise
> warm-reset ports. The device works ok without this patch, if
> there is already any other device connected to the hub.
> 
> Signed-off-by: Jan-Marek Glogowski <glogow@fbihome.de>
> ---
> 
> 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, so I could abandon my explanation mail, which I
> was typing when Gregs mail arrived.
> 
> ---
>  drivers/usb/core/hub.c | 21 +++++++++++++++------
>  1 file changed, 15 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
> index 1d1e61e..e0cc740 100644
> --- a/drivers/usb/core/hub.c
> +++ b/drivers/usb/core/hub.c
> @@ -108,6 +108,16 @@ 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 int hub_port_reset(struct usb_hub *hub, int port1,
> +			struct usb_device *udev, unsigned int delay, bool warm);
> +
> +#define HUB_ROOT_RESET_TIME	60	/* times are in msec */
> +#define HUB_SHORT_RESET_TIME	10
> +#define HUB_BH_RESET_TIME	50
> +#define HUB_LONG_RESET_TIME	200
> +#define HUB_RESET_TIMEOUT	800
>  
>  static inline char *portspeed(struct usb_hub *hub, int portstatus)
>  {
> @@ -1122,6 +1132,11 @@ static void hub_activate(struct usb_hub *hub, enum hub_activation_type type)
>  						USB_SS_PORT_LS_POLLING))
>  			need_debounce_delay = true;
>  
> +		if (type == HUB_RESUME &&
> +		    hub_port_warm_reset_required(hub, port1, portstatus))
> +			hub_port_reset(hub, port1, udev,
> +					HUB_BH_RESET_TIME, true);
> +
>  		/* Clear status-change flags; we'll debounce later */
>  		if (portchange & USB_PORT_STAT_C_CONNECTION) {
>  			need_debounce_delay = true;
> @@ -2653,12 +2668,6 @@ static unsigned hub_is_wusb(struct usb_hub *hub)
>  #define SET_CONFIG_TRIES	(2 * (use_both_schemes + 1))
>  #define USE_NEW_SCHEME(i, scheme)	((i) / 2 == (int)scheme)
>  
> -#define HUB_ROOT_RESET_TIME	60	/* times are in msec */
> -#define HUB_SHORT_RESET_TIME	10
> -#define HUB_BH_RESET_TIME	50
> -#define HUB_LONG_RESET_TIME	200
> -#define HUB_RESET_TIMEOUT	800
> -
>  /*
>   * "New scheme" enumeration causes an extra state transition to be
>   * exposed to an xhci host and causes USB3 devices to receive control
>

             reply	other threads:[~2019-01-18 11:28 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-01-18 11:28 Jan-Marek Glogowski [this message]
  -- strict thread matches above, loose matches on Subject: below --
2019-02-01 11:46 [v3] usb: warm-reset ports on hub resume, if requested Mathias Nyman
2019-01-31 21:11 Alan Stern
2019-01-31 18:52 Jan-Marek Glogowski
2019-01-31 16:53 Alan Stern
2019-01-31 15:13 Jan-Marek Glogowski
2019-01-31 14:56 Mathias Nyman
2019-01-31 10:42 Jan-Marek Glogowski
2019-01-30 16:56 Jan-Marek Glogowski
2019-01-30 14:58 Mathias Nyman
2019-01-30 12:38 Jan-Marek Glogowski
2019-01-25 16:21 Jan-Marek Glogowski
2019-01-25 15:14 Mathias Nyman
2019-01-16 17:07 Jan-Marek Glogowski

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=0ae1181c-1ee3-f813-825e-043fefb72418@fbihome.de \
    --to=glogow@fbihome.de \
    --cc=drinkcat@chromium.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=mathias.nyman@linux.intel.com \
    --cc=oneukum@suse.com \
    --cc=stern@rowland.harvard.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.