| Message ID | 20210917182226.3532898-5-mcgrof@kernel.org (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | firmware_loader: built-in API and make x86 use it | expand |
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. > + 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? Anyway, I took the first 3 patches here, please fix this up and rebase and resend. thanks, greg k-h
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 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 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? Luis
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
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
On Mon, Oct 11, 2021 at 03:30:24PM -0700, Luis Chamberlain wrote: > On Mon, Oct 11, 2021 at 07:46:04PM +0200, Greg KH wrote: > > > 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. Greg, The fact that it was not obvious to you we were effectively disabling the built-in firmware functionality by default using side kconfig symbols is a good reason to clarify this situation with its own kconfig symbol. And consider what I started below as well. Please let me know why on the other hand we should *not* add this new kconfig symbol? > > > 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
On Mon, Oct 18, 2021 at 02:00:25PM -0700, Luis Chamberlain wrote: > On Mon, Oct 11, 2021 at 03:30:24PM -0700, Luis Chamberlain wrote: > > On Mon, Oct 11, 2021 at 07:46:04PM +0200, Greg KH wrote: > > > > 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. > > Greg, > > The fact that it was not obvious to you we were effectively disabling > the built-in firmware functionality by default using side kconfig > symbols is a good reason to clarify this situation with its own kconfig > symbol. > > And consider what I started below as well. > > Please let me know why on the other hand we should *not* add this new > kconfig symbol? Because added complexity for no real good reason? You need to justify why we need yet-another firmware kconfig option here. We should be working to remove them, not add more, if at all possible. thanks, greg k-h
On Tue, Oct 19, 2021 at 08:16:14AM +0200, Greg KH wrote: > On Mon, Oct 18, 2021 at 02:00:25PM -0700, Luis Chamberlain wrote: > > On Mon, Oct 11, 2021 at 03:30:24PM -0700, Luis Chamberlain wrote: > > > On Mon, Oct 11, 2021 at 07:46:04PM +0200, Greg KH wrote: > > > > > 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. > > > > Greg, > > > > The fact that it was not obvious to you we were effectively disabling > > the built-in firmware functionality by default using side kconfig > > symbols is a good reason to clarify this situation with its own kconfig > > symbol. > > > > And consider what I started below as well. > > > > Please let me know why on the other hand we should *not* add this new > > kconfig symbol? > > Because added complexity for no real good reason? You need to justify > why we need yet-another firmware kconfig option here. We should be > working to remove them, not add more, if at all possible. I did, it actually simplifies things more and makes the fact that we disable the functionality of the built-in firmware by default clearer. So no, this is not adding complexity. Luis
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 + depends on FW_LOADER=y help Device drivers which require firmware can typically deal with having the kernel load firmware from the various supported @@ -43,7 +45,14 @@ config EXTRA_FIRMWARE in boot and cannot rely on the firmware being placed in an initrd or initramfs. - This option is a string and takes the (space-separated) names of the + Support for built-in firmware is not supported if you are using + the firmware loader as a module. + +config EXTRA_FIRMWARE + string "Build named firmware blobs into the kernel binary" + depends on FW_LOADER_BUILTIN + help + This option is a string and takes the space-separated names of the firmware files -- the same names that appear in MODULE_FIRMWARE() and request_firmware() in the source. These files should exist under the directory specified by the EXTRA_FIRMWARE_DIR option, which is @@ -61,12 +70,14 @@ config EXTRA_FIRMWARE consult a lawyer of your own before distributing such an image. config EXTRA_FIRMWARE_DIR - string "Firmware blobs root directory" - depends on EXTRA_FIRMWARE != "" + string "Directory with firmware to be built-in to the kernel" + depends on FW_LOADER_BUILTIN default "/lib/firmware" help - This option controls the directory in which the kernel build system - looks for the firmware files listed in the EXTRA_FIRMWARE option. + This option specifies the directory which the kernel build system + will use to look for the firmware files which are going to be + built into the kernel using the space-separated EXTRA_FIRMWARE + entries. config FW_LOADER_USER_HELPER bool "Enable the firmware sysfs fallback mechanism" diff --git a/drivers/base/firmware_loader/Makefile b/drivers/base/firmware_loader/Makefile index e87843408fe6..a2dbfa19201c 100644 --- a/drivers/base/firmware_loader/Makefile +++ b/drivers/base/firmware_loader/Makefile @@ -1,10 +1,9 @@ # SPDX-License-Identifier: GPL-2.0 # Makefile for the Linux firmware loader +obj-$(CONFIG_FW_LOADER_BUILTIN) += builtin/ obj-$(CONFIG_FW_LOADER_USER_HELPER) += fallback_table.o obj-$(CONFIG_FW_LOADER) += firmware_class.o firmware_class-objs := main.o firmware_class-$(CONFIG_FW_LOADER_USER_HELPER) += fallback.o firmware_class-$(CONFIG_EFI_EMBEDDED_FIRMWARE) += fallback_platform.o - -obj-y += builtin/ diff --git a/drivers/base/firmware_loader/main.c b/drivers/base/firmware_loader/main.c index d95b5fe5f700..45075c7f9290 100644 --- a/drivers/base/firmware_loader/main.c +++ b/drivers/base/firmware_loader/main.c @@ -95,7 +95,7 @@ static struct firmware_cache fw_cache; /* Builtin firmware support */ -#ifdef CONFIG_FW_LOADER +#ifdef CONFIG_FW_LOADER_BUILTIN extern struct builtin_fw __start_builtin_fw[]; extern struct builtin_fw __end_builtin_fw[]; @@ -148,7 +148,7 @@ static bool fw_is_builtin_firmware(const struct firmware *fw) return false; } -#else /* Module case - no builtin firmware support */ +#else static inline bool firmware_request_builtin(struct firmware *fw, const char *name)