On Jun 09 2017 or thereabouts, Greg KH wrote: > 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 :) I can imagine :) > > 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? This particular case might be slightly different than a generic solution across the tree. HID devices are supposed to behave properly out of the box and are expected to be reprobed by design (most input devices have a special boot mode to be accessed to some extend by the UEFI, and then you have the shiny proprietary driver that takes over it under windows). So I don't think it would be an issue to "bind" a generic handling of a device, and somehow retrigger a probe when the actual hid-specific driver comes in (and we know we are using the default, non ideal, handling). The current driver model won't allow this by design, but I'll try to work around this if it is possible in the hid tree as a specific case. Cheers, Benjamin > > sorry, > > greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
