Re: [PATCH] USB: OHCI/UHCI: Add soft dependencies on ehci_hcd

["Diederik de Haas" <diederik@cknow-tech.com>]

On Tue Dec 30, 2025 at 5:42 PM CET, Alan Stern 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.
>> >> <snip>
>> 
>> FWIW, I've been seeing this warning on several of my Rockchip based
>> devices as well. ... 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".

I shouldn't have stated that before I fully investigated it.
I do plan to change my kernel config to make it "=y" though.

> 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?

One of the issue is that I don't (fully) understand how this (should)
work. F.e. I wondered about all the PCI 'references' in your explanation
(thanks for that :-)).

I (also) wondered why the number on Quartz64-A was lower, but that
actually has a PCIe slot ... with a USB3 controller card in it.

If I do ``lsmod | grep pci`` on my PineTab2, I get zero hits, but I do
get hits when doing it on my Q64-A.

On my Rock 5B, I get 1 hit, "phy_rockchip_snps_pcie3", but that has a
NVMe drive connected to it. And I have a (working) keyboard connected
via a USB2 port. And/while I do have the warning ...

Cheers,
  Diederik

> 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.)
>
> Alan Stern