On Fri, Jul 2, 2021 at 3:18 PM Marek Vasut <ma...@denx.de> wrote: > > On 7/2/21 11:44 PM, Tim Harvey wrote: > > On Fri, Jul 2, 2021 at 12:53 PM Marek Vasut <ma...@denx.de> wrote: > >> > >> On 7/2/21 9:43 PM, Tim Harvey wrote: > >>> On Fri, Jul 2, 2021 at 12:17 PM Marek Vasut <ma...@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