RE: [PATCH 1/2] usb: gadget: udc-core: independent registration of gadgets and gadget drivers

[Krzysztof Opasiak]

> -----Original Message-----
> From: linux-usb-owner@xxxxxxxxxxxxxxx [mailto:linux-usb-
> owner@xxxxxxxxxxxxxxx] On Behalf Of Krzysztof Opasiak
> Sent: Monday, February 09, 2015 7:06 PM
> To: 'Alan Stern'; 'Ruslan Bilovol'; 'Peter Chen'
> Cc: linux-usb@xxxxxxxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx;
> 'Balbi, Felipe'; gregkh@xxxxxxxxxxxxxxxxxxx; Andrzej Pietrasiewicz
> Subject: RE: [PATCH 1/2] usb: gadget: udc-core: independent
> registration of gadgets and gadget drivers
> 
> Hi,
> 
> (... snip ...)
> 
> >
> > > > You don't need all this stuff.  What's the point of keeping
> > track of
> > > > names?  If there are any unbound gadget drivers pending, a
> > newly
> > > > registered UDC should bind to the first one available.
> > >
> > > It's because gadget driver may be bound to usb_gadget in two
> > ways:
> > >  - standard way - in this case any available udc will be picked
> > up
> > >  - by name of udc, in this case only matching udc will be
> picked
> > up
> >
> > Where did this "by name" feature come from?  You did not mention
> it
> > in
> > the patch description.
> >
> > Why bother matching by name?  Why not simply take the first
> > available
> > UDC?
> 
> Because you may have more than one udc. This would allow to pick
> one by
> name just like using configfs interface.
> 
> >
> > > Main feature of my path is not only deferred binding of gadget
> > driver,
> > > but also possibility to register/unregister udc at any time.
> > > This is useful for user who can load, for example, udc module
> > > if needed and unload it safely, not touching gadget driver.
> >
> > We can already do that with the existing code.  There's no need
> for
> > a
> > patch.
> >
> > Also, it's not clear that the existing gadget drivers will work
> > properly if they are unbound from one UDC and then bound again to
> > another one.  They were not written with that sort of thing in
> > mind.
> >
> 
> What you have described is one of basics configfs features.
> You should be able to bind and unbind your gadget whenever you want
> and it should work properly after doing:
> 
> ## create gadget
> $ echo "udc.0" > UDC
> $ echo "" > UDC
> $ echo "udc.1" > UDC
> 
> Function shouldn't care which udc it has been bound previously.
> Only current one is important and on each unbind each function
> should cleanup its state and prepare to be bound to another udc.
> Configfs interface doesn't prohibit this and I haven't seen any
> info about such restriction. If some function is not working in
> such situation there is a bug in that function and it should be
> fixed.
> 
> I have tried to test this on my odroid with dwc2 and dummy_hcd.
> Most of functions seems to be working but for example ecm isn't.

^ above is ok

> After some digging with Robert we found that it's always reusing
> endpoints received in first bind().

Fixup:

That's bullshit ignore it please. ecm_opts->bound is not used to take
endpoints but only to register net device. Went too far after short
reading.
All in all, ecm is not working when binding form one udc to another.
Don't know exact reason, but in my opinion it's more a bug than common
assumption.


-- 
Krzysztof Opasiak
Samsung R&D Institute Poland
Samsung Electronics
k.opasiak@xxxxxxxxxxx




--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/