linux-kernel - Re: [PATCHv2] usb: gadget: get rid of USB_GADGET_DUALSPEED and USB_GADGET

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.v0gi7koy3l0zgt@mnazarewicz-glaptop>
Date:	Fri, 19 Aug 2011 12:53:34 +0200
From:	"Michal Nazarewicz" <mina86@...a86.com>
To:	"Alan Stern" <stern@...land.harvard.edu>
Cc:	"Sergei Shtylyov" <sshtylyov@...sta.com>,
	"Felipe Balbi" <balbi@...com>,
	"Sebastian Andrzej Siewior" <bigeasy@...utronix.de>,
	"Yang Rui Rui" <ruirui.r.yang@...to.com>,
	"Greg Kroah-Hartman" <gregkh@...e.de>, linux-usb@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCHv2] usb: gadget: get rid of USB_GADGET_DUALSPEED and
 USB_GADGET_SUPERSPEED

On Thu, 18 Aug 2011 22:30:14 +0200, Alan Stern <stern@...land.harvard.edu>  
wrote:
> Okay, that line was probably all right, but it seems that something
> else needs to be changed.  In a composite gadget, if none of the
> function drivers support SuperSpeed then we don't want
> composite_driver.speed to be set to USB_SPEED_SUPER.  It would be
> foolish to allow the UDC to connect at a speed which would make the
> gadget useless.

OK, so it seems I was misunderstanding your comment all along, but
that was nothing a good night sleep couldn't fix. :P

So, what you are saying is that when passed to the UDC driver (ie.
by calling usb_gadget_probe_driver()) the usb_gadget_driver structure
must have speed no higher then what the UDC supports, right?  And in
that case, it's not composite specific but affects all the gadgets.

In that case, I think that usb_gadget_probe_driver() itself needs to be
changed since prior to this function we don't know which gadget the
gadget driver will be bound to.  Ie. something as follows could be added
somewhere there:

   driver->speed = min(driver->speed, udc->gadget->speed)

Does that sound like it makes sense?

At this point though, gadget drivers need to be aware that
usb_gadget_probe_driver() may change the speed field.  It should not
be a problem since, as far as I can tell, all gadgets expect for g_ffs
call usb_gadget_probe_driver() only once and in case of g_ffs this can
be solved at composite level.

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