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@vger.kernel.org
Reported-by: Shengwen Xiao <atzlinux@sina.com>
Signed-off-by: Huacai Chen <chenhuacai@loongson.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");
 
diff --git a/drivers/usb/host/uhci-hcd.c b/drivers/usb/host/uhci-hcd.c
index 14e6dfef16c6..e1a27d01bdbc 100644
--- a/drivers/usb/host/uhci-hcd.c
+++ b/drivers/usb/host/uhci-hcd.c
@@ -939,3 +939,4 @@ module_exit(uhci_hcd_cleanup);
 MODULE_AUTHOR(DRIVER_AUTHOR);
 MODULE_DESCRIPTION(DRIVER_DESC);
 MODULE_LICENSE("GPL");
+MODULE_SOFTDEP("pre: ehci_hcd");
-- 
2.47.3

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@vger.kernel.org
> Reported-by: Shengwen Xiao <atzlinux@sina.com>
> Signed-off-by: Huacai Chen <chenhuacai@loongson.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.

thanks,

greg k-h

On Tue, Dec 30, 2025 at 09:15:36AM +0100, 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@vger.kernel.org
> > Reported-by: Shengwen Xiao <atzlinux@sina.com>
> > Signed-off-by: Huacai Chen <chenhuacai@loongson.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.

This might also be a good time to revert 9beeee6584b9 ("USB: EHCI: log a 
warning if ehci-hcd is not loaded first").  Firstly, because it doesn't 
test the right condition; what matters is not whether ehci-hcd is loaded 
before uhci-hcd and ohci-hcd, but whether ehci-pci is loaded before 
uhci-pci and ohci-pci.

And secondly, because if the warning hasn't convinced people to fix the 
order of module loading after seventeen years, it's not likely to do so 
in the future.

Alan Stern

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@vger.kernel.org
>> Reported-by: Shengwen Xiao <atzlinux@sina.com>
>> Signed-off-by: Huacai Chen <chenhuacai@loongson.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'.

Cheers,
  Diederik

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@vger.kernel.org
> >> Reported-by: Shengwen Xiao <atzlinux@sina.com>
> >> Signed-off-by: Huacai Chen <chenhuacai@loongson.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.)

Alan Stern

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

On Wed, Dec 31, 2025 at 06:33:34PM +0100, Diederik de Haas wrote:
> 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 ...

I can't say anything specific about your systems without a lot more 
information.  However, I suspect that any problems you are running into 
are not related to that warning.

Alan Stern

Hi, Alan,

On Wed, Dec 31, 2025 at 12:42 AM Alan Stern <stern@rowland.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@vger.kernel.org
> > >> Reported-by: Shengwen Xiao <atzlinux@sina.com>
> > >> Signed-off-by: Huacai Chen <chenhuacai@loongson.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

On Wed, Dec 31, 2025 at 05:38:05PM +0800, Huacai Chen wrote:
> 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?

