On Sat, Aug 13, 2022 at 7:59 AM Simon Glass sjg@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