Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1759981AbcLPJJo (ORCPT ); Fri, 16 Dec 2016 04:09:44 -0500 Received: from mx2.suse.de ([195.135.220.15]:34879 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1759909AbcLPJJV (ORCPT ); Fri, 16 Dec 2016 04:09:21 -0500 Date: Fri, 16 Dec 2016 10:09:15 +0100 From: "Luis R. Rodriguez" To: =?utf-8?B?UmFmYcWCIE1pxYJlY2tp?= Cc: "Luis R. Rodriguez" , gregkh@linuxfoundation.org, ming.lei@canonical.com, daniel.wagner@bmw-carit.de, teg@jklm.no, mchehab@osg.samsung.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, bjorn.andersson@linaro.org, arend.vanspriel@broadcom.com, kvalo@codeaurora.org Subject: Re: [PATCH 3/5] firmware: revamp firmware documentation Message-ID: <20161216090915.GL13946@wotan.suse.de> References: <20161213030828.17820-1-mcgrof@kernel.org> <20161213030828.17820-4-mcgrof@kernel.org> <1daef7df-5a0d-894b-802c-e9622082570f@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1daef7df-5a0d-894b-802c-e9622082570f@gmail.com> User-Agent: Mutt/1.6.0 (2016-04-01) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2642 Lines: 55 On Tue, Dec 13, 2016 at 08:26:41AM +0100, Rafał Miłecki wrote: > On 12/13/2016 04:08 AM, Luis R. Rodriguez wrote: > > Understanding this code is getting out of control without any > > notes. Give the firmware_class driver a much needed documentation love, > > and while at it convert it to the new sphinx documentation format. > > It does help to understand the class/API, thank you! Glad it is helping! > > +Even if you have these needs there are a few reasons why you may not be > > +able to make use of built-in firmware: > > + > > +* Legalese - firmware is non-GPL compatible > > +* Some firmware may be optional > > +* Firmware upgrades are possible, therefore a new firmware would implicate > > + a complete firmware rebuild. > > Could it be you meant "kernel rebuild" or "vmlinux rebuild" here? Heh, yes... thanks, fixed! > > diff --git a/Documentation/driver-api/firmware/fallback-mechanisms.rst b/Documentation/driver-api/firmware/fallback-mechanisms.rst > > new file mode 100644 > > index 000000000000..edce1d76ce29 > > --- /dev/null > > +++ b/Documentation/driver-api/firmware/fallback-mechanisms.rst > > @@ -0,0 +1,195 @@ > > +=================== > > +Fallback mechanisms > > +=================== > > + > > +A fallback mechanism is supported to allow to overcome failures to do a direct > > +filesystem lookup on the root filesystem or when the firmware simply cannot be > > +installed for practical reasons on the root filesystem. The kernel > > +configuration options related to supporting the firmware fallback mechanism are: > > + > > + * CONFIG_FW_LOADER_USER_HELPER: enables building the firmware fallback > > + mechanism. Most distributions enable this option today. If enabled but > > + CONFIG_FW_LOADER_USER_HELPER_FALLBACK is disabled, only the custom fallback > > + mechanism is available and for the request_firmware_nowait() call. > > + * CONFIG_FW_LOADER_USER_HELPER_FALLBACK: force enables each request to > > + enable the kobject uevent fallback mechanism on all firmare API calls > > + except request_firmware_direct(). Most distributions disable this option > > + today. The call request_firmware_nowait() allows for one alternative > > + fallback mechanism: if this kconfig option is enabled and your second > > + argument to request_firmware_nowait(), uevent, is set to false you are > > + informing the kernel that you have a custom fallback mechanism and it will > > + manually load the firmware. Read below for more details. > > Yeah, it really asks for API simplification ;) So up next once this is done is the new revamp with an extensible firmware API. Luis