[PATCH v4 1/4] cmd: bind: Add unbind command with driver filter

[Tom Rini]

On Fri, Aug 04, 2023 at 07:01:46PM +0200, Miquel Raynal wrote:
> Hi Tom,
> 
> > > > >>> Well, what's needed / is it possible to get to the point where we don't
> > > > >>> _need_ to call bind/unbind for each of these cases? Is there something
> > > > >>> we're supposed to be setting in the DT that we aren't?    
> > > > >>
> > > > >> You do need to unbind the ethernet before using fastboot, always, with the 'unbind ethernet 0', you dont need the peripheral unbind/rebind part, so it should behave like before.    
> > > > > 
> > > > > And for my own understanding, why don't we need to bind a fastboot
> > > > > gadget?    
> > > > 
> > > > The fastboot command does that internally .  
> > > 
> > > This is not visible with dm tree and I did not find how to bind the
> > > fastboot gadget manually.
> > > 
> > > This makes the CLI clearly uneven and the internal code badly different
> > > between gadgets/commands. Why can't we have them both
> > > autoloaded/unloaded like before? I think I missed something which
> > > explains the rationale behind this series.  
> > 
> > They aren't both auto-loaded currently. We have a legacy call,
> > usb_ether_init(), in a few cases, so that gadget mode ethernet starts.
> > But this leads to the ref counting problems you encountered and
> > re-posted the rejected series for.
> 
> Ok, thanks for the additional details.
> 
> I don't understand why fastboot autoloads the correct gadget driver if
> there is none bound, while all network commands just fail to do that if
> we don't make the usb_ether_init() call manually.

Because "fastboot" or "dfu" are both being told (as part of their call)
"find usb gadget controller number X".  That's doing the bind.  Calling
usb_ether_init just takes the first controller and that's that (and so
could be / is wrong depending on the platform).

> I also don't understand why I need to unbind the ethernet gadget but I
> cannot bind the fastboot gadget.

You can't bind fastboot while ethernet is still configured.  It's in
use.  And we aren't a full blown operating system with the logic to have
multiple end points and devices configured and exposed.  I mean heck, we
don't keep the gadget interface up between network calls so on the host
side you need to re-configure the interface (or have something that's
bringing it up there again each time).  Which is why DFU or fastboot or
other "treat USB like USB" options tend to be more popular than "treat
USB like ethernet" work flows.

> My underlying question is: can we have a single approach for all
> drivers, or is it too complex today? Could it be possible, when we
> perform these autoloads, to look up the registered gadget and
> potentially unbind the one already in place before?

I would invite you to look in to this, yes.  No one objects to enhancing
the code, but the "functionality" you see on am33xx is as you've also
seen very broken in other ways, which is why it's not used virtually
anywhere else and instead the "bind" command is.  For example, if you
wanted to do this workflow on the new beagle devices, that's DWC3 and
where the "bind" command came from :)

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20230804/95900b68/attachment.sig>