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:	Wed, 25 May 2011 10:07:25 -0700 (PDT)
From:	"Brokhman Tatyana" <tlinder@...eaurora.org>
To:	"Alan Stern" <stern@...land.harvard.edu>
Cc:	"Tanya Brokhman" <tlinder@...eaurora.org>, 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

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.

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

>Otherwise, if all of them
> support high speed and CONFIG_USB_GADGET_DUALSPEED is enabled then set
> composite_driver.speed to USB_SPEED_HIGH.  Otherwise set it to
> USB_SPEED_FULL.
>
> Alan Stern
>

Thanks,
Tanya Brokhman
-- 
Sent by an consultant of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.


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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