[U-Boot] [PATCH v1 3/3] cmd: usb gadget: Add a command to bind a USB gadget driver to a UDC port

[Simon Glass]

Hi Jean-Jacques,

On 12 June 2018 at 03:31, Jean-Jacques Hiblot <jjhiblot at ti.com> wrote:
> Hi,
>
>
> On 08/06/2018 23:59, Simon Glass wrote:
>>
>> Hi,
>>
>> On 7 June 2018 at 01:39, Lukasz Majewski <lukma at denx.de> wrote:
>>>
>>> Hi Jean-Jacques,
>>>
>>>> Most of the time the UDC is bound to a driver when a dedicated
>>>> command is executed, like 'dfu'. But the ethernet gadget driver must
>>>> be bound by calling usb_ether_init() in the code otherwise the USB
>>>> ethernet adapter is not visible to the ethernet core.
>>>>
>>>> In DM context, the platform code should not be used to bind UDC to a
>>>> particular driver, so adding a new command to bind a USB device port
>>>> to a driver.
>>>>
>>>> usage example:
>>>> usbdev bind 0 usb_ether
>>>> usbdev unbind 0
>>>
>>> I would prefer a comment from Simon (so adding him to CC) - as it looks
>>> to me that we shall try to use DM to avoid adding separate commands for
>>> binding.
>>
>> We could perhaps introduce 'bind' and 'unbind' commands with similar
>> arguments?
>
> What kind of parameters should be used to identify the device to bind ?
> I see 2 possible options:
> - node paths: bind /opc/omap_dwc3 at 48380000/usb at 483d0000 usb_ether
> - device class + index: bind usb_dev 0 usb_ether.
>
> The last one looks a lot like what I proposed, only more generic, but
> requires creating a table to match a string with a UCLASS id.
> The first is more precise but IMO less user friendly.

We can look up a uclass by name, so your second open should work OK.
It matches the current U-Boot approach pretty well two since most
commands work this way.

However, I have sometimes thought (with driver model) of supporting
the first option as a fallback.

You could in fact have a function that supports both:

1. Option 1 - it does a global search for a device with that DT node
2. Option 2 - it does a uclass_get_device_by_seq() call

I agree that option 2 is likely to be much preferred in normal use.

Regards,
Simon