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 227D3958 for ; Tue, 2 Aug 2016 09:48:06 +0000 (UTC) Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id A5C6314F for ; Tue, 2 Aug 2016 09:48:05 +0000 (UTC) Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id BA1E3ACAC for ; Tue, 2 Aug 2016 09:48:03 +0000 (UTC) Date: Tue, 2 Aug 2016 11:48:03 +0200 (CEST) From: Jiri Kosina To: Hannes Reinecke In-Reply-To: Message-ID: 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 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, 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