linux-kernel - Re: [PATCHv3 2/4] usb: gadget: replace "is_dualspeed" with "max

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <op.v0oapawkvgw7ix@mnazarewicz-glaptop>
Date:	Tue, 23 Aug 2011 17:30:36 +0200
From:	"Michal Nazarewicz" <mnazarewicz@...gle.com>
To:	"Felipe Balbi" <balbi@...com>
Cc:	"Alan Stern" <stern@...land.harvard.edu>,
	"Sebastian Andrzej Siewior" <bigeasy@...utronix.de>,
	"Yang Rui Rui" <ruirui.r.yang@...to.com>,
	"Dave Young" <hidave.darkstar@...il.com>,
	linux-usb@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCHv3 2/4] usb: gadget: replace "is_dualspeed" with
 "max_speed"

>> On Tue, 23 Aug 2011 15:58:17 +0200, Felipe Balbi <balbi@...com> 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...

On Tue, 23 Aug 2011 17:05:48 +0200, Felipe Balbi <balbi@...com> wrote:
> 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 ?

But isn't that what's happening right now?  The gadget_driver structure
has a speed field which is set to the maximum speed the gadget driver
can handle.  Only after this is set, usb_gadget_probe_driver() is
called so at this point a SS UDC can figure out whether it needs to
turn pieces needed for SS support or not.


>>> 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 ;-)

Adding another attribute with the same show function seems easy, but
that's probably not elegant. ;)

> (please add a note on feature-removal-schedule too)

Yep!

-- 
Best regards,                                         _     _
.o. | Liege of Serenely Enlightened Majesty of      o' \,=./ `o
..o | Computer Science,  Michal "mina86" Nazarewicz    (o o)
ooo +-----<email/xmpp: mnazarewicz@...gle.com>-----ooO--(_)--Ooo--
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/