Hi,
On 10/25/2013 03:19 PM, Alan Stern wrote:
On Fri, 25 Oct 2013, Hans de Goede wrote:
Hi,
On 10/24/2013 06:32 PM, Alan Stern wrote:
On Thu, 24 Oct 2013, Hans de Goede wrote:
uas devices have 2 alternative settings on their usb-storage interface,
one for usb-storage and one for uas. Using the uas driver is preferred, so if
the uas driver is enabled, and the device has an uas alt setting, don't bind.
We need a mechanism for the user to force a device into usb-storage
mode, even if the device claims to support UAS. It would not be at all
surprising to find some devices whose UAS support is broken.
Agreed, this is one of the reasons why I want to share the uas-detect code
between the uas and usb-storage drivers, so that we can have a single
place for a blacklist.
So I think the best way to provide such a user override would be a kernel
module option. But that needs to belong to a single module, so I see 2 options;
1) Turn uas-detect into a separate module
2) Use the existing unusual_dev stuff for this and make uas depend on usb-storage
to get the unusual_dev (included user added extra quirks) from usb-storage
2. Makes the most sense to me, since usb-storage will get loaded anyways when
uas is loaded as they both match on the same usb class.
If you agree that 2. is probably best then I can do an addon patch adding support
for a NO_UAS quirk which will cause the uas-detect code to bail with an error if
present.
How about:
3) Create an unusual_uas.h file containing entries to be shared between
usb-storage and uas. Put the NO_UAS quirk entries there.
This way uas will know not to bind to the device (and usb-storage will
know to bind), and you won't have to make uas depend on usb-storage.
Interesting suggestion.
That works for compile time quirks, but not for adding boot / runtime
quirks (ie usb-storage.quirks=... on the kernel cmdline). That means we
need to tell the user to pass the same .quirks=... for both the uas and
the usb-storage modules. I think it is better to just use the existing
usb-storage quirk code, so that runtime set quirks will always match
between uas and usb-storage, but this does mean having the uas driver
depend on usb-storage to get access to the usb-storage runtime quirk
info (through an exported helper function).
Alternatively we could add a global no_uas kernel cmdline parameter
which will be checked by both drivers, this will work for boot time
quirks, but this way we cannot add runtime quirks, it is pretty KISS
though, so I'll probably implement this for now.
Regards,
Hans
--
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
