bind/unbind command not working for usb_ether

[Tim Harvey]

On Tue, Feb 14, 2023 at 4:31 PM Marek Vasut <marex at denx.de> wrote:
>
> On 2/15/23 01:11, Tim Harvey wrote:
> > On Sat, Aug 13, 2022 at 7:59 AM Simon Glass <sjg at chromium.org> wrote:
> >>
> > <snip>
> >>>
> >>> Simon,
> >>>
> >>> Now that we have identified a fix needed to uclass_get_by_name to fix
> >>> the dm bind command, can you comment on the other issue we have run
> >>> into trying to use usb_ether?
> >>>
> >>> Here's an example with some debugging:
> >>> Ventana > net list
> >>> device_probe ethernet at 2188000 flags=0x1043
> >>> eth0 : ethernet at 2188000 00:d0:12:f3:f2:f5 active
> >>> Ventana > bind usb 0 usb_ether
> >>> Ventana > net list
> >>> eth0 : ethernet at 2188000 00:d0:12:f3:f2:f5 active
> >>> eth1 : usb_ether 00:00:00:00:00:00
> >>> Ventana > setenv ethact eth1
> >>> Ventana > ping 192.168.1.146
> >>> device_probe ethernet at 2188000 flags=0x1043
> >>> device_probe usb_ether flags=0x4a
> >>> device_probe usb at 2184000 flags=0x1042
> >>> device_probe bus at 2100000 flags=0x1051
> >>> device_probe usbotggrp flags=0x40
> >>> device_probe iomuxc at 20e0000 flags=0x1041
> >>> device_probe iomuxc at 20e0000 flags=0x1041
> >>> device_probe regulator-usb-otg-vbus flags=0x52
> >>> device_probe gpio at 20a4000 flags=0x1043
> >>> device_probe root_driver flags=0x1041
> >>> device_probe iomuxc at 20e0000 flags=0x1041
> >>> usb_eth_probe usb_ether
> >>> usb_eth_start
> >>> usb_setup_ehci_gadget
> >>> usb_setup_ehci_gadget removing old device 'usb at 2184000'
> >>> device_remove usb at 2184000
> >>> device_remove usb_ether
> >>> usb_eth_stop
> >>> usb_setup_ehci_gadget probing 'usb at 2184000'
> >>> device_probe usb at 2184000 flags=0x42
> >>> device_probe bus at 2100000 flags=0x1051
> >>> device_probe usbotggrp flags=0x1041
> >>> device_probe regulator-usb-otg-vbus flags=0x1053
> >>> usb_setup_ehci_gadget done
> >>> ^^^ hangs here - notice usb controller and the usb_ether child were
> >>> removed then usb controller probed again (but not usb_ether)
> >>>
> >>> fbeceb260232 ("dm: usb: Allow setting up a USB controller as a
> >>> device/gadget") adds the usb_setup_ehci_gadget() function which
> >>> removes the old USB controller device (and its usb_ether child) then
> >>> probes only the USB controller leaving the usb_ether device un-probed.
> >>> The commit log makes it sound like something isn't complete:
> >>>
> >>>      Some controllers support OTG (on-the-go) where they can operate as either
> >>>      host or device. The gadget layer in U-Boot supports this.
> >>>
> >>>      While this layer does not interact with driver model, we can provide a
> >>>      function which sets up the controller in the correct way. This way the code
> >>>      at least builds (although it likely will not work).
> >>>
> >>> I'm not clear why the USB controller (and children) need to be removed
> >>> here. If I comment out the removal and re-probe of the controller
> >>> usb_ether then works fine:
> >>>
> >>> diff --git a/drivers/usb/host/usb-uclass.c b/drivers/usb/host/usb-uclass.c
> >>> index 27e2fc6fcd36..0882641b51b0 100644
> >>> --- a/drivers/usb/host/usb-uclass.c
> >>> +++ b/drivers/usb/host/usb-uclass.c
> >>> @@ -399,6 +399,7 @@ int usb_setup_ehci_gadget(struct ehci_ctrl **ctlrp)
> >>>          ret = uclass_find_first_device(UCLASS_USB, &dev);
> >>>          if (ret)
> >>>                  return ret;
> >>> +#if 0
> >>>          ret = device_remove(dev, DM_REMOVE_NORMAL);
> >>>          if (ret)
> >>>                  return ret;
> >>> @@ -408,6 +409,7 @@ int usb_setup_ehci_gadget(struct ehci_ctrl **ctlrp)
> >>>          ret = device_probe(dev);
> >>>          if (ret)
> >>>                  return ret;
> >>> +#endif
> >>>          *ctlrp = dev_get_priv(dev);
> >>>
> >>>          return 0;
> >>>
> >>> Why was it necessary to remove the USB controller and children and reprobe?
> >>
> >> +Marek Vasut who may know more
> >>
> >> I suspect that this is a bit of a hack to get the device running after
> >> it is swtiched from host to device mode?
> >>
> >> The gadget side of things should really move to driver model.
> >>
> >
> > Marek,
> >
> > Do you know if there is a proper way of binding a usb_ether gadget
> > driver at runtime so as to get USB over ethernet gadget support?
> >
> > 'bind usb 0 usb_ether' does bind the driver but when you try to use it
> > the usb controller is removed which causes a failure.
>
> Look around patch
>
> [PATCH v2] usb: gadget: ether: split start/stop from init/halt
>
> which is a huge bag of subtle issues in its own right. I think it is
> moving in the right direction, except there seem to be additional bugs
> lurking around, which need to be addressed first instead of papering
> over them.

Marek,

Thanks for the reference - I'll take a look at Niel's patch. It
doesn't address what I'm seeing but it seems to aim to resolve similar
issues.

Best Regards,

Tim