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