On Thu, Jan 19, 2012 at 07:24:55PM +0100, Sebastian Andrzej Siewior wrote: > * Sarah Sharp | 2012-01-13 16:31:34 [-0800]: > > >Nak. The UAS driver isn't ready for prime time. Until we get the error > >paths cleaned up (and I know I owe Greg some patches for 3.4 from both > >of us), I don't want the UAS driver to claim devices with BOT on the > >first alternate setting. So keep this patch for a bit. :) > > Okay. But in general you like this. I've been thinking about moving uas > into usb-storage as a new protocol but it seems to be better off the way > it is now. In general, I like having the USB-storage driver kick devices with a UAS interface over to the UAS driver, so I like your patch, just not the timing of the submission. :) Matthew Wilcox had the thought that maybe if we ran into bad behavior from devices (like when your device sent the status instead of the data buffer), we should kick it back to the USB storage driver. That way we don't end up with a bijillion quirks in the UAS driver. If the device plays well, then it gets to work at the faster UAS speeds, but if it doesn't, it gets kicked back to the usb-storage driver. We'd have to have some sort of dynamic blacklist of device IDs for the UAS driver to avoid. I'm not sure how the re-binding to usb-storage would work. > _Maybe_ this check should be moved little later so we use the fixups > tables & module parameter to overwritte the setting of a particular UAS > device and use legacy interface instead. Yeah, that's probably good. But a normal user isn't going to know how to use the userspace modeswitch (at least I've never used it). If we turn on UAS by default with the driver the way it is, users will just get frustrated and distros are likely to just blacklist the UAS driver. 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
