Greg KH <greg@xxxxxxxxx> writes: > On Fri, Jun 09, 2017 at 10:52:42AM +0200, Bjørn Mork wrote: >> Greg KH <greg@xxxxxxxxx> writes: >> >> > On Fri, Jun 09, 2017 at 10:21:47AM +0200, Jiri Kosina wrote: >> >> Longer-term, we'd ideally make 'generic' driver special and let it attach >> >> as a 'last resort driver' if none of the specific driver picked the device >> >> up during probe. But I don't think our current driver model allows this >> >> easily ... or is there way I am not seeing? >> > >> > Nope, the driver model does not provide a way for this, sorry, it's been >> > a complaint from the very beginning that we don't really know how to >> > handle, except to make sure the order of the drivers loaded are the >> > priority list, and that's not really a solution at all. >> >> Add a 'priority' field to struct device_driver and sort the list by this >> field instead of load order? > > We've been over this before :) OK, I have to google that. > What happens when a new module is loaded, are you supposed to then > disconnect a device from an existing driver, recan all of the existing > drivers, and then bind the "correct" one then? You don't have to touch any bound device unless it matches the new driver, which hopefully only will be the rare cases where that driver actually *is* a better alternative. But yes, there are many issues which needs to be resolved. What if you unbind from an existing driver and the new driver fails probing? What if the user manually bound the device to the existing driver? What if different devices want different driver priorities? Can we make module loading follow the priority to avoid bind/unbind bouncing for the common case? Etc. Lots of work, but I still think it's the way to go. Just look at what we have today: Inflexible build time priorities implemented as paired blacklists and whitelists. Even if you get all the IS_ENABLED ifdefs right, you will fail if the user blacklists or removes one of the modules at runtime. And when you have two alternative drivers for a device, possibly with different feature sets [1], there is no way to switch between drivers without rebuilding. And you have a number of class drivers with long lists of apparently redundant device IDs. Until you look at the source and discover that these devices are actually blacklisted. Ugly and confusing. I was a bit unsure if I should dare mention this since it is one of the uglier constructs I know about, and I am responsible, but what the h...: The cdc_ncm vs cdc_mbim is particularily bad. It has its own "priority" flag implemented as a module parameter in the cdc_ncm driver. This was done because both drivers had to match NCM interfaces, since these are allowed to transform into MBIM interfaces depending on altsetting. I still don't see any way to support that without priorities. I only wish I had tried to push generic driver priorities instead of making it specific to cdc_ncm/cdc_mbim. But I should probably go google now, before I repeat too mcuh of the previous discussions ;-) [1] there are real examples of this. r8152 vs cdc_ether is one. Bjørn -- 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
