[PATCH v2 1/2] usb: ehci-mx6: move mode set/detect to probe

[Tim Harvey]

On Fri, Jul 2, 2021 at 3:18 PM Marek Vasut <marex at denx.de> wrote:
>
> On 7/2/21 11:44 PM, Tim Harvey wrote:
> > On Fri, Jul 2, 2021 at 12:53 PM Marek Vasut <marex at denx.de> wrote:
> >>
> >> On 7/2/21 9:43 PM, Tim Harvey wrote:
> >>> On Fri, Jul 2, 2021 at 12:17 PM Marek Vasut <marex at denx.de> wrote:
> >>>>
> >>>> On 7/2/21 2:15 AM, Tim Harvey wrote:
> >>>>> There is no need to set and/or detect mode in of_to_plat
> >>>>
> >>>> Are you absolutely sure of that ?
> >>>>
> >>>> It used to be necessary to know the core mode early to determine which
> >>>> driver (the gadget or host) to probe, that's why this code was in
> >>>> of_to_plat.
> >>>>
> >>>
> >>> Marek,
> >>>
> >>> I can't find a reason for the core mode to be known early and have
> >>> tested it both with host and gadget mode on IMX6 and IMX8MM. Fabio has
> >>> tested this change also (from another thread) with SPL SDP on IMX8MM
> >>> (granted the SPL is not using DM_USB for that).
> >>>
> >>> It appears I accidentally forgot to cc the uboot list so I'll need to
> >>> resend this at any rate.
> >>
> >> If I recall it correctly, the mode determination happened early because
> >> it was necessary to find out which driver to probe (this one, or the
> >> samsung gadget one) before it actually probed. I'm not sure myself if
> >> this is still even applicable.
> >
> > Marek,
> >
> > When I tested UMS with this series on imx6 based gwventana I had to
> > troubleshoot a regression caused when I switched to DM_USB and found
> > that the gadget driver isn't probed until you issue the ums command. I
> > don't know if this helps reduce your hesitation here.
>
> Do I understand it correctly that, because you had to debug a
> regression, this patch should be OK ? That implication there is a bit odd.
>

Not at all... My regression had to do with the fact that DM_USB uses
the 'usb0' alias to get to the USB OTG controller (which I didn't have
defined right). I merely pointed out that I had to poke around at the
code enough to realize the device controller didn't get probed until
you use the ums command. I didn't realize my regression until I set
out to test gadget mode so that I could resubmit this series and let
you know that I had tested both host and gadget mode on the boards I
have.

> What I am asking is whether you considered all the things which can go
> wrong with this still messy driver, that's all.

Oh I most definitely will never be able to consider everything as you
point out the driver is a complete mess and it supports a large
variety of SoC's and configurations. All I can do is make my best
effort to look for possible issues (which I've done), test (which I've
done), and post for review.

>
> > I'm not sure what else you want me to do with this - personally I
> > would like to see some more maintainers of boards using ehci-mx6 chime
> > in (mx7?) with testing results showing host and device un-affected. I
> > only have imx6q/imx6dl/imx8mm/imx8mn to test with here.
>
> The other option is to put it into next and see whether someone
> complains. I am banking toward that option.

By 'next' do you mean it sits in a branch that never gets merged or
are you saying it gets merged after v2021.07? I would agree it should
not be merged this late into v2021.07 but if it sits in a branch
that's never merged to master it will never get tested.

Tim