linux-kernel - RE: [PATCH v12 7/8] usb: Adding SuperSpeed support to dummy

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: <Pine.LNX.4.44L0.1105251316170.1987-100000@iolanthe.rowland.org>
Date:	Wed, 25 May 2011 13:29:14 -0400 (EDT)
From:	Alan Stern <stern@...land.harvard.edu>
To:	Brokhman Tatyana <tlinder@...eaurora.org>
cc:	balbi@...com, 'Sarah Sharp' <sarah.a.sharp@...ux.intel.com>,
	<greg@...ah.com>, <linux-usb@...r.kernel.org>,
	<linux-arm-msm@...r.kernel.org>, <ablay@...eaurora.org>,
	'open list' <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH v12 7/8] usb: Adding SuperSpeed support to dummy_hcd

On Wed, 25 May 2011, Brokhman Tatyana wrote:

> Hi Alan,
> 
> > I have looked this over more carefully.  It turns out that both of you
> > have misunderstood the purpose of CONFIG_USB_GADGET_DUALSPEED (and by
> > extension, CONFIG_USB_GADGET_SUPERSPEED).  In fact, the existing
> > Kconfig file is also wrong.
> >
> > The _only_ reason for CONFIG_USB_GADGET_DUALSPEED is so that gadget
> > drivers can use conditional compilation to avoid including the
> > high-speed descriptors when the UDC doesn't support high-speed
> > operation.  That's all.  This means that the
> > CONFIG_USB_GAGDET_DUALSPEED option does not need to be
> > user-controllable in Kconfig.  It should default to N, and UDC drivers
> > that support high speed should select it.
> >
> > The same should be true of CONFIG_USB_GADGET_HIGHSPEED.  It should not
> > be user-controllable.  It should default to N, and UDC drivers that
> > support SuperSpeed operation (after these patches, only dummy-hcd)
> > should select it.
> 
> Ok, agreed. Thanks for the clarification. I saw your patch, I'll update
> mine in the same way.

Good.  If Felipe doesn't object to my patch, I'll send it to Greg.

> > There remains the other question, about whether composite_driver.speed
> > should be set to USB_SPEED_SUPER.  I think the matter can be settled at
> > runtime.  Iterate through all the function drivers; if all of them
> > support SuperSpeed and CONFIG_USB_GADGET_SUPERSPEED is enabled then set
> > composite_driver.speed to USB_SPEED_SUPER.
> 
> Not sure how to verify this. I need to know whether the driver that is
> registered with the UDC is SS or not. This is before the function drivers
> are binded to it. So how can I verify at that point that the function
> drivers that will bind to this driver will provide SS descriptors?
> (I'm sorry, I don't have the ability to view the code at the moment and
> due to the time differences between us I don't want to leave this question
> for tomorrow and loose another day...)

I'm not sure about this either.  I have never used the composite
framework so I'm not familiar with its details.  This has to be decided
before the composite gadget driver registers with the UDC driver ...  
and surely that can't happen until all the function drivers have
registered with the composite driver?  After all, the gadget can't be
enumerated until all the function drivers are registered.

Maybe this logic can be put in usb_add_function()?  That routine
already deals with issues involving device speed and available
descriptors.

Alan Stern

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