On 2/15/23 01:11, Tim Harvey wrote:
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.
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.