bind/unbind command not working for usb_ether

[Marek Vasut]

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.