The warning message in 9beeee6584b9 was written a long time ago; back 
then I didn't realize that the real dependency was between the -pci 
drivers rather than the -hcd ones (and I wasn't aware of softdeps).  The 
soft dependency in 05c92da0c524 is between the -pci drivers, so it is 
correct.

To put it another way, on PCI-based systems it is not a problem if the 
modules are loaded in this order: uhci-hcd, ohci-hcd, ehci-hcd, 
ehci-pci, ohci-pci, uhci-pci.  Even though the warning message would be 
logged, the message would be wrong.

On the whole, I think the best approach is to revert 9beeee6584b9's 
warning message while keeping 05c92da0c524's softdeps.  Greg might not 
approve of soft dependencies between modules in general, but in this 
case I believe it is appropriate.

And so your patch really is not needed, as far as I can tell.  While it 
might in theory help some peculiar platform-dependent scenario, I'm 
not aware of any platforms like that.

Alan Stern

On Wed, Dec 31, 2025 at 11:21 PM Alan Stern <stern@rowland.harvard.edu> wrote:
>
> On Wed, Dec 31, 2025 at 05:38:05PM +0800, Huacai Chen wrote:
> > 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?
>
> The warning message in 9beeee6584b9 was written a long time ago; back
> then I didn't realize that the real dependency was between the -pci
> drivers rather than the -hcd ones (and I wasn't aware of softdeps).  The
> soft dependency in 05c92da0c524 is between the -pci drivers, so it is
> correct.
>
> To put it another way, on PCI-based systems it is not a problem if the
> modules are loaded in this order: uhci-hcd, ohci-hcd, ehci-hcd,
> ehci-pci, ohci-pci, uhci-pci.  Even though the warning message would be
> logged, the message would be wrong.
Correct me if I'm wrong.

I found XHCI is compatible with USB1.0/2.0 devices, but EHCI isn't
compatible with USB1.0. Instead, EHCI usually has an OHCI together,
this is not only in the PCI case.

So I guess OHCI/UHCI have an EHCI dependency in order to avoid "new
connection", not only in the PCI case.


Huacai

>
> On the whole, I think the best approach is to revert 9beeee6584b9's
> warning message while keeping 05c92da0c524's softdeps.  Greg might not
> approve of soft dependencies between modules in general, but in this
> case I believe it is appropriate.
>
> And so your patch really is not needed, as far as I can tell.  While it
> might in theory help some peculiar platform-dependent scenario, I'm
> not aware of any platforms like that.
>
> Alan Stern

On Fri, Jan 02, 2026 at 10:36:35AM +0800, Huacai Chen wrote:
> On Wed, Dec 31, 2025 at 11:21 PM Alan Stern <stern@rowland.harvard.edu> wrote:
> >
> > On Wed, Dec 31, 2025 at 05:38:05PM +0800, Huacai Chen wrote:
> > > 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?
> >
> > The warning message in 9beeee6584b9 was written a long time ago; back
> > then I didn't realize that the real dependency was between the -pci
> > drivers rather than the -hcd ones (and I wasn't aware of softdeps).  The
> > soft dependency in 05c92da0c524 is between the -pci drivers, so it is
> > correct.
> >
> > To put it another way, on PCI-based systems it is not a problem if the
> > modules are loaded in this order: uhci-hcd, ohci-hcd, ehci-hcd,
> > ehci-pci, ohci-pci, uhci-pci.  Even though the warning message would be
> > logged, the message would be wrong.
> Correct me if I'm wrong.
> 
> I found XHCI is compatible with USB1.0/2.0 devices,

Yes.

>  but EHCI isn't
> compatible with USB1.0. Instead, EHCI usually has an OHCI together,
> this is not only in the PCI case.

It's more complicated than that.

For quite a long time now, most systems using EHCI have not included a 
companion OHCI or UHCI controller.  Instead they include a built-in 
USB-2.0 hub; the hub is wired directly into the EHCI controller and the 
external ports are connected to the hub.  USB-2.0 hubs include 
transaction translators that relay packets between high-speed and low- 
or full-speed connections, so they can talk to both USB-1 and USB-2 
devices.  Hence no companion controller is needed.

I don't remember when Intel starting selling chipsets like this, but it 
was probably around 2000 or earlier.  (Some non-Intel-based systems 
included a transaction translator directly in the root hub, so they 
didn't even need to have an additional USB-2.0 hub.)

Before that, systems did include companion controllers along with an 
EHCI controller.  I don't know of any non-PCI systems that did this, but 
of course some may exist.  However, the EHCI-1.0 specification says this 
in section 4.2 "Port Routing and Control" (p. 54):

	The USB 2.0 host controller must be implemented as a 
	multi-function PCI device if the implementation
	includes companion controllers.

> So I guess OHCI/UHCI have an EHCI dependency in order to avoid "new
> connection", not only in the PCI case.

Do you know of any non-PCI systems that do this?

Alan Stern

On Fri, Jan 2, 2026 at 11:13 PM Alan Stern <stern@rowland.harvard.edu> wrote:
>
> On Fri, Jan 02, 2026 at 10:36:35AM +0800, Huacai Chen wrote:
> > On Wed, Dec 31, 2025 at 11:21 PM Alan Stern <stern@rowland.harvard.edu> wrote:
> > >
> > > On Wed, Dec 31, 2025 at 05:38:05PM +0800, Huacai Chen wrote:
> > > > 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?
> > >
> > > The warning message in 9beeee6584b9 was written a long time ago; back
> > > then I didn't realize that the real dependency was between the -pci
> > > drivers rather than the -hcd ones (and I wasn't aware of softdeps).  The
> > > soft dependency in 05c92da0c524 is between the -pci drivers, so it is
> > > correct.
> > >
> > > To put it another way, on PCI-based systems it is not a problem if the
> > > modules are loaded in this order: uhci-hcd, ohci-hcd, ehci-hcd,
> > > ehci-pci, ohci-pci, uhci-pci.  Even though the warning message would be
> > > logged, the message would be wrong.
> > Correct me if I'm wrong.
> >
> > I found XHCI is compatible with USB1.0/2.0 devices,
>
> Yes.
>
> >  but EHCI isn't
> > compatible with USB1.0. Instead, EHCI usually has an OHCI together,
> > this is not only in the PCI case.
>
> It's more complicated than that.
>
> For quite a long time now, most systems using EHCI have not included a
> companion OHCI or UHCI controller.  Instead they include a built-in
> USB-2.0 hub; the hub is wired directly into the EHCI controller and the
> external ports are connected to the hub.  USB-2.0 hubs include
> transaction translators that relay packets between high-speed and low-
> or full-speed connections, so they can talk to both USB-1 and USB-2
> devices.  Hence no companion controller is needed.
>
> I don't remember when Intel starting selling chipsets like this, but it
> was probably around 2000 or earlier.  (Some non-Intel-based systems
> included a transaction translator directly in the root hub, so they
> didn't even need to have an additional USB-2.0 hub.)
>
> Before that, systems did include companion controllers along with an
> EHCI controller.  I don't know of any non-PCI systems that did this, but
> of course some may exist.  However, the EHCI-1.0 specification says this
> in section 4.2 "Port Routing and Control" (p. 54):
>
>         The USB 2.0 host controller must be implemented as a
>         multi-function PCI device if the implementation
>         includes companion controllers.
>
Thank you for your explanation, so it means there are two methods: The
old one is EHCI with a companion OHCI; the new one is EHCI with a
USB-2.0 hub. Right?

> > So I guess OHCI/UHCI have an EHCI dependency in order to avoid "new
> > connection", not only in the PCI case.
>
> Do you know of any non-PCI systems that do this?
Unfortunately, in 2026 there are really "EHCI with a companion OHCI"
for non-PCI systems, please see
arch/loongarch/boot/dts/loongson-2k0500.dtsi.

Huacai

>
> Alan Stern

On Sat, Jan 03, 2026 at 11:16:59AM +0800, Huacai Chen wrote:
> Thank you for your explanation, so it means there are two methods: The
> old one is EHCI with a companion OHCI; the new one is EHCI with a
> USB-2.0 hub. Right?

Right.

> > > So I guess OHCI/UHCI have an EHCI dependency in order to avoid "new
> > > connection", not only in the PCI case.
> >
> > Do you know of any non-PCI systems that do this?
> Unfortunately, in 2026 there are really "EHCI with a companion OHCI"
> for non-PCI systems, please see
> arch/loongarch/boot/dts/loongson-2k0500.dtsi.

Since these systems don't use PCI, the question I raised earlier still 
needs to be answered: How do they route connections between the ports 
and the two controllers?

There may be some exceptions, but for the most part, the code in 
ehci-hcd was written assuming that only PCI-based controllers will have 
companions.  If you want to make an exception for loongson-2k0500, you 
will need to figure out how to get it to work.

Have you tested any of those systems to see how they behave if a USB-1 
device is already plugged in and running when the ehci-hcd driver gets 
loaded?

Alan Stern

On Sat, Jan 3, 2026 at 11:33 AM Alan Stern <stern@rowland.harvard.edu> wrote:
>
> On Sat, Jan 03, 2026 at 11:16:59AM +0800, Huacai Chen wrote:
> > Thank you for your explanation, so it means there are two methods: The
> > old one is EHCI with a companion OHCI; the new one is EHCI with a
> > USB-2.0 hub. Right?
>
> Right.
>
> > > > So I guess OHCI/UHCI have an EHCI dependency in order to avoid "new
> > > > connection", not only in the PCI case.
> > >
> > > Do you know of any non-PCI systems that do this?
> > Unfortunately, in 2026 there are really "EHCI with a companion OHCI"
> > for non-PCI systems, please see
> > arch/loongarch/boot/dts/loongson-2k0500.dtsi.
>
> Since these systems don't use PCI, the question I raised earlier still
> needs to be answered: How do they route connections between the ports
> and the two controllers?
>
> There may be some exceptions, but for the most part, the code in
> ehci-hcd was written assuming that only PCI-based controllers will have
> companions.  If you want to make an exception for loongson-2k0500, you
> will need to figure out how to get it to work.
Loongson-2K0500 use EHCI/OHCI with platform bus, while
Loongson-2K1000/2000 use EHCI/OHCI with PCI bus. They use the same USB
IP cores, so the route connections are probably the same.

Huacai
>
> Have you tested any of those systems to see how they behave if a USB-1
> device is already plugged in and running when the ehci-hcd driver gets
> loaded?
>
> Alan Stern

On Sat, Jan 03, 2026 at 11:57:47AM +0800, Huacai Chen wrote:
> On Sat, Jan 3, 2026 at 11:33 AM Alan Stern <stern@rowland.harvard.edu> wrote:
> > Since these systems don't use PCI, the question I raised earlier still
> > needs to be answered: How do they route connections between the ports
> > and the two controllers?
> >
> > There may be some exceptions, but for the most part, the code in
> > ehci-hcd was written assuming that only PCI-based controllers will have
> > companions.  If you want to make an exception for loongson-2k0500, you
> > will need to figure out how to get it to work.
> Loongson-2K0500 use EHCI/OHCI with platform bus, while
> Loongson-2K1000/2000 use EHCI/OHCI with PCI bus. They use the same USB
> IP cores, so the route connections are probably the same.

With PCI we know exactly which companion controller each port is 
connected to.  Is that true in your situation?

Or do you have only one companion controller?

For that matter, how many USB ports do these systems have?  Are some of 
them USB-1 only or USB-2 only?

> > Have you tested any of those systems to see how they behave if a USB-1
> > device is already plugged in and running when the ehci-hcd driver gets
> > loaded?

You did not answer this question.

There are other issues involving companion controllers, connected with 
hibernation.  You should take a look at commit 6d19c009cc78 ("USB: 
implement non-tree resume ordering constraints for PCI host 
controllers"), which was later modified by commit 05768918b9a1 ("USB: 
improve port transitions when EHCI starts up") and a few others.

Also, read through the current code in hcd-pci.c (for_each_companion(), 
ehci_pre_add(), ehci_post_add(), non_ehci_add(), ehci_remove(), and 
ehci_wait_for_companions()).  Your non-PCI system will need to implement 
some sort of equivalent to all these things.

Alan Stern

On Sun, Jan 4, 2026 at 12:41 AM Alan Stern <stern@rowland.harvard.edu> wrote:
>
> On Sat, Jan 03, 2026 at 11:57:47AM +0800, Huacai Chen wrote:
> > On Sat, Jan 3, 2026 at 11:33 AM Alan Stern <stern@rowland.harvard.edu> wrote:
> > > Since these systems don't use PCI, the question I raised earlier still
> > > needs to be answered: How do they route connections between the ports
> > > and the two controllers?
> > >
> > > There may be some exceptions, but for the most part, the code in
> > > ehci-hcd was written assuming that only PCI-based controllers will have
> > > companions.  If you want to make an exception for loongson-2k0500, you
> > > will need to figure out how to get it to work.
> > Loongson-2K0500 use EHCI/OHCI with platform bus, while
> > Loongson-2K1000/2000 use EHCI/OHCI with PCI bus. They use the same USB
> > IP cores, so the route connections are probably the same.
>
> With PCI we know exactly which companion controller each port is
> connected to.  Is that true in your situation?
>
> Or do you have only one companion controller?
>
> For that matter, how many USB ports do these systems have?  Are some of
> them USB-1 only or USB-2 only?
>
> > > Have you tested any of those systems to see how they behave if a USB-1
> > > device is already plugged in and running when the ehci-hcd driver gets
> > > loaded?
>
> You did not answer this question.
On Loongson-2K0500 (OHCI/EHCI with platform bus).

If ohci-platform loaded before ehci-platform:

[   30.530103] ohci-platform 1f058000.usb: Generic Platform OHCI controller
[   30.555362] ohci-platform 1f058000.usb: new USB bus registered,
assigned bus number 1
[   30.583586] ohci-platform 1f058000.usb: irq 28, io mem 0x1f058000
[   30.671500] hub 1-0:1.0: USB hub found
[   30.687929] hub 1-0:1.0: 4 ports detected
[   30.798553] Warning! ehci_hcd should always be loaded before
uhci_hcd and ohci_hcd, not after
[   31.015178] usb 1-4: new low-speed USB device number 2 using ohci-platform
[   31.090527] ehci-platform 1f050000.usb: EHCI Host Controller
[   31.107968] ehci-platform 1f050000.usb: new USB bus registered,
assigned bus number 2
[   31.143813] ehci-platform 1f050000.usb: irq 29, io mem 0x1f050000
[   31.227286] ehci-platform 1f050000.usb: USB 2.0 started, EHCI 1.00
[   31.248271] usb 1-4: device descriptor read/all, error -62
[   31.256845] hub 2-0:1.0: USB hub found
[   31.279310] hub 2-0:1.0: 4 ports detected
[   31.915149] usb 1-4: new low-speed USB device number 3 using ohci-platform
[   32.264765] input: YSPRINGTECH USB OPTICAL MOUSE as
/devices/platform/bus@10000000/1f058000.usb/usb1/1-4/1-4:1.0/0003:10C4:8105.0001/input/input0
[   32.374306] hid-generic 0003:10C4:8105.0001: input,hidraw0: USB HID
v1.11 Mouse [YSPRINGTECH USB OPTICAL MOUSE] on
usb-1f058000.usb-4/input0

If ehci-platform loaded before ohci-platform:

[   30.724394] ehci-platform 1f050000.usb: EHCI Host Controller
[   30.743839] ehci-platform 1f050000.usb: new USB bus registered,
assigned bus number 1
[   30.775857] ehci-platform 1f050000.usb: irq 28, io mem 0x1f050000
[   30.811297] ehci-platform 1f050000.usb: USB 2.0 started, EHCI 1.00
[   30.829172] hub 1-0:1.0: USB hub found
[   30.847397] hub 1-0:1.0: 4 ports detected
[   30.934190] ohci-platform 1f058000.usb: Generic Platform OHCI controller
[   30.959877] ohci-platform 1f058000.usb: new USB bus registered,
assigned bus number 2
[   30.987617] ohci-platform 1f058000.usb: irq 29, io mem 0x1f058000
[   31.080419] hub 2-0:1.0: USB hub found
[   31.092038] hub 2-0:1.0: 4 ports detected
[   31.407288] usb 2-4: new low-speed USB device number 2 using ohci-platform
[   31.741276] input: YSPRINGTECH USB OPTICAL MOUSE as
/devices/platform/bus@10000000/1f058000.usb/usb2/2-4/2-4:1.0/0003:10C4:8105.0001/input/input0
[   31.815422] hid-generic 0003:10C4:8105.0001: input,hidraw0: USB HID
v1.11 Mouse [YSPRINGTECH USB OPTICAL MOUSE] on
usb-1f058000.usb-4/input0

"new low-speed USB device number 3 using ohci-platform" only displayed
once and "usb 1-4: device descriptor read/all, error -62" disappears
in this case.

So I think we need a softdep between ohci-platform/uhci-platform and
ehci-platform, which is similar to the PCI case.

>
> There are other issues involving companion controllers, connected with
> hibernation.  You should take a look at commit 6d19c009cc78 ("USB:
> implement non-tree resume ordering constraints for PCI host
> controllers"), which was later modified by commit 05768918b9a1 ("USB:
> improve port transitions when EHCI starts up") and a few others.
>
> Also, read through the current code in hcd-pci.c (for_each_companion(),
> ehci_pre_add(), ehci_post_add(), non_ehci_add(), ehci_remove(), and
> ehci_wait_for_companions()).  Your non-PCI system will need to implement
> some sort of equivalent to all these things.
At least for the device probe, a softdep seems enough.

Huacai

>
> Alan Stern

On Sat, Jan 10, 2026 at 12:05:19PM +0800, Huacai Chen wrote:
> So I think we need a softdep between ohci-platform/uhci-platform and
> ehci-platform, which is similar to the PCI case.

Yes, on your platform.  But not on other platforms.  (For example, not 
on a platform that doesn't have an EHCI controller.)

I think the best way to do this is to create a new CONFIG_EHCI_SOFTDEPS 
Kconfig symbol, and add the soft dependency only if the symbol is 
defined.  Normally it will be undefined by default, but on your platform 
(and any others that need it) you can select it.

How does that sound?

> > There are other issues involving companion controllers, connected with
> > hibernation.  You should take a look at commit 6d19c009cc78 ("USB:
> > implement non-tree resume ordering constraints for PCI host
> > controllers"), which was later modified by commit 05768918b9a1 ("USB:
> > improve port transitions when EHCI starts up") and a few others.
> >
> > Also, read through the current code in hcd-pci.c (for_each_companion(),
> > ehci_pre_add(), ehci_post_add(), non_ehci_add(), ehci_remove(), and
> > ehci_wait_for_companions()).  Your non-PCI system will need to implement
> > some sort of equivalent to all these things.
> At least for the device probe, a softdep seems enough.

Does this platform support hibernation at all?

Alan Stern

On Sat, Jan 10, 2026 at 11:00 PM Alan Stern <stern@rowland.harvard.edu> wrote:
>
> On Sat, Jan 10, 2026 at 12:05:19PM +0800, Huacai Chen wrote:
> > So I think we need a softdep between ohci-platform/uhci-platform and
> > ehci-platform, which is similar to the PCI case.
>
> Yes, on your platform.  But not on other platforms.  (For example, not
> on a platform that doesn't have an EHCI controller.)
For the PCI case, OHCI without EHCI is also possible? So I think they
are similar.

>
> I think the best way to do this is to create a new CONFIG_EHCI_SOFTDEPS
> Kconfig symbol, and add the soft dependency only if the symbol is
> defined.  Normally it will be undefined by default, but on your platform
> (and any others that need it) you can select it.
>
> How does that sound?
From my point of view, keeping it simple may be better. I think an
unconditional softdep is harmless.

>
> > > There are other issues involving companion controllers, connected with
> > > hibernation.  You should take a look at commit 6d19c009cc78 ("USB:
> > > implement non-tree resume ordering constraints for PCI host
> > > controllers"), which was later modified by commit 05768918b9a1 ("USB:
> > > improve port transitions when EHCI starts up") and a few others.
> > >
> > > Also, read through the current code in hcd-pci.c (for_each_companion(),
> > > ehci_pre_add(), ehci_post_add(), non_ehci_add(), ehci_remove(), and
> > > ehci_wait_for_companions()).  Your non-PCI system will need to implement
> > > some sort of equivalent to all these things.
> > At least for the device probe, a softdep seems enough.
>
> Does this platform support hibernation at all?
LS2K500 is an embedded chip, it may or may not support hibernation,
but we haven't used hibernation.

Huacai

>
> Alan Stern

On Sun, Jan 11, 2026 at 09:54:46AM +0800, Huacai Chen wrote:
> On Sat, Jan 10, 2026 at 11:00 PM Alan Stern <stern@rowland.harvard.edu> wrote:
> >
> > On Sat, Jan 10, 2026 at 12:05:19PM +0800, Huacai Chen wrote:
> > > So I think we need a softdep between ohci-platform/uhci-platform and
> > > ehci-platform, which is similar to the PCI case.
> >
> > Yes, on your platform.  But not on other platforms.  (For example, not
> > on a platform that doesn't have an EHCI controller.)
> For the PCI case, OHCI without EHCI is also possible? So I think they
> are similar.

That's a good point.

> > I think the best way to do this is to create a new CONFIG_EHCI_SOFTDEPS
> > Kconfig symbol, and add the soft dependency only if the symbol is
> > defined.  Normally it will be undefined by default, but on your platform
> > (and any others that need it) you can select it.
> >
> > How does that sound?
> From my point of view, keeping it simple may be better. I think an
> unconditional softdep is harmless.

Submit your patch and let's see what Greg thinks.  You should include 
that log extract with the extra disconnect/reconnect messages in the 
patch description, to indicate clearly what you want to prevent.

Alan Stern

Hi,

在 2025/12/30 16:15, Greg Kroah-Hartman 写道:
> 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@vger.kernel.org
>> Reported-by: Shengwen Xiao <atzlinux@sina.com>
>> Signed-off-by: Huacai Chen <chenhuacai@loongson.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?
In Debian kernel config, the USB driver module is config as module.

I meet this warning info in my Loongarch machine 3A6000 on Debian:

[    1.119467] Warning! ehci_hcd should always be loaded before uhci_hcd and ohci_hcd, not after

I hope this warning can fix in my Loongarch machine.

> 
> And I really should just go revert 05c92da0c524 ("usb: ohci/uhci - add
> soft dependencies on ehci_pci") as well, that feels wrong too.
> 
> thanks,
> 
> greg k-h

Is there more better way to fix this Warning info?


BTW: I'm not a kernel developer, just a Loongarch linux user.

thanks,
-- 
肖盛文 xiao sheng wen -- Debian Developer(atzlinux)
Debian QA page: https://qa.debian.org/developer.php?login=atzlinux%40debian.org
GnuPG Public Key: 0x00186602339240CB