Re: UAS support for hcd without sg support

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Jan 09, 2012 at 11:01:01AM -0500, Alan Stern wrote:
> On Mon, 9 Jan 2012, Sebastian Andrzej Siewior wrote:
> 
> > On 01/09/2012 03:23 PM, Matthew Wilcox wrote:
> > > On Mon, Jan 09, 2012 at 01:55:02PM +0100, Sebastian Andrzej Siewior wrote:
> > >> Hi Sarah,
> > >>
> > >> I've been looking into UAS support for hcds without support for sg.
> > >
> > > I think that's fundamentally the wrong approach.  Instead, HCDs should
> > > be modified to add support for SGs.  I posted a patch series that made
> > > progress towards that goal a while back.
> > 
> > That is what Felipe and I decided for the gadget framework.
> > Alan / Greg, any comments from your side?
> 
> There are lots of little host controller drivers, and verifying that SG 
> support has been correctly added to each of them will be nearly 
> impossible.  On the other hand, most of those drivers don't matter much 
> as far as UAS is concerned.
> 
> 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.

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.

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.

Sarah Sharp
--
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


[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux