Hi, On Mon, Jan 09, 2012 at 11:21:15AM -0500, Alan Stern wrote: > > > When the most commonly used HCDs all support SG, that should be good > > > enough. UAS can refuse to bind if the host controller doesn't work > > > with SG. And similarly, in that situation usb-storage should accept a > > > device that has both BOT and UAS altsettings. > > > > > > It would be nice to have a Kconfig variable (CONFIG_USB_HCD_HAS_SG or > > > something like that) which would be selected by all the HC drivers > > > supporting SG, and which UAS would depend on. That way it would be > > > impossible to build the UAS driver on systems where none of the HCDs > > > will work with it. > > > > I'm not sure that will create a nice user experience, specially when a > > user decides he wants to back up some data from his old PC (which is > > OHCI only) to his brand new USB3.0 UASP Storage Device. > > Why wouldn't the user have a nice experience? > > > Well, he can't expect nice throughput anyway, but he will definitely > > expect it to work since that's one of USB's flagships: Plug&Play. > > Why wouldn't it work? UAS storage devices also have to support BOT. > Otherwise they wouldn't work with Windows XP. Indeed, it's even very clear on UASP specification: "For [USB2] backward compatibility, the device shall present [BOT] as alternate interface zero (primary) and [UAS] as alternate interface one (secondary). A device which does not need backward compatibility with [BOT] shall present [UAS] as alternate interface zero. In [USB2] systems, the [BOT] driver or an associated filter driver may need to issue a SET INTERFACE request for alternate interface one and then allow the [UAS] driver to load." So a device which does not need backward compatibility is that which will not bind. We are actually doing a lot by supporting UASP on USB2 systems ;-) Nevermind my concern :-) -- balbi
Attachment:
signature.asc
Description: Digital signature
