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

[frank jpliu]

On Fri, Oct 30, 2026 at 10:23 AM Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote:
>
> 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.

Makes sense, thanks for the explanation. I'll drop this patch and
won't pursue it further.
Thanks for your time and the review.

Best regards,
Frank