lkml.org 
[lkml]   [2021]   [Oct]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 04/14] firmware_loader: add built-in firmware kconfig entry
On Mon, Oct 11, 2021 at 07:46:04PM +0200, Greg KH wrote:
> 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?

Because it is done this way today only implicitly because
EXTRA_FIRMWARE is empty. Using a kconfig entry makes this
more obvious.

> > 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? :)

Well later this patch set also renames this to something more
sensible, and so that change is clearer through this patch.

> I can not take this as-is, so yes :)

Well please let me know again once you read the above explanations.

I think the new kconfig is very well justified given the above.

Luis

\
 
 \ /
  Last update: 2021-10-12 00:31    [W:0.106 / U:0.052 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site