Received: by 10.192.165.156 with SMTP id m28csp473614imm; Mon, 16 Apr 2018 03:37:13 -0700 (PDT) X-Google-Smtp-Source: AIpwx4+/TYIA/5ybh7zzed5wG6AXVzrtmS8ItyPFtqnggWKXgOqYl8iIU6fRW/W3azEExyJdjQSp X-Received: by 10.98.153.23 with SMTP id d23mr7412041pfe.18.1523875033777; Mon, 16 Apr 2018 03:37:13 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1523875033; cv=none; d=google.com; s=arc-20160816; b=uTqiqUBNeIAvNrkZQkr9D1GtvJ5MCDYby5ECHq/UuHqk0kgxQALUiG7LApAW7YldjK WnJcecBGv9+W7BcaEiOxPuhPMiiCG5Kzut7PaSb1SkNGQflQwh+c2A9E1bhrEq8WBjGP MsiDk4SGMuXj5/cGgbn3UVfgY/XWVbaY7GKpVM9XOLJW9zJj3gNMHrS8h7rP8/R9AB2h Ov+gyjZ/1ncHhTDTBItratPx5sR4Nk84v5eOh97GINMWBdd6z8bN46UCYA66SLQrETLE svdTXNOIQTUcxaiEtOVxxy/l/ahxcBrNSchaMFjw1h3QTNv4QMwt2lUh2Qo3V2wk3tm5 2mng== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :references:in-reply-to:mime-version:dkim-signature :arc-authentication-results; bh=naSAzhaEF+ojahNRgJ7zwZcFlmPEnf5pIcEKGOw+mgs=; b=AkWdNhblo3Gl6pOhvHiLCJ5aLO+UHGAALijQvykYnDx/QCZ4rxbMD5gvjY/O3ELy39 VmP8etmE1YULS5/xEWQBXxraEnZyX8eXOc9Z+h9uaw3easTOvU9BnCV60DjPBQqLkD8Y 0fORMs7n6iWj56TeJdDoURiH9um4mr29uJvb676LJXXfgcQbK03TOVeXkZ1bR3DeCLA8 Q5/Shp+o/1oBLLJ418Hi/GCxcp7NXz0CEHww/grv6rpQulJT/N21hDC+PnotBzKAOcHb fE2B9eaRHDs3SggIMJ8PTSGXrph1oB98wnQkPuPUHrvFRfZPc9bI6N3k94Pexs9R2lDx OAeg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=aX05H6Co; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id a1si2425257pgq.594.2018.04.16.03.36.59; Mon, 16 Apr 2018 03:37:13 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=aX05H6Co; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754035AbeDPI2t (ORCPT + 99 others); Mon, 16 Apr 2018 04:28:49 -0400 Received: from mail-it0-f65.google.com ([209.85.214.65]:52937 "EHLO mail-it0-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753104AbeDPI2r (ORCPT ); Mon, 16 Apr 2018 04:28:47 -0400 Received: by mail-it0-f65.google.com with SMTP id f6-v6so10357248ita.2 for ; Mon, 16 Apr 2018 01:28:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=naSAzhaEF+ojahNRgJ7zwZcFlmPEnf5pIcEKGOw+mgs=; b=aX05H6CogMtkWfmxlR/O1mzHdioogU8UL6l85wP0zzdHe2MHQcs9+kOADBnlw2xUa5 6lsqxOb52GxS9aBxVlboHNL4uDqQB8jLc0XVljgM1XDC4A76w1q5r3G9cjAA0P7JgNYR j5+8/cU+EeXgkpwqEF4A7IjpgtwNtllNn2MVE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=naSAzhaEF+ojahNRgJ7zwZcFlmPEnf5pIcEKGOw+mgs=; b=uN8zFfQG+zvqJbZIJqSAIA1L3ecJ20K7kSaYVXHhoUieDnzDZoP/DONyPZWGF9nzLB uSUQljn+dzVgC+qhwPoZVRPARwtFcKQaTaT/pzNcoSzvDGeZK9CapWieMzdxpvhZMa9W xgmBm3A+jEmpQSbAytQ0wpj/hXhxCbU0Unacn4+yaFVMjoO2ce5/4A1LAMmSLVBuAkwP n6qZL2VY1TFEp61noJfw+lcmiX/wlUAr4tJOV7QfiSjH3y8eiQFAalxgJnkxeJcHA1KJ Rf9r3/jJuKl91aaAy9d1MgUwO88CCGuRFNhqqbSHEzb4aCSCXm4phcIx4fmIUImLVOvk Ae6w== X-Gm-Message-State: ALQs6tCIO29aUjAS8UaAA3E5LDpvMkaI8Xc23zjVY4jZv7r3g3xzzld4 bemGfFKJFTLo577y53/mFej2Au1a1ci+Tc0XEFCD9A== X-Received: by 2002:a24:36c9:: with SMTP id l192-v6mr13974490itl.42.1523867326238; Mon, 16 Apr 2018 01:28:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.187.67 with HTTP; Mon, 16 Apr 2018 01:28:45 -0700 (PDT) In-Reply-To: <20180408174014.21908-3-hdegoede@redhat.com> References: <20180408174014.21908-1-hdegoede@redhat.com> <20180408174014.21908-3-hdegoede@redhat.com> From: Ard Biesheuvel Date: Mon, 16 Apr 2018 10:28:45 +0200 Message-ID: Subject: Re: [PATCH v3 2/5] efi: Add embedded peripheral firmware support To: Hans de Goede Cc: Darren Hart , Andy Shevchenko , "Luis R . Rodriguez" , Greg Kroah-Hartman , Thomas Gleixner , Ingo Molnar , "H . Peter Anvin" , platform-driver-x86@vger.kernel.org, Linux Kernel Mailing List , Peter Jones , Dave Olsthoorn , Will Deacon , Andy Lutomirski , Matt Fleming , David Howells , Mimi Zohar , Josh Triplett , Dmitry Torokhov , Martin Fuzzey , Kees Cook , Kalle Valo , Arend Van Spriel , Linus Torvalds , Nicolas Broeking , Bjorn Andersson , Torsten Duwe , "the arch/x86 maintainers" , linux-efi@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 8 April 2018 at 19:40, Hans de Goede wrote: > Just like with PCI options ROMs, which we save in the setup_efi_pci* > functions from arch/x86/boot/compressed/eboot.c, the EFI code / ROM itself > sometimes may contain data which is useful/necessary for peripheral drivers > to have access to. > > Specifically the EFI code may contain an embedded copy of firmware which > needs to be (re)loaded into the peripheral. Normally such firmware would be > part of linux-firmware, but in some cases this is not feasible, for 2 > reasons: > > 1) The firmware is customized for a specific use-case of the chipset / use > with a specific hardware model, so we cannot have a single firmware file > for the chipset. E.g. touchscreen controller firmwares are compiled > specifically for the hardware model they are used with, as they are > calibrated for a specific model digitizer. > > 2) Despite repeated attempts we have failed to get permission to > redistribute the firmware. This is especially a problem with customized > firmwares, these get created by the chip vendor for a specific ODM and the > copyright may partially belong with the ODM, so the chip vendor cannot > give a blanket permission to distribute these. > > This commit adds support for finding peripheral firmware embedded in the > EFI code and making this available to peripheral drivers through the > standard firmware loading mechanism. > > Note we check the EFI_BOOT_SERVICES_CODE for embedded firmware near the end > of start_kernel(), just before calling rest_init(), this is on purpose > because the typical EFI_BOOT_SERVICES_CODE memory-segment is too large for > early_memremap(), so the check must be done after mm_init(). This relies > on EFI_BOOT_SERVICES_CODE not being free-ed until efi_free_boot_services() > is called, which means that this will only work on x86 for now. > > Reported-by: Dave Olsthoorn > Suggested-by: Peter Jones > Signed-off-by: Hans de Goede > --- > Changes in v2: > -Rebased on driver-core/driver-core-next > -Add documentation describing the EFI embedded firmware mechanism to: > Documentation/driver-api/firmware/request_firmware.rst > -Add a new EFI_EMBEDDED_FIRMWARE Kconfig bool and only build the embedded > fw support if this is set. This is an invisible option which should be > selected by drivers which need this > -Remove the efi_embedded_fw_desc and dmi_system_id-s for known devices > from the efi-embedded-fw code, instead drivers using this are expected to > export a dmi_system_id array, with each entries' driver_data pointing to a > efi_embedded_fw_desc struct and register this with the efi-embedded-fw code > -Use kmemdup to make a copy instead of efi_mem_reserve()-ing the firmware, > this avoids us messing with the EFI memmap and avoids the need to make > changes to efi_mem_desc_lookup() > -Make the firmware-loader code only fallback to efi_get_embedded_fw() if the > passed in device has the "efi-embedded-firmware" device-property bool set > -Skip usermodehelper fallback when "efi-embedded-firmware" device-property > is set > > Changes in v3: > -Fix the docs using "efi-embedded-fw" as property name instead of > "efi-embedded-firmware" > --- > .../driver-api/firmware/request_firmware.rst | 70 +++++++++ > drivers/base/firmware_loader/main.c | 33 ++++ > drivers/firmware/efi/Kconfig | 6 + > drivers/firmware/efi/Makefile | 1 + > drivers/firmware/efi/embedded-firmware.c | 148 ++++++++++++++++++ > include/linux/efi.h | 6 + > include/linux/efi_embedded_fw.h | 25 +++ > init/main.c | 1 + > 8 files changed, 290 insertions(+) > create mode 100644 drivers/firmware/efi/embedded-firmware.c > create mode 100644 include/linux/efi_embedded_fw.h > > diff --git a/Documentation/driver-api/firmware/request_firmware.rst b/Documentation/driver-api/firmware/request_firmware.rst > index 20f21ed427a5..189b02f815c9 100644 > --- a/Documentation/driver-api/firmware/request_firmware.rst > +++ b/Documentation/driver-api/firmware/request_firmware.rst > @@ -68,3 +68,73 @@ If something went wrong request_firmware() returns non-zero and fw_entry > is set to NULL. Once your driver is done with processing the firmware it > can call call release_firmware(fw_entry) to release the firmware image > and any related resource. > + > +EFI embedded firmware support > +============================= > + > +On some devices the system's EFI code / ROM may contain an embedded copy > +of firmware for some of the system's integrated peripheral devices and > +the peripheral's Linux device-driver needs to access this firmware. > + > +A device driver which needs this can describe the firmware it needs > +using an efi_embedded_fw_desc struct: > + > +.. kernel-doc:: include/linux/efi_embedded_fw.h > + :functions: efi_embedded_fw_desc > + > +The EFI embedded-fw code works by scanning all EFI_BOOT_SERVICES_CODE memory > +segments for an eight byte sequence matching prefix, if the prefix is found it > +then does a crc32 over length bytes and if that matches makes a copy of length > +bytes and adds that to its list with found firmwares. > + > +To avoid doing this somewhat expensive scan on all systems, dmi matching is > +used. Drivers are expected to export a dmi_system_id array, with each entries' > +driver_data pointing to an efi_embedded_fw_desc. > + > +To register this array with the efi-embedded-fw code, a driver needs to: > + > +1. Always be builtin to the kernel or store the dmi_system_id array in a > + separate object file which always gets builtin. > + > +2. Add an extern declaration for the dmi_system_id array to > + include/linux/efi_embedded_fw.h. > + > +3. Add the dmi_system_id array to the embedded_fw_table in > + drivers/firmware/efi/embedded-firmware.c wrapped in a #ifdef testing that > + the driver is being builtin. > + > +4. Add "select EFI_EMBEDDED_FIRMWARE if EFI_STUB" to its Kconfig entry. > + > +The request_firmware() function will always first try to load firmware with > +the specified name directly from the disk, so the EFI embedded-fw can always > +be overridden by placing a file under /lib/firmare. > + > +To make request_firmware() fallback to trying EFI embedded firmwares after this, > +the driver must set a boolean "efi-embedded-firmware" device-property on the > +device before passing it to request_firmware(). Note that this disables the > +usual usermodehelper fallback, so you may want to only set this on systems > +which match your dmi_system_id array. > + > +Once the device-property is set, the driver can use the regular > +request_firmware() function to get the firmware, using the name filled in > +in the efi_embedded_fw_desc. > + > +Note that: > + > +1. The code scanning for EFI embbedded-firmware runs near the end > + of start_kernel(), just before calling rest_init(). For normal drivers and > + subsystems using subsys_initcall() to register themselves this does not > + matter. This means that code running earlier cannot use EFI > + embbedded-firmware. > + > +2. ATM the EFI embedded-fw code assumes that firmwares always start at an offset > + which is a multiple of 8 bytes, if this is not true for your case send in > + a patch to fix this. > + > +3. ATM the EFI embedded-fw code only works on x86 because other archs free > + EFI_BOOT_SERVICES_CODE before the EFI embedded-fw code gets a chance to > + scan it. > + > +4. On some systems the embedded-firmware may be accessible through the > + EFI_FIRMWARE_VOLUME_PROTOCOL if this is the case this may be a better way > + to access the firmware files. EFI_FIRMWARE_VOLUME_PROTOCOL is not a UEFI protocol, so I'd prefer it if we just drop this point altogether. > diff --git a/drivers/base/firmware_loader/main.c b/drivers/base/firmware_loader/main.c > index eb34089e4299..1aa42f147415 100644 > --- a/drivers/base/firmware_loader/main.c > +++ b/drivers/base/firmware_loader/main.c > @@ -33,6 +33,8 @@ > #include > #include > #include > +#include > +#include > > #include > > @@ -340,6 +342,28 @@ fw_get_filesystem_firmware(struct device *device, struct fw_priv *fw_priv) > return rc; > } > > +#ifdef CONFIG_EFI_EMBEDDED_FIRMWARE > +static int > +fw_get_efi_embedded_fw(struct device *dev, struct fw_priv *fw_priv, int ret) > +{ > + size_t size; > + int rc; > + > + rc = efi_get_embedded_fw(fw_priv->fw_name, &fw_priv->data, &size, > + fw_priv->data ? fw_priv->allocated_size : 0); > + if (rc == 0) { > + dev_dbg(dev, "using efi-embedded fw %s\n", fw_priv->fw_name); > + fw_priv->size = size; > + fw_state_done(fw_priv); > + ret = 0; > + } else { > + dev_warn(dev, "Firmware %s not in EFI\n", fw_priv->fw_name); > + } > + > + return ret; > +} > +#endif > + > /* firmware holds the ownership of pages */ > static void firmware_free_data(const struct firmware *fw) > { > @@ -576,6 +600,15 @@ _request_firmware(const struct firmware **firmware_p, const char *name, > goto out; > > ret = fw_get_filesystem_firmware(device, fw->priv); > +#ifdef CONFIG_EFI_EMBEDDED_FIRMWARE > + if (ret && device && > + device_property_read_bool(device, "efi-embedded-firmware")) { > + ret = fw_get_efi_embedded_fw(device, fw->priv, ret); > + if (ret == 0) > + ret = assign_fw(fw, device, opt_flags | FW_OPT_NOCACHE); > + goto out; > + } > +#endif > if (ret) { > if (!(opt_flags & FW_OPT_NO_WARN)) > dev_warn(device, > diff --git a/drivers/firmware/efi/Kconfig b/drivers/firmware/efi/Kconfig > index 3098410abad8..efb190f5c157 100644 > --- a/drivers/firmware/efi/Kconfig > +++ b/drivers/firmware/efi/Kconfig > @@ -164,6 +164,12 @@ config RESET_ATTACK_MITIGATION > have been evicted, since otherwise it will trigger even on clean > reboots. > > +config EFI_EMBEDDED_FIRMWARE > + # This needs boot-services-code to be kept around till after mm_init() > + # so make this X86 only for now > + depends on EFI_STUB && X86 > + bool > + > endmenu > > config UEFI_CPER > diff --git a/drivers/firmware/efi/Makefile b/drivers/firmware/efi/Makefile > index cb805374f4bc..dde12cea8aac 100644 > --- a/drivers/firmware/efi/Makefile > +++ b/drivers/firmware/efi/Makefile > @@ -25,6 +25,7 @@ obj-$(CONFIG_EFI_BOOTLOADER_CONTROL) += efibc.o > obj-$(CONFIG_EFI_TEST) += test/ > obj-$(CONFIG_EFI_DEV_PATH_PARSER) += dev-path-parser.o > obj-$(CONFIG_APPLE_PROPERTIES) += apple-properties.o > +obj-$(CONFIG_EFI_EMBEDDED_FIRMWARE) += embedded-firmware.o > > arm-obj-$(CONFIG_EFI) := arm-init.o arm-runtime.o > obj-$(CONFIG_ARM) += $(arm-obj-y) > diff --git a/drivers/firmware/efi/embedded-firmware.c b/drivers/firmware/efi/embedded-firmware.c > new file mode 100644 > index 000000000000..cb57225a340d > --- /dev/null > +++ b/drivers/firmware/efi/embedded-firmware.c > @@ -0,0 +1,148 @@ > +// SPDX-License-Identifier: GPL-2.0 > +/* > + * Support for extracting embedded firmware for peripherals from EFI code, > + * > + * Copyright (c) 2018 Hans de Goede > + */ > + > +#include > +#include > +#include > +#include > +#include > +#include > +#include > + > +struct embedded_fw { > + struct list_head list; > + const char *name; > + void *data; > + size_t length; > +}; > + > +static LIST_HEAD(found_fw_list); > + > +static const struct dmi_system_id * const embedded_fw_table[] = { > + NULL > +}; > + > +/* > + * Note the efi_check_for_embedded_firmwares() code currently makes the > + * following 2 assumptions. This may needs to be revisited if embedded firmware > + * is found where this is not true: > + * 1) The firmware is only found in EFI_BOOT_SERVICES_CODE memory segments > + * 2) The firmware always starts at an offset which is a multiple of 8 bytes > + */ > +static int __init efi_check_md_for_embedded_firmware( > + efi_memory_desc_t *md, const struct efi_embedded_fw_desc *desc) > +{ > + struct embedded_fw *fw; > + u64 i, size; > + u32 crc; > + u8 *mem; > + > + size = md->num_pages << EFI_PAGE_SHIFT; > + mem = memremap(md->phys_addr, size, MEMREMAP_WB); > + if (!mem) { > + pr_err("Error mapping EFI mem at %#llx\n", md->phys_addr); > + return -ENOMEM; > + } > + > + size -= desc->length; > + for (i = 0; i < size; i += 8) { > + if (*((u64 *)(mem + i)) != *((u64 *)desc->prefix)) > + continue; > + > + /* Seed with ~0, invert to match crc32 userspace utility */ > + crc = ~crc32(~0, mem + i, desc->length); > + if (crc == desc->crc) > + break; > + } > + > + memunmap(mem); > + > + if (i >= size) > + return -ENOENT; > + > + pr_info("Found EFI embedded fw '%s' crc %08x\n", desc->name, desc->crc); > + > + fw = kmalloc(sizeof(*fw), GFP_KERNEL); > + if (!fw) > + return -ENOMEM; > + > + mem = memremap(md->phys_addr + i, desc->length, MEMREMAP_WB); > + if (!mem) { > + pr_err("Error mapping embedded firmware\n"); > + goto error_free_fw; > + } > + fw->data = kmemdup(mem, desc->length, GFP_KERNEL); > + memunmap(mem); > + if (!fw->data) > + goto error_free_fw; > + > + fw->name = desc->name; > + fw->length = desc->length; > + list_add(&fw->list, &found_fw_list); > + > + return 0; > + > +error_free_fw: > + kfree(fw); > + return -ENOMEM; > +} > + > +void __init efi_check_for_embedded_firmwares(void) > +{ > + const struct efi_embedded_fw_desc *fw_desc; > + const struct dmi_system_id *dmi_id; > + efi_memory_desc_t *md; > + int i, r; > + > + for (i = 0; embedded_fw_table[i]; i++) { > + dmi_id = dmi_first_match(embedded_fw_table[i]); > + if (!dmi_id) > + continue; > + > + fw_desc = dmi_id->driver_data; > + for_each_efi_memory_desc(md) { > + if (md->type != EFI_BOOT_SERVICES_CODE) > + continue; > + > + r = efi_check_md_for_embedded_firmware(md, fw_desc); > + if (r == 0) > + break; > + } > + } > +} > + > +int efi_get_embedded_fw(const char *name, void **data, size_t *size, > + size_t msize) > +{ > + struct embedded_fw *iter, *fw = NULL; > + void *buf = *data; > + > + list_for_each_entry(iter, &found_fw_list, list) { > + if (strcmp(name, iter->name) == 0) { > + fw = iter; > + break; > + } > + } > + > + if (!fw) > + return -ENOENT; > + > + if (msize && msize < fw->length) > + return -EFBIG; > + > + if (!buf) { > + buf = vmalloc(fw->length); > + if (!buf) > + return -ENOMEM; > + } > + > + memcpy(buf, fw->data, fw->length); > + *size = fw->length; > + *data = buf; > + > + return 0; > +} > diff --git a/include/linux/efi.h b/include/linux/efi.h > index f5083aa72eae..3847323ace2f 100644 > --- a/include/linux/efi.h > +++ b/include/linux/efi.h > @@ -1572,6 +1572,12 @@ static inline void > efi_enable_reset_attack_mitigation(efi_system_table_t *sys_table_arg) { } > #endif > > +#ifdef CONFIG_EFI_EMBEDDED_FIRMWARE > +void efi_check_for_embedded_firmwares(void); > +#else > +static inline void efi_check_for_embedded_firmwares(void) { } > +#endif > + > void efi_retrieve_tpm2_eventlog(efi_system_table_t *sys_table); > > /* > diff --git a/include/linux/efi_embedded_fw.h b/include/linux/efi_embedded_fw.h > new file mode 100644 > index 000000000000..0f7d4df3f57a > --- /dev/null > +++ b/include/linux/efi_embedded_fw.h > @@ -0,0 +1,25 @@ > +/* SPDX-License-Identifier: GPL-2.0 */ > +#ifndef _LINUX_EFI_EMBEDDED_FW_H > +#define _LINUX_EFI_EMBEDDED_FW_H > + > +#include > + > +/** > + * struct efi_embedded_fw_desc - This struct is used by the EFI embedded-fw > + * code to search for embedded firmwares. > + * > + * @name: Name to register the firmware with if found > + * @prefix: First 8 bytes of the firmware > + * @length: Length of the firmware in bytes including prefix > + * @crc: Inverted little endian Ethernet style CRC32, with 0xffffffff seed > + */ > +struct efi_embedded_fw_desc { > + const char *name; > + u8 prefix[8]; > + u32 length; > + u32 crc; > +}; > + > +int efi_get_embedded_fw(const char *name, void **dat, size_t *sz, size_t msize); > + > +#endif > diff --git a/init/main.c b/init/main.c > index 21efbf6ace93..51dc2981d229 100644 > --- a/init/main.c > +++ b/init/main.c > @@ -710,6 +710,7 @@ asmlinkage __visible void __init start_kernel(void) > sfi_init_late(); > > if (efi_enabled(EFI_RUNTIME_SERVICES)) { > + efi_check_for_embedded_firmwares(); Should this depend on EFI runtime services? I don't see why it should matter whether you have access to variables or the EFI rtc services. If the regions are not reserved in the first place in that case, I'd rather fix that properly. (see comment re new EFI_xxx flag in previous mail) > efi_free_boot_services(); > } > > -- > 2.17.0 >