mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Mathias Nyman <mathias.nyman@linux.intel.com>
To: Lovekesh Solanki <lovekeshsolanki00@gmail.com>,
	linux-usb@vger.kernel.org
Cc: linux-kernel@vger.kernel.org,
	Michal Pecio <michal.pecio@gmail.com>,
	Mathieu Fluhr <mathieu.fluhr@gmail.com>,
	Mario Limonciello <mario.limonciello@amd.com>,
	Thorsten Leemhuis <regressions@leemhuis.info>,
	regressions@lists.linux.dev, stable@vger.kernel.org
Subject: Re: [PATCH 1/2] usb: hub: use shorter 120ms post resume hold for SS root hubs
Date: Wed, 2 Sep 2026 16:29:40 +0300	[thread overview]
Message-ID: <9f8fae96-0865-4b0e-9650-00e92e324f9e@linux.intel.com> (raw)
In-Reply-To: <20260831190349.29590-1-lovekeshsolanki00@gmail.com>

Hi

Some minor nitpicks/personal preferences if you are sending a v2.

I don't really object taking this as is either.

On 8/31/26 22:03, Lovekesh Solanki wrote:
> Commit 8f5b7e2bec1c ("usb: hub: fix detection of high tier USB3 devices
> behind suspended hubs") holds a runtime PM reference for
> USB_SS_PORT_U0_WAKE_TIME (200ms) after every SS hub resume, so
> downstream links have time to finish trianing before the hub can
> suspend again.
> 
> But 200ms is excessive for root hubs since a root hub has no upstream
> suspended hub whose wake propagation needs to be accounted for.
> The root hub still needs some time for USB3 link training to complete,
> And root hubs also default to zero auto suspend delay and get
> periodically resumed by userspace USB enumeration opening and
> closing their usbfs nodes (adb, libusb).
> This extra 200ms hold stretches this resume into a suspend/resume
> cycle of roughly once per second, which on idle AMD systems have
> been reported to cause system freezes.

I'd highlight the fact that this patch mitigates the AMD platform issue.

Maybe begin commit message with something like

"Holding a USB3 hub PM runtime reference for 200ms at hub resume triggers a
  AMD platform issue. Users running Android adb report crashes after adb has
  been polling and waking up the USB subsystem once a second for some time.
  Vendors are working on a solution. Disabling USB runtime PM is one way to
  prevent this issue, but it is also proven that reducing the hold time to 120ms in
  resume also mitigates it. See Link for more details.

  Reducing the hold time to 120ms for the USB3 roothub is in itself a valid change
  and optimization as the current 200ms is excessive...
"

> 
> Shorten the post resume hold to 120ms only for root hubs but
> keep the 200ms for external hubs that the original commit is
> intended for.
> 
> Reported-by: Mathieu Fluhr <mathieu.fluhr@gmail.com>
> Link: https://lore.kernel.org/all/CAPyJwA_D9qw0T72f8zwM1yKjP+To=maVANbcdsWM7yRmbBxYvw@mail.gmail.com/
> Cc: stable@vger.kernel.org
> Fixes: 8f5b7e2bec1c ("usb: hub: fix detection of high tier USB3 devices behind suspended hubs")
> Signed-off-by: Lovekesh Solanki <lovekeshsolanki00@gmail.com>
> ---
>   drivers/usb/core/hub.c | 10 +++++++++-
>   1 file changed, 9 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
> index 3345b3298daf..e1415ad5f908 100644
> --- a/drivers/usb/core/hub.c
> +++ b/drivers/usb/core/hub.c
> @@ -76,6 +76,12 @@
>    */
>   #define USB_SS_PORT_U0_WAKE_TIME	200  /* ms */
>   
> +/*
> + * Root hubs have no upstream hub whose wake propagation needs to be
> + * accounted for, but still needs time for USB3 link training to complete.
> + */
> +#define USB_SS_ROOT_HUB_U0_WAKE_TIME 120 /* ms */

I'd do minor changes to the original code comment above the first #define,
and just add the second define right after it

/*
  * modified original comment
  */
#define USB_SS_PORT_U0_WAKE_TIME	200  /* ms */
#define USB_SS_RH_PORT_U0_WAKE_TIME	120  /* ms */

Thanks
Mathias

  parent reply	other threads:[~2026-09-02 13:32 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-31 19:03 Lovekesh Solanki
2026-08-31 19:03 ` [PATCH 2/2] xhci: drop 120ms U3 LFPS wake retry wait from runtime resume Lovekesh Solanki
2026-09-01 12:53   ` Mathias Nyman
2026-09-01 15:50     ` Lovekesh Solanki
2026-09-02 12:10       ` Mathias Nyman
2026-09-02 18:21         ` Lovekesh Solanki
2026-09-03  7:42           ` Mathias Nyman
2026-09-04 13:13             ` Lovekesh Solanki
2026-09-02 13:29 ` Mathias Nyman [this message]
2026-09-02 18:43   ` [PATCH 1/2] usb: hub: use shorter 120ms post resume hold for SS root hubs Lovekesh Solanki
2026-09-03  7:50     ` Mathias Nyman

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=9f8fae96-0865-4b0e-9650-00e92e324f9e@linux.intel.com \
    --to=mathias.nyman@linux.intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=lovekeshsolanki00@gmail.com \
    --cc=mario.limonciello@amd.com \
    --cc=mathieu.fluhr@gmail.com \
    --cc=michal.pecio@gmail.com \
    --cc=regressions@leemhuis.info \
    --cc=regressions@lists.linux.dev \
    --cc=stable@vger.kernel.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®