On 5/13/2020 10:39 AM, Alan Stern wrote:

On Wed, May 13, 2020 at 07:05:05PM +0200, Greg Kroah-Hartman wrote:

quoted

On Wed, May 13, 2020 at 09:31:11AM -0700, Florian Fainelli wrote:

quoted

On 5/13/2020 9:27 AM, Greg Kroah-Hartman wrote:

quoted

On Wed, May 13, 2020 at 08:08:07AM -0700, Florian Fainelli wrote:

quoted

On 5/13/2020 5:26 AM, Greg Kroah-Hartman wrote:

quoted

On Tue, May 12, 2020 at 11:00:15AM -0400, Al Cooper wrote:

quoted

Some BRCMSTB USB chips have an XHCI, EHCI and OHCI controller
on the same port where XHCI handles 3.0 devices, EHCI handles 2.0
devices and OHCI handles <2.0 devices. Currently the Makefile
has XHCI linking at the bottom which will result in the XHIC driver
initalizing after the EHCI and OHCI drivers and any installed 3.0
device will be seen as a 2.0 device. Moving the XHCI linking
above the EHCI and OHCI linking fixes the issue.

What happens if all of these are modules and they are loaded in a
different order?  This makefile change will not help with that, you need
to have logic in the code in order to properly coordinate this type of
mess, sorry.

I believe we should be using module soft dependencies to instruct the
module loaders to load the modules in the correct order, so something
like this would do (not tested) for xhci-plat-hcd.c:

MODULE_SOFTDEP("post: ehci-hcd ohci-hcd");

and I am not sure whether we need to add the opposite for ehci-hcd and
ohci-hcd:

MODULE_SOFTDEP("pre: xhci-plat-hcd");

That's a nice start, but what happens if that isn't honored?  This
really needs to work properly for any order as you never can guarantee
module/driver loading order in a system of modules.

I also suggested that device links may help, though I am not sure. What
do you suggest to be done?

No idea.  device links will help if you defer the probe properly until
you see the proper drivers binding correctly.

I suspect that in general there is no way to do this properly.

We can't modify ehci-hcd and ohci-hcd to make them wait.  In fact, for 
all they know, xhci-hcd will _never_ be loaded.

One thing that might be possible (although not all platforms may support 
it) is if xhci-hcd could somehow disconnect all devices attached to a 
peer port when it starts up.  But that would be disruptive to any 
devices that aren't USB-3.

We faced a very similar ordering problem between ehci-hcd and 
[ou]hci-hcd many years ago, and we never found a good solution.  
We did arrange the link order so that ehci-hcd precedes the others, and 
we added a warning message to ehci-hcd which gets printed if the module 
initialization routine runs after [ou]hci-hcd is loaded.  Also, there 
are MODULE_SOFTDEP lines in ohci-pci.c and uhci-pci.c.

Given that these modules are used on specific SoC platforms, where we
usually provide a reference implementation of user space and kernel
space and documentation, it seems to me that the MODULE_SOFTDEP(),
despite being a hint and best effort from user space module loaders is
probably acceptable.
-- 
Florian