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]

Date:	Thu, 25 Aug 2011 14:46:55 +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 Thu, 25 Aug 2011 01:04:19 +0200, Felipe Balbi <balbi@...com> wrote:
> there's one catch. As of today, we always start UDCs with data pullups
> connected, which means that we could connect to a host even before a
> gadget driver is loaded. My point in moving to udc_start/udc_stop is
> that the above would be take care of. See udc-core.c: [...]

Honestly I'm not quite sure why udc_start/udc_stop is needed here.  Even
without those the UDC driver can start with all hw disabled and turn it
on only after the gadget driver's bind callback finishes.

> If all UDCs are converted to udc_start()/udc_stop() we get the guarantee
> that they will only conect to host after gadget driver is fully loaded
> for free.

> We can also, finally, properly use the usb_function_deactivate/
> usb_function_activate properly. So for each registered function,
> composite.c calls usb_function_deactivate() and function is _required_
> to call usb_function_activate when it's ready.

I'm not really sure why that would be beneficial.  Also, it would still
require disconnect-connect cycle if some function decides to (de)activate
itself while gadget is connected.

> Then, when on gadget driver's bind() we can take this kind of speed
> decision and pass that on to UDC driver.

So can we leave things as they are for now and wait for UDCs to be  
converted
and once this is done, do all kinds of magic we want in copomiset's bind
callback?

-- 
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/