Re: Two regressions on BYT/T ASUS T100TA 4.12-rc: #2 Keyboard no longer works

Greg KH [off-list ref] writes:

On Fri, Jun 09, 2017 at 10:52:42AM +0200, Bjørn Mork wrote:

quoted

Greg KH [off-list ref] writes:

quoted

On Fri, Jun 09, 2017 at 10:21:47AM +0200, Jiri Kosina wrote:

quoted

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