On Mon, 9 Jan 2012, Sarah Sharp wrote: > > 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. > > Yes, I think that patch would be good to have. However, it doesn't help > the case where a system has two host controllers, one with driver SG > support and one without SG support. For example, you could have an > embedded board with an MUSB host and an xHCI host. If the user > accidentally plugs in their USB 3.0 UAS device into the MUSB port, then > the UAS driver can still claim the USB 2.0 UAS device. Actually it does help: In that situation, the uas driver can print a warning message telling the user to plug the device into a different controller. We already do something very much like that when a high-speed-capable device is plugged into a full-speed controller; see check_highspeed() in hub.c. Is there any way to do the same thing when a SuperSpeed-capable device is plugged into a USB <= 2.0 controller? > Even in the case where the BoT interface is the first alt setting, the > UAS driver could race against the BoT driver and claim the device first. > So I think a necessary patch would be to check for SG support in the UAS > probe function and fail it if the host doesn't have SG support. Then > the BoT driver will just take over. Yes, that's what I was proposing. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
