Message-ID: <CAAhV-H6drj1df3Y4_Z67t4TzJ5n6YiexsEHKTPvi1caNvw5H9A@mail.gmail.com>
Date: Wed, 31 Dec 2025 17:38:05 +0800
From: Huacai Chen <chenhuacai@...nel.org>
To: Alan Stern <stern@...land.harvard.edu>
Cc: Diederik de Haas <diederik@...ow-tech.com>, 
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>, Huacai Chen <chenhuacai@...ngson.cn>, 
	linux-usb@...r.kernel.org, linux-kernel@...r.kernel.org, 
	stable@...r.kernel.org, Shengwen Xiao <atzlinux@...a.com>, 
	linux-rockchip@...ts.infradead.org
Subject: Re: [PATCH] USB: OHCI/UHCI: Add soft dependencies on ehci_hcd

Hi, Alan,

On Wed, Dec 31, 2025 at 12:42 AM Alan Stern <stern@...land.harvard.edu> wrote:
>
> On Tue, Dec 30, 2025 at 03:40:27PM +0100, Diederik de Haas wrote:
> > On Tue Dec 30, 2025 at 9:15 AM CET, Greg Kroah-Hartman wrote:
> > > On Tue, Dec 30, 2025 at 04:00:14PM +0800, Huacai Chen wrote:
> > >> Commit 9beeee6584b9aa4f ("USB: EHCI: log a warning if ehci-hcd is not
> > >> loaded first") said that ehci-hcd should be loaded before ohci-hcd and
> > >> uhci-hcd. However, commit 05c92da0c52494ca ("usb: ohci/uhci - add soft
> > >> dependencies on ehci_pci") only makes ohci-pci/uhci-pci depend on ehci-
> > >> pci, which is not enough and we may still see the warnings in boot log.
> > >> So fix it by also making ohci-hcd/uhci-hcd depend on ehci-hcd.
> > >>
> > >> Cc: stable@...r.kernel.org
> > >> Reported-by: Shengwen Xiao <atzlinux@...a.com>
> > >> Signed-off-by: Huacai Chen <chenhuacai@...ngson.cn>
> > >> ---
> > >>  drivers/usb/host/ohci-hcd.c | 1 +
> > >>  drivers/usb/host/uhci-hcd.c | 1 +
> > >>  2 files changed, 2 insertions(+)
> > >>
> > >> diff --git a/drivers/usb/host/ohci-hcd.c b/drivers/usb/host/ohci-hcd.c
> > >> index 9c7f3008646e..549c965b7fbe 100644
> > >> --- a/drivers/usb/host/ohci-hcd.c
> > >> +++ b/drivers/usb/host/ohci-hcd.c
> > >> @@ -1355,4 +1355,5 @@ static void __exit ohci_hcd_mod_exit(void)
> > >>    clear_bit(USB_OHCI_LOADED, &usb_hcds_loaded);
> > >>  }
> > >>  module_exit(ohci_hcd_mod_exit);
> > >> +MODULE_SOFTDEP("pre: ehci_hcd");
> > >
> > > Ick, no, this way lies madness.  I hate the "softdep" stuff, it's
> > > usually a sign that something is wrong elsewhere.
> > >
> > > And don't add this _just_ to fix a warning message in a boot log, if you
> > > don't like that message, then build the module into your kernel, right?
> > >
> > > And I really should just go revert 05c92da0c524 ("usb: ohci/uhci - add
> > > soft dependencies on ehci_pci") as well, that feels wrong too.
> >
> > FWIW, I've been seeing this warning on several of my Rockchip based
> > devices as well. I thought I had already mentioned that on some ML, but
> > couldn't find it on lore.k.o ... turns out I reported it on my 'own' ML:
> > https://lists.sr.ht/~diederik/pine64-discuss/%3CDD65LB64HB7K.15ZYRTB98X8G2@cknow.org%3E
> > (and likely on #linux-rockchip IRC channel)
> >
> > Most of it is just my research notes, but the last post also had this:
> >
> > ```
> > I checked the last 20 boots on my devices to see that warning (or not).
> > Device                                Number of times that warning showed up
> > Rock64 (rk3328)                       16x
> > RockPro64 (rk3399)            11x
> > Quartz64 Model A (rk3566)      7x
> > Quartz64 Model B (rk3566)     14x
> > PineTab2 (rk3566)             17x
> > NanoPi R5S (rk3568)           13x
> > Rock 5B (rk3588)              12x
> > ```
> >
> > While I generally don't like seeing warning messages, it often also
> > resulted in USB2 ports not working. Maybe even every time, but I only
> > notice it when I actually tried to use one of the USB2 ports.
> >
> > The first post mentioned what I 'assume' to be the problem:
> > ```
> > CONFIG_USB_XHCI_HCD=m
> > CONFIG_USB_EHCI_HCD=m
> > CONFIG_USB_OHCI_HCD=m
> > ```
> >
> > So I guess USB_EHCI_HCD doesn't work with '=m'.
>
> Not true, it really does work with "=m".
>
> And in fact, your systems should work even if the modules are loaded in
> the wrong order.  The issue is that doing so can cause a brief
> interruption in the existing USB connections when the ehci-pci module is
> loaded.
>
> If your systems don't use PCI for these host controllers then I don't
> know how they would behave.  The issue is: How does the hardware route
> low-speed and full-speed USB connections to the different types of
> controller?
>
> On PCI systems, when ehci-pci isn't loaded, the hardware routes all
> connections directly to the companion UHCI or OHCI controller.  When
> ehci-pci is loaded, the hardware routes connections to the EHCI
> controller, and when the driver sees that a connection isn't running at
> high speed (480 Mb/s), it tells the hardware to switch the connection
> over to the companion.
>
> So if a low-speed (1.5 Mb/s) or full-speed (12 Mb/s) device is connected
> before ehci-pci loads, its connection will get routed to the companion
> controller.  Then when ehci-pci loads, the connection will be switched
> over to the EHCI controller, which will cause the existing connection to
> be dropped.  Then the connection will be routed back to the companion
> controller, but it will be perceived as a new connection, resulting in a
> brief interruption in service.  For many devices this won't matter, but
> for some it might.  The only way to avoid the problem is to load
> ehci-pci before uhci-pci and ohci-pci.
>
> (A similar problem can occur with high-speed-capable devices.  When
> initially attached to the companion controller, they are forced to
> connect at full speed.  But when the connection is changed to the EHCI
> controller, they are able to run at high speed -- and again, the result
> is a new connection, causing service to be interrupted and then start up
> fresh but running much faster.)
>From your long explanation I think the order is still important. "New
connection" may be harmless for USB keyboard/mouse, but really
unacceptable for USB storage.

If we revert 05c92da0c524 and 9beeee6584b9, the real problem doesn't
disappear. Then we go back to pre-2008 to rely on distributions
providing a correct modprobe.conf?

Huacai

>
> Alan Stern

Powered by blists - more mailing lists