On Tue, 23 Aug 2011 15:58:17 +0200, Felipe Balbi <balbi@xxxxxx> wrote:All of the speed negotiation between composite.c and f_*.c should happen before even connecting to host
On Tue, Aug 23, 2011 at 04:15:08PM +0200, Michal Nazarewicz wrote:Yep, obviously. The usb_gadget_probe_driver() is called at the very and
once all the functions and everything is added so composite.c can do all
the analysis it wants and figure out the maximum speed.
>(before attaching data pullups, enabling IRQs, etc), that's exactly why
>me and Sebastian have decided (at that time off list) to add
>udc_start()/udc_stop() methods.
I don't really follow why those would be needed...
Ok, I guess I need to give the full picture here, my bad.
Let's say you have a SuperSpeed controller, but you know that this
particular gadget driver can only support fullspeed, so why do you need
to go through RX detection, HS chirp sequence and whatnot if you can
decide the maximum_speed before kickstarting the UDC's state machine ?
you already maximum_speed (below) and speed alone looses some extra
hint of what kind of information will be there. I think it's better to
change this to current_speed and make a symbolic link called 'speed'
which we can keep for the next 5 years and remove it in e.g. Linux v5.0
OK, I'll do that (as soon as I figure out/recall how to make symlinks that is ;) ).
yeah, I would have to go through the same re-education ;-)
(please add a note on feature-removal-schedule too)