On Sat, Oct 22, 2011 at 12:14:51PM +0200, Josua Dietze wrote: > Am 22.10.2011 10:25, schrieb Greg KH: > >On Fri, Oct 21, 2011 at 11:04:09PM +0200, Josua Dietze wrote: > > > >>When adding the ID of a composite device dynamically to a driver, > >>all hitherto unbound interfaces are bound to this driver which is > >>often not intended. > > > >It isn't? What happens wrong with this? Can't you just unbind the ones > >you don't want? > > Yes, I could, but if the dynamic adding is done automatically, say, > by an udev rule upon device discovery, the process is becoming > time-sensitive. > For instance, it may happen that e.g. storage interfaces are > mistakenly bound before the storage driver is able to bind. > Unbinding specific interfaces would be even more time-sensitive in > that context, wouldn't it? Ah, yeah, good point, ok, you have convinced me :) > >>Example: > >>$ echo "1234 2a2a ff">/sys/bus/usb-serial/drivers/generic/new_id > >>will bind only vendor-specific interfaces to usbserial. > > > >You really shouldn't be using the generic usb serial driver for anything > >"real", so that's not a good reason to accept this patch :) > > It's literally only a "generic" example. My real-world use revolves > around the "option" driver (and I keep telling everyone *not* to use > "usbserial" BTW :)). > The current 3G/4G sticks usually expose one or two storage > interfaces in addition to their serial/vendor-specific interfaces. > To support brand-new models that are not known to the 3G driver yet, > the adding of dynamic IDs to the driver is very useful. > > >And your patch is linewrapped :( > > Oops, I'm sorry. Will repost if acceptance is likely. Please repost, fixing the linewrapping, and use the option driver as the example. Also, I think there are some documentation files somewhere that should be updated with this new information that should also be done in this patch as well. thanks, greg k-h -- 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
