Re: [PATCH 42/68] uas: Add a usbcore.nouas kernel cmdline option

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

 



Hi,

On 11/15/2013 08:19 PM, Sarah Sharp wrote:
On Fri, Nov 15, 2013 at 04:06:56PM +0100, Hans de Goede wrote:
Note this is done through a usbcore module parameter as the option is needed
by both the uas and usb-storage drivers.

I'm a bit confused as to why you need both this patch and the previous
patch.  The previous patch adds the ability to add an usual dev entry to
the UAS driver to make it not bind to a UAS device (usb-storage would
get used instead).  This one adds a module parameter to the USB core to
disable UAS all together.

I believe you can add unusual dev entries via modprobe arguments

For the usb-storage driver that is correct, but not for the uas driver,
the current modprobe / sysfs options are for setting quirks only on the
usb-storage side. uas cannot access these quirk since this info is all
inside the usb-storage module.

so why do you need this extra parameter to disable UAS all together?

The reason to have a module option for this, besides the blacklist is
for users with new models, so that they can see if falling back to
usb-storage helps and can report this to us.

The reason to have this in the usb-core rather then in uas, is that
for this to work both uas.ko and usb-storage.ko need to know. uas
must NOT bind, where as usb-storage must bind where it would normally
not bind to an uas capable device.

Alternatively I could add a quirks module option to the uas module,
mirroring the quirks option of the usb-storage module. But then users
must pass the same quirks= argument to both uas and usb-storage for
things to work. It seemed easier for users to me to simply have
one single usbcore.nouas option.

Another alternative would be for uas to use the quirks list from
usb-storage, as I suggested in an earlier email discussion on this,
but but that would make uas depend on usb-storage which was deemed
undesirable in that discussion. Note that unusual_devs entries
are shared by simply including the same .h file in both drivers,
the only problem which would require a dependency between the 2
modules is commandline / runtime added quirks. I've opted to
put a module option at a higher level rather then introduce a
dependency to solve this.

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




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

  Powered by Linux