[U-Boot] [PATCH] usb_ether: register usb ethernet gadget at each eth init

[Lei Wen]

Hi Vitaly,

On Mon, Nov 29, 2010 at 9:56 PM, Vitaly Kuzmichev <vkuzmichev at mvista.com> wrote:
> Hi Lei,
>
> Lei Wen wrote:
>> Hi Vitaly,
>> [...]
>>>> +     if (usb_gadget_register_driver(&eth_driver) < 0)
>>>> +             goto fail;
>>>
>>> You probably need then at least to remove usb_gadget_register_driver
>>> call from usb_eth_initialize. And add usb_gadget_unregister_driver in
>>> usb_eth_halt.
>>
>> I am afraid that remove usb_gadget_register_driver call from usb_eth_initialize
>> is not possible. For tftp as example, it would call eth_halt before
>> the eth_init.
>> If we do the remove behavior, the gadget still not valid yet in the
>> first eth_halt call
>> which would cause the uboot becomes halt.
>
> The gadget driver handles this properly. Right now it just does
> usb_gadget_disconnect which has no effect when no gadget was requested
> from the UDC driver yet.
> And additional calling of usb_gadget_unregister_driver will at most
> return an error.
>

For current ether.c state, there is no usb_gadget_unregister_driver in
it. Even it has, we still need
usb_gadget_register_driver call in each eth_init().

>>> For example, my UDC driver returns EBUSY if another gadget driver tries
>>> to register itself. (Yes, I do not want to have more than 1 gadget).
>>> With your patch the gadget driver will fail each time when initializing.
>>> Anyway if I "fix" my UDC driver some day the Ether gadget will try to
>>> register itself twice (and more times later). So I will have to protect
>>> it against this bad behavior.
>>
>> Two gadget example may comes from what I am using now.
>> I am current attempting to make the tftp and fastboot cowork togetther.
>> Since fastboot is a cool tool, I think people may want it beside they
>> still use the tftp.
>> Would that be enough convincing?:)
>>
>> I think the gadget driver should adopt like this to allow two gadget coexist.
>> And from gadget driver's review, the switch from one gadget to another
>> is easy, just
>> register it to another should be enough. Does it really need to return EBUSY?
>
> If the UDC (not a gadget) driver does not support more than 1 gadget
> driver in the same time it must return an error (EBUSY is fine for now)
> when another gadget tries to register itself.
Right, if at the same time certainly need to return error.

> The reason why does not it support 2 (and more) gadgets registered
> simultaneously is another question. Even if I fix this, your patch is
> not needed because the UDC driver will give USB requests to the
> appropriate gadget driver properly.
>
> I really do not understand what a problem with using 2 gadgets in the
> same time without your patch if the UDC driver supports this.
> Especially I do not understand...
>
Sorry, maybe I make a confused saying here. I don't mean to support two gadget
at the "same time", but to let one gadget could work after another
gadget is finished.
Like after tftp, I could use fastboot, or after return from fastboot,
I could still use the tftp.

>> it is neccessary to do the register each time the
>> eth begin to work to make usb gadget driver less confussed when
>> we want to use two different usb gadget at the same time.
>
> ...how can the gadget (or UDC?) driver be confused here?
> Right now I can tell that it will be more confused rather than less.
> I just can suppose that you are trying to implement something like
> switching active gadget driver in UDC driver which has only one variable
> to store info about gadget driver (rather than having an array at
> least). In this case you need to fix UDC driver rather than hacking all
> available gadget drivers.
> Also this way will not work when someone needs two gadgets active
> simultaneously, e.g. USB ether with USB serial.
>
The confused thing is for the ether.c would register its gadget at the
usb_eth_initialize() call,
which is a very begining of the uboot. If we use some other gadget,
like fastboot, it would take
place of gadget registered in the gadget driver. Then if we return to
the USB ether, for there is
no other chance to register itself, the ether gadget would use other
gadget setting to make the
ethernet connection. That is where the confussion start.

Best regards,
Lei