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

[Jean-Jacques Hiblot]

On 13/06/2018 03:29, Simon Glass wrote:
> 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.
I've been working on this and have come up with a slightly different 
interface:

bind <node path> <driver name>
unbind <node path>
bind <class name> <index> <driver name>
unbind <class name> <index>


Interface with node path:
It is a symmetric interface:
example:
bind /ocp/ocp2scp at 483e8000 generic_simple_bus
unbind /ocp/ocp2scp at 483e8000


Interface with class/index:
This is by essence an asymmetric interface: the class/index pair is not 
the same for binding as for unbinding
example:
bind usb_dev_generic 0 usb_ether
unbind eth 1

While it makes sense, it may be a bit harder to use because of the asymmetry

JJ

>
> Regards,
> Simon
>