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: <20161216090915.GL13946@wotan.suse.de>
Date:   Fri, 16 Dec 2016 10:09:15 +0100
From:   "Luis R. Rodriguez" <mcgrof@...nel.org>
To:     Rafał Miłecki <zajec5@...il.com>
Cc:     "Luis R. Rodriguez" <mcgrof@...nel.org>,
        gregkh@...uxfoundation.org, ming.lei@...onical.com,
        daniel.wagner@...-carit.de, teg@...m.no, mchehab@....samsung.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 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