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

[Jiri Kosina]

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.

Thanks,

-- 
Jiri Kosina
SUSE Labs