On Sat, Aug 13, 2022 at 7:59 AM Simon Glass <s...@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@2188000 flags=0x1043
> > eth0 : ethernet@2188000 00:d0:12:f3:f2:f5 active
> > Ventana > bind usb 0 usb_ether
> > Ventana > net list
> > eth0 : ethernet@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@2188000 flags=0x1043
> > device_probe usb_ether flags=0x4a
> > device_probe usb@2184000 flags=0x1042
> > device_probe bus@2100000 flags=0x1051
> > device_probe usbotggrp flags=0x40
> > device_probe iomuxc@20e0000 flags=0x1041
> > device_probe iomuxc@20e0000 flags=0x1041
> > device_probe regulator-usb-otg-vbus flags=0x52
> > device_probe gpio@20a4000 flags=0x1043
> > device_probe root_driver flags=0x1041
> > device_probe iomuxc@20e0000 flags=0x1041
> > usb_eth_probe usb_ether
> > usb_eth_start
> > usb_setup_ehci_gadget
> > usb_setup_ehci_gadget removing old device 'usb@2184000'
> > device_remove usb@2184000
> > device_remove usb_ether
> > usb_eth_stop
> > usb_setup_ehci_gadget probing 'usb@2184000'
> > device_probe usb@2184000 flags=0x42
> > device_probe bus@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.
Best Regards,
Tim
