Re: [RFC/PATCH v3 2/5] uas: MS UAS Gadget driver - Infrastructure

[Alan Stern]

On Tue, 26 Apr 2011, Sarah Sharp wrote:

> I meant that during enumeration, configuration 1 would be installed, and
> because the USB core doesn't try to install a particular alternate
> interface setting, alt setting 0 would be active by default.

Unless the driver changed it.

> How would the usb-storage driver reject a bind by the USB core?  By
> returning an error from the probe function?  Would the USB core go and
> search for the next driver after the BOT driver rejected the bind?  It
> looks like usb_probe_interface will just return an error if the first
> driver's probe function fails.

If a driver's or subsystem's probe routine returns an error then the
driver core continues looking for another driver.  If the error code is
-ENODEV or -ENXIO then it doesn't even put a warning in the kernel log;  
the driver core takes this to mean that the driver detected it couldn't
handle the device.  See drivers/base/dd.c:really_probe().

> > Which reminds me...  Fallbacks are always a good idea.  If usb-storage 
> > did decide not to bind to combined BOT/UAS devices, we should have a 
> > mechanism for overriding this choice (i.e., forcing usb-storage to bind 
> > regardless).
> 
> Sure, maybe a module parameter like "own_uas"?  Or do we want something
> fancier, like a way to specify a list of VID:PIDs that the usb-storage
> driver should own?  (I think the list parsing might be a bit hard to
> implement though.)

The VID:PID thing would work; usb-storage already has a "quirks" 
parameter that accepts such things.  We could add a quirk for binding
to a BOT/UAS interface.

> > Likewise, Sarah, you should consider adding a mechanism to xhci-hcd for 
> > forcing individual root-hub ports not to run at SuperSpeed (rather like 
> > the "companion" attribute file in ehci-hcd, although I'm sure you can 
> > come up with a better name).
> 
> I'm not entirely sure I can force a port down to USB 2.0 speeds, because
> I'm not sure I can disable the port or turn off SuperSpeed terminations
> from the xHCI driver.  I'd have to look into it.

This sounds like the problem we encountered while trying to disable a
SuperSpeed port.  It merely forced the device to switch over to the
USB-2 bus.  That wasn't what we wanted then, but it is what we're
interested in now.

Getting things to switch back might be harder -- re-enabling the 
SuperSpeed terminations won't force the device to stop using the USB-2 
bus.  It might be necessary to reset the USB-2 port.

Alan Stern

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/