linux-kernel - Re: [PATCH 3/5] firmware: revamp firmware documentation

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20161216091649.GM13946@wotan.suse.de>
Date:   Fri, 16 Dec 2016 10:16:49 +0100
From:   "Luis R. Rodriguez" <mcgrof@...nel.org>
To:     Daniel Wagner <daniel.wagner@...-carit.de>
Cc:     "Luis R. Rodriguez" <mcgrof@...nel.org>,
        gregkh@...uxfoundation.org, ming.lei@...onical.com, teg@...m.no,
        mchehab@....samsung.com, zajec5@...il.com,
        linux-kernel@...r.kernel.org, markivx@...eaurora.org,
        stephen.boyd@...aro.org, broonie@...nel.org,
        zohar@...ux.vnet.ibm.com, tiwai@...e.de, johannes@...solutions.net,
        chunkeey@...glemail.com, hauke@...ke-m.de,
        jwboyer@...oraproject.org, dmitry.torokhov@...il.com,
        dwmw2@...radead.org, jslaby@...e.com,
        torvalds@...ux-foundation.org, luto@...capital.net,
        fengguang.wu@...el.com, rpurdie@...ys.net,
        j.anaszewski@...sung.com, Abhay_Salunke@...l.com,
        Julia.Lawall@...6.fr, Gilles.Muller@...6.fr, nicolas.palix@...g.fr,
        dhowells@...hat.com, bjorn.andersson@...aro.org,
        arend.vanspriel@...adcom.com, kvalo@...eaurora.org
Subject: Re: [PATCH 3/5] firmware: revamp firmware documentation

On Tue, Dec 13, 2016 at 02:26:06PM +0100, Daniel Wagner wrote:
> > +++ 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.

OK how about:

Firmware can be built-in to the kernel, this means building the firmware        
into vmlinux directly, to enable avoiding having to look for firmware from      
the filesystem. Instead, firmware can be looked for inside the kernel           
directly. You can enable built-in firmware using the kernel configuration       
options:                                                                        
                                                                                
  * CONFIG_EXTRA_FIRMWARE                                                       
  * CONFIG_EXTRA_FIRMWARE_DIR   

> > 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/ ?

Fixed.

> > +which enable firmware to be built as part of the kernel build process. This
> 
> enables?

Fixed.

> > +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?

Fixed.

> > +* 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.

Adjusted. It now says:

* The firmware may need to be scraped out from some device specific location    
  dynamically, an example is calibration data for for some WiFi chipsets. This  
  calibration data can be unique per sold device.  

> [...]
> 
> > +++ 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/

Fixed.

  Luis