From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 5CB9F93D for ; Tue, 2 Aug 2016 11:50:54 +0000 (UTC) Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id DE012A7 for ; Tue, 2 Aug 2016 11:50:53 +0000 (UTC) Date: Tue, 02 Aug 2016 13:50:51 +0200 Message-ID: From: Takashi Iwai To: Jiri Kosina In-Reply-To: References: <20160729111303.GA10376@sirena.org.uk> <20160801190309.GX3296@wotan.suse.de> <1555444.RIYpEbA2F7@vostro.rjw.lan> <20160802005650.GF3296@wotan.suse.de> MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: ksummit-discuss@lists.linuxfoundation.org Subject: Re: [Ksummit-discuss] [TECH TOPIC] Addressing complex dependencies and semantics (v2) List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , 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