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

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, 27 Apr 2011 13:16:05 -0400 (EDT)
From:	Alan Stern <stern@...land.harvard.edu>
To:	Sarah Sharp <sarah.a.sharp@...ux.intel.com>
cc:	Tanya Brokhman <tlinder@...eaurora.org>, <gregkh@...e.de>,
	<linux-arm-msm@...r.kernel.org>, <ablay@...eaurora.org>,
	<balbi@...com>, USB list <linux-usb@...r.kernel.org>,
	Kernel development list <linux-kernel@...r.kernel.org>,
	'Matthew Wilcox' <matthew.r.wilcox@...el.com>
Subject: Re: [RFC/PATCH v3 2/5] uas: MS UAS Gadget driver - Infrastructure

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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/