From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754379AbdASS7I (ORCPT ); Thu, 19 Jan 2017 13:59:08 -0500 Received: from mail-pf0-f171.google.com ([209.85.192.171]:32976 "EHLO mail-pf0-f171.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754219AbdASS7G (ORCPT ); Thu, 19 Jan 2017 13:59:06 -0500 Date: Thu, 19 Jan 2017 10:58:56 -0800 From: Bjorn Andersson To: "Luis R. Rodriguez" Cc: gregkh@linuxfoundation.org, ming.lei@canonical.com, bp@alien8.de, wagi@monom.org, teg@jklm.no, mchehab@osg.samsung.com, zajec5@gmail.com, linux-kernel@vger.kernel.org, markivx@codeaurora.org, stephen.boyd@linaro.org, broonie@kernel.org, zohar@linux.vnet.ibm.com, tiwai@suse.de, johannes@sipsolutions.net, chunkeey@googlemail.com, hauke@hauke-m.de, jwboyer@fedoraproject.org, dmitry.torokhov@gmail.com, dwmw2@infradead.org, jslaby@suse.com, torvalds@linux-foundation.org, luto@amacapital.net, fengguang.wu@intel.com, rpurdie@rpsys.net, j.anaszewski@samsung.com, Abhay_Salunke@dell.com, Julia.Lawall@lip6.fr, Gilles.Muller@lip6.fr, nicolas.palix@imag.fr, dhowells@redhat.com, arend.vanspriel@broadcom.com, kvalo@codeaurora.org Subject: Re: [PATCH v4 1/3] firmware: add new extensible firmware API - drvdata Message-ID: <20170119185856.GX10531@minitux> References: <20161216114632.22559-1-mcgrof@kernel.org> <20170112150244.12700-1-mcgrof@kernel.org> <20170112150244.12700-2-mcgrof@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170112150244.12700-2-mcgrof@kernel.org> User-Agent: Mutt/1.7.2 (2016-11-26) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu 12 Jan 07:02 PST 2017, Luis R. Rodriguez wrote: [..] > +Fallback mechanisms on the driver data API > +========================================== > + > +The old firmware API provided support for a series of fallback mechanisms. The > +new driver data API abandons all current notions of the fallback mechanisms, > +it may soon add support for one though. > + What will this fallback mechanism look like? Will it be fully compatible with the current userspace interfaces or will we forever have two duplicate systems for loading "firmware" in the kernel? Will the "sysdata" (or is it named "driver_data"?!) replace the firmware_class at any point in the future? Regards, Bjorn