From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753609AbcLMN0N (ORCPT ); Tue, 13 Dec 2016 08:26:13 -0500 Received: from cit-hm8-mail01.bmw-carit.de ([212.118.206.84]:35496 "EHLO cit-hm8-gw01.bmw-carit.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1752056AbcLMN0L (ORCPT ); Tue, 13 Dec 2016 08:26:11 -0500 X-CTCH-RefID: str=0001.0A0C0203.584FF6EE.033D,ss=1,re=0.000,recu=0.000,reip=0.000,cl=1,cld=1,fgs=0 Subject: Re: [PATCH 3/5] firmware: revamp firmware documentation To: "Luis R. Rodriguez" , , References: <20161213030828.17820-1-mcgrof@kernel.org> <20161213030828.17820-4-mcgrof@kernel.org> CC: , , , , , , , , , , , , , , , , , , , , , , , , , , , , From: Daniel Wagner Message-ID: Date: Tue, 13 Dec 2016 14:26:06 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: <20161213030828.17820-4-mcgrof@kernel.org> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.10.50.100] X-ClientProxiedBy: CIT-HM8-EX01.bmw-carit.intra (10.40.100.13) To CIT-HM8-EX01.bmw-carit.intra (10.40.100.13) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > +++ b/Documentation/driver-api/firmware/built-in-fw.rst > @@ -0,0 +1,36 @@ > +================= > +Built-in firmware > +================= > + > +Firmware can be built-in to the kernel, that is built-in to vmlinux, > +to enable firmware lookups to avoid having to look for firmware from > +the filesystem. I find the second part of the sentence a bit confusing in the wording. > You can enable built-in firmware using the kernel > +configuration options: > + > + * CONFIG_EXTRA_FIRMWARE > + * CONFIG_EXTRA_FIRMWARE_DIR > + > +The should not be confused with CONFIG_FIRMWARE_IN_KERNEL, this is for drivers s/The/This/ ? > +which enable firmware to be built as part of the kernel build process. This enables? > +option, CONFIG_FIRMWARE_IN_KERNEL, will build all firmware for all drivers > +enabled which ship its firmware inside the Linux kernel source tree. > + > +There are a few reasons why you might want to consider building your firmware > +into the kernel with CONFIG_EXTRA_FIRMWARE though: > + > +* Speed > +* Firmware is needed for accessing the boot device, and the user doesn't > + want to stuff the firmware into the boot initramfs. > + > +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. kernel rebuild? > +* Some firmware files may be really large in size. The remote-proc subsystem > + is an example subsystem which deals with these sorts of firmware > +* The firmware may need to be scraped out from some device specific location > + dynamically, an example is calibration data for for some WiFi chipsets. Maybe it is worth to mention, that the calibration data is unique to a given chip, so it is individual. That is you would need to built for each device you sell its own kernel. [...] > +++ 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 s/firmare/firmware/ > + 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. > + > +Note that this means when having this configuration: > + > +CONFIG_FW_LOADER_USER_HELPER=y > +CONFIG_FW_LOADER_USER_HELPER_FALLBACK=n > + > +the kobject uevent fallback mechanism will never take effect even > +for request_firmware_nowait() when uevent is set to true. > + > +Justifying the firmware fallback mechanism > +========================================== > + > +Direct filesystem lookups may fail for a variety of reasons. Known reasons for > +this are worth itemizing and documenting as it justifies the need for the > +fallback mechanism: > + > +* Race against access with the root filesystem upon bootup. > + > +* Races upon resume from suspend. This is resolved by the firmware cache, but > + the firmware cache is only supported if you use uevents, and its not > + supported for request_firmware_into_buf(). > + > +* Firmware is not accessible through typical means: > + * It cannot be installed into the root filesystem > + * The firmware provides very unique device specific data tailored for > + the unit gathered with local information. An example is calibration > + data for WiFi chipsets for mobile devices. This calibration data is > + not common to all units, but tailored per unit. Such information may > + be installed on a separate flash partition other than where the root > + filesystem is provided. Ah, her is the bit about the calibration information. cheers, daniel