Re: [PATCH] usb: core: raise root-hub autosuspend delay to stop a busy-loop

From: Alan Stern

Date: Thu Oct 29 2026 - 22:23:23 EST


On Wed, Oct 28, 2026 at 12:18:59PM +0800, Jianping Liu wrote:
> From: Jianping Liu <frankjpliu@xxxxxxxxxxx>
>
> hub_probe() sets the hub autosuspend delay to 0. An idle hub is
> therefore suspended at once, with no waiting time.
>
> Suspending the root hub can fail. While a port reports over-current
> or a connect change, xHCI refuses the bus suspend and returns -EBUSY.
> usb_runtime_suspend() returns that error. The hub is resumed, and when
> its status URB completes the same suspend runs again.

Why should root hubs be special? An ordinary hub doesn't refuse to
suspend because of an over-current or connect change. xhci-hcd ought to
behave the same way.

> The PM core would normally leave a gap before that next attempt. It
> starts the autosuspend timer only when the delay is still in the
> future. A delay of 0 is already due, so no timer is started and there
> is nothing to wait for. Suspend and resume repeat immediately, and one
> CPU core stays at 100% until the port is no longer stuck.
>
> If a root-hub runtime suspend fails while the delay is still 0, set
> the delay to 1000 ms so the next attempt waits. If a later runtime
> suspend succeeds and the delay is not 0, put it back to 0.

The concerns raised by Sashiko are valid. If people really want hubs
(or just root hubs) to have a positive autosuspend delay, it should be
set to a small value such as 100 ms. Not constantly alternating between
0 and 1000.

Furthermore, this can be controlled from userspace by writing to the
aprpopriate sysfs attribute file. The kernel doesn't need to be
involved.

Alan Stern