From: Greg KH <gregkh@linuxfoundation.org>
To: Luis Chamberlain <mcgrof@kernel.org>
Cc: bp@suse.de, akpm@linux-foundation.org, josh@joshtriplett.org,
rishabhb@codeaurora.org, kubakici@wp.pl, maco@android.com,
david.brown@linaro.org, bjorn.andersson@linaro.org,
linux-wireless@vger.kernel.org, keescook@chromium.org,
shuah@kernel.org, mfuzzey@parkeon.com, zohar@linux.vnet.ibm.com,
dhowells@redhat.com, pali.rohar@gmail.com, tiwai@suse.de,
arend.vanspriel@broadcom.com, zajec5@gmail.com, nbroeking@me.com,
broonie@kernel.org, dmitry.torokhov@gmail.com,
dwmw2@infradead.org, torvalds@linux-foundation.org,
Abhay_Salunke@dell.com, jewalt@lgsinnovations.com,
cantabile.desu@gmail.com, ast@fb.com, andresx7@gmail.com,
dan.rue@linaro.org, brendanhiggins@google.com,
yzaikin@google.com, sfr@canb.auug.org.au, rdunlap@infradead.org,
linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH 04/14] firmware_loader: add built-in firmware kconfig entry
Date: Mon, 11 Oct 2021 19:46:04 +0200 [thread overview]
Message-ID: <YWR4XKrC2Bkr4qKQ@kroah.com> (raw)
In-Reply-To: <YWR16e/seTx/wxE+@bombadil.infradead.org>
On Mon, Oct 11, 2021 at 10:35:37AM -0700, Luis Chamberlain wrote:
> On Tue, Oct 05, 2021 at 04:30:06PM +0200, Greg KH wrote:
> > On Fri, Sep 17, 2021 at 11:22:16AM -0700, Luis R. Rodriguez wrote:
> > > From: Luis Chamberlain <mcgrof@kernel.org>
> > >
> > > The built-in firmware is always supported when a user enables
> > > FW_LOADER=y today, that is, it is built-in to the kernel. When the
> > > firmware loader is built as a module, support for built-in firmware
> > > is skipped. This requirement is not really clear to users or even
> > > developers.
> > >
> > > Also, by default the EXTRA_FIRMWARE is always set to an empty string
> > > and so by default we really have nothing built-in to that kernel's
> > > sections for built-in firmware, so today a all FW_LOADER=y kernels
> > > spins their wheels on an empty set of built-in firmware for each
> > > firmware request with no true need for it.
> > >
> > > Add a new kconfig entry to represent built-in firmware support more
> > > clearly. This let's knock 3 birds with one stone:
> > >
> > > o Clarifies that support for built-in firmware requires the
> > > firmware loader to be built-in to the kernel
> > >
> > > o By default we now always skip built-in firmware even if a FW_LOADER=y
> > >
> > > o This also lets us make it clear that the EXTRA_FIRMWARE_DIR
> > > kconfig entry is only used for built-in firmware
> > >
> > > Reviewed-by: Borislav Petkov <bp@suse.de>
> > > Signed-off-by: Luis Chamberlain <mcgrof@kernel.org>
> > > ---
> > > .../driver-api/firmware/built-in-fw.rst | 2 ++
> > > Documentation/x86/microcode.rst | 5 ++--
> > > drivers/base/firmware_loader/Kconfig | 25 +++++++++++++------
> > > drivers/base/firmware_loader/Makefile | 3 +--
> > > drivers/base/firmware_loader/main.c | 4 +--
> > > 5 files changed, 26 insertions(+), 13 deletions(-)
> > >
> > > diff --git a/Documentation/driver-api/firmware/built-in-fw.rst b/Documentation/driver-api/firmware/built-in-fw.rst
> > > index bc1c961bace1..9dd2b1df44f0 100644
> > > --- a/Documentation/driver-api/firmware/built-in-fw.rst
> > > +++ b/Documentation/driver-api/firmware/built-in-fw.rst
> > > @@ -8,6 +8,7 @@ the filesystem. Instead, firmware can be looked for inside the kernel
> > > directly. You can enable built-in firmware using the kernel configuration
> > > options:
> > >
> > > + * CONFIG_FW_LOADER_BUILTIN
> > > * CONFIG_EXTRA_FIRMWARE
> > > * CONFIG_EXTRA_FIRMWARE_DIR
> > >
> > > @@ -17,6 +18,7 @@ into the kernel with CONFIG_EXTRA_FIRMWARE:
> > > * Speed
> > > * Firmware is needed for accessing the boot device, and the user doesn't
> > > want to stuff the firmware into the boot initramfs.
> > > +* Testing built-in firmware
> > >
> > > Even if you have these needs there are a few reasons why you may not be
> > > able to make use of built-in firmware:
> > > diff --git a/Documentation/x86/microcode.rst b/Documentation/x86/microcode.rst
> > > index a320d37982ed..d199f0b98869 100644
> > > --- a/Documentation/x86/microcode.rst
> > > +++ b/Documentation/x86/microcode.rst
> > > @@ -114,11 +114,12 @@ Builtin microcode
> > > =================
> > >
> > > The loader supports also loading of a builtin microcode supplied through
> > > -the regular builtin firmware method CONFIG_EXTRA_FIRMWARE. Only 64-bit is
> > > -currently supported.
> > > +the regular builtin firmware method using CONFIG_FW_LOADER_BUILTIN and
> > > +CONFIG_EXTRA_FIRMWARE. Only 64-bit is currently supported.
> > >
> > > Here's an example::
> > >
> > > + CONFIG_FW_LOADER_BUILTIN=y
> > > CONFIG_EXTRA_FIRMWARE="intel-ucode/06-3a-09 amd-ucode/microcode_amd_fam15h.bin"
> > > CONFIG_EXTRA_FIRMWARE_DIR="/lib/firmware"
> > >
> > > diff --git a/drivers/base/firmware_loader/Kconfig b/drivers/base/firmware_loader/Kconfig
> > > index 5b24f3959255..de4fcd9d41f3 100644
> > > --- a/drivers/base/firmware_loader/Kconfig
> > > +++ b/drivers/base/firmware_loader/Kconfig
> > > @@ -29,8 +29,10 @@ if FW_LOADER
> > > config FW_LOADER_PAGED_BUF
> > > bool
> > >
> > > -config EXTRA_FIRMWARE
> > > - string "Build named firmware blobs into the kernel binary"
> > > +config FW_LOADER_BUILTIN
> > > + bool "Enable support for built-in firmware"
> > > + default n
> >
> > n is always the default, no need to list it again.
>
> Oh, alrighty, I'll remove that line.
>
> > > + depends on FW_LOADER=y
> >
> > I don't see what this gets us to add another config option. Are you
> > making things easier later on?
>
> This makes a few things clearer for both developers and users.
> The code in question is a *feature* *only* when FW_LOADER=y, by
> adding a new kconfig to represent this and clearly makeing it
> depend on FW_LOADER=y it let's us:
>
> o Clarify that support for built-in firmware requires
> the firmware loader to be built-in to the kernel
That is good.
> o By default we now always skip built-in firmware even if a FW_LOADER=y
I do not understand, why would we ever want to skip built-in firmware?
> o This also lets us make it clear that the EXTRA_FIRMWARE_DIR
> kconfig entry is only used for built-in firmware
How was it ever used for anything else? :)
> The above is not easily obvious to developers (including myself when
> I was reviewing this code) or users without this new kconfig entry.
>
> Should I re-send by just removing the one line you asked for?
I can not take this as-is, so yes :)
thanks,
greg k-h
next prev parent reply other threads:[~2021-10-11 17:46 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-09-17 18:22 [PATCH 00/14] firmware_loader: built-in API and make x86 use it Luis R. Rodriguez
2021-09-17 18:22 ` [PATCH 01/14] firmware_loader: fix pre-allocated buf built-in firmware use Luis R. Rodriguez
2021-09-17 18:22 ` [PATCH 02/14] firmware_loader: split built-in firmware call Luis R. Rodriguez
2021-09-17 18:22 ` [PATCH 03/14] firmware_loader: add a sanity check for firmware_request_builtin() Luis R. Rodriguez
2021-09-17 18:22 ` [PATCH 04/14] firmware_loader: add built-in firmware kconfig entry Luis R. Rodriguez
2021-10-05 14:30 ` Greg KH
2021-10-11 17:35 ` Luis Chamberlain
2021-10-11 17:46 ` Greg KH [this message]
2021-10-11 22:30 ` Luis Chamberlain
2021-10-18 21:00 ` Luis Chamberlain
2021-10-19 6:16 ` Greg KH
2021-10-19 15:52 ` Luis Chamberlain
2021-09-17 18:22 ` [PATCH 05/14] firmware_loader: formalize built-in firmware API Luis R. Rodriguez
2021-09-17 18:22 ` [PATCH 06/14] firmware_loader: remove old DECLARE_BUILTIN_FIRMWARE() Luis R. Rodriguez
2021-09-17 18:22 ` [PATCH 07/14] x86/microcode: Use the firmware_loader built-in API Luis R. Rodriguez
2021-09-17 18:22 ` [PATCH 08/14] firmware_loader: move struct builtin_fw to the only place used Luis R. Rodriguez
2021-09-17 18:22 ` [PATCH 09/14] vmlinux.lds.h: wrap built-in firmware support under its kconfig symbol Luis R. Rodriguez
2021-09-17 18:22 ` [PATCH 10/14] x86/build: Tuck away built-in firmware " Luis R. Rodriguez
2021-09-17 18:22 ` [PATCH 11/14] firmware_loader: rename EXTRA_FIRMWARE and EXTRA_FIRMWARE_DIR Luis R. Rodriguez
2021-09-17 18:22 ` [PATCH 12/14] firmware_loader: move builtin build helper to shared library Luis R. Rodriguez
2021-09-17 18:22 ` [PATCH 13/14] test_firmware: move a few test knobs out to its library Luis R. Rodriguez
2021-09-17 18:22 ` [PATCH 14/14] test_firmware: add support for testing built-in firmware Luis R. Rodriguez
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=YWR4XKrC2Bkr4qKQ@kroah.com \
--to=gregkh@linuxfoundation.org \
--cc=Abhay_Salunke@dell.com \
--cc=akpm@linux-foundation.org \
--cc=andresx7@gmail.com \
--cc=arend.vanspriel@broadcom.com \
--cc=ast@fb.com \
--cc=bjorn.andersson@linaro.org \
--cc=bp@suse.de \
--cc=brendanhiggins@google.com \
--cc=broonie@kernel.org \
--cc=cantabile.desu@gmail.com \
--cc=dan.rue@linaro.org \
--cc=david.brown@linaro.org \
--cc=dhowells@redhat.com \
--cc=dmitry.torokhov@gmail.com \
--cc=dwmw2@infradead.org \
--cc=jewalt@lgsinnovations.com \
--cc=josh@joshtriplett.org \
--cc=keescook@chromium.org \
--cc=kubakici@wp.pl \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-wireless@vger.kernel.org \
--cc=maco@android.com \
--cc=mcgrof@kernel.org \
--cc=mfuzzey@parkeon.com \
--cc=nbroeking@me.com \
--cc=pali.rohar@gmail.com \
--cc=rdunlap@infradead.org \
--cc=rishabhb@codeaurora.org \
--cc=sfr@canb.auug.org.au \
--cc=shuah@kernel.org \
--cc=tiwai@suse.de \
--cc=torvalds@linux-foundation.org \
--cc=yzaikin@google.com \
--cc=zajec5@gmail.com \
--cc=zohar@linux.vnet.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).