Re: [Ksummit-discuss] [TECH TOPIC] Addressing complex dependencies and semantics (v2)

[Takashi Iwai <tiwai@suse.de>]

On Tue, 02 Aug 2016 11:48:03 +0200,
Jiri Kosina wrote:
> 
> On Tue, 2 Aug 2016, Hannes Reinecke wrote:
> 
> > We actually have been discussing such a scenario when running under 
> > UEFI; there you could implement a generic UEFI network driver, which 
> > then later might get superseded by the 'real' network driver.
> > 
> > Which would require to
> > a) be able to properly formulate the probing order
> > and
> > b) establish proper rules on how to 're-bind' a device to a different
> > driver.
> 
> Similar use-case for HID.
> 
> There is a lot of hardware for which hid-generic driver 'sort of works' 
> (and it makes sense to have that one included in the initrd), but then 
> there are specific drivers fully exploiting all the capabilities of 
> particular device (and it doesn't make sense to include all of those in 
> initrd).
> 
> Currently, the hid-generic doesn't bind to such devices at all, because it 
> has a large list of device IDs for which specific drivers exist, and 
> expects those to be bound. Which doesn't really provide the best user 
> experience.

Another "me too": a similar requirement for HD-audio.

We provide a generic HD-audio codec driver and codec-specific drivers.
Currently, the prioritized binding is done by the special binder code
in HD-audio controller driver, since we have no standard established
fallback bind mechanism, so far.


Takashi