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

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.

good luck!

greg k-h