From: Conor Dooley <conor@kernel.org>
To: Yunhui Cui <cuiyunhui@bytedance.com>
Cc: ardb@kernel.org, palmer@dabbelt.com, paul.walmsley@sifive.com,
aou@eecs.berkeley.edu, linux-riscv@lists.infradead.org,
rminnich@gmail.com, mark.rutland@arm.com, lpieralisi@kernel.org,
rafael@kernel.org, lenb@kernel.org, jdelvare@suse.com,
yc.hung@mediatek.com, angelogioacchino.delregno@collabora.com,
allen-kh.cheng@mediatek.com,
pierre-louis.bossart@linux.intel.com, tinghan.shen@mediatek.com,
linux-kernel@vger.kernel.org, linux-acpi@vger.kernel.org,
geshijian@bytedance.com, weidong.wd@bytedance.com
Subject: Re: [PATCH v2 2/3] firmware: introduce FFI for SMBIOS entry.
Date: Sun, 2 Jul 2023 13:41:36 +0100 [thread overview]
Message-ID: <20230702-collide-rumor-f0d915a4f1b2@spud> (raw)
In-Reply-To: <20230702095735.860-2-cuiyunhui@bytedance.com>
[-- Attachment #1: Type: text/plain, Size: 6720 bytes --]
Hey,
On Sun, Jul 02, 2023 at 05:57:33PM +0800, Yunhui Cui wrote:
> 1. Some bootloaders do not support EFI, and the transfer of
> firmware information can only be done through DTS,
> such as Coreboot.
>
> 2. Some arches do not have a reserved address segment that
> can be used to pass firmware parameters like x86.
>
> 3. Based on this, we have added an interface to obtain firmware
> information through FDT, named FFI.
>
> 4. We not only use FFI to pass SMBIOS entry,
> but also pass other firmware information as an extension.
nit: please don't write your commit messages as bullet lists
> +FDT FIRMWARE INTERFACE (FFI)
> +M: Yunhui Cui cuiyunhui@bytedance.com
> +S: Maintained
> +F: drivers/firmware/ffi.c
> +F: include/linux/ffi.h
Are you going to apply patches for this, or is someone else?
> EXTERNAL CONNECTOR SUBSYSTEM (EXTCON)
> M: MyungJoo Ham <myungjoo.ham@samsung.com>
> M: Chanwoo Choi <cw00.choi@samsung.com>
> diff --git a/drivers/firmware/Kconfig b/drivers/firmware/Kconfig
> index b59e3041fd62..ea0149fb4683 100644
> --- a/drivers/firmware/Kconfig
> +++ b/drivers/firmware/Kconfig
> @@ -303,6 +303,17 @@ config TURRIS_MOX_RWTM
> other manufacturing data and also utilize the Entropy Bit Generator
> for hardware random number generation.
>
> +config FDT_FW_INTERFACE
> + bool "An interface for passing firmware info through FDT"
> + depends on OF && OF_FLATTREE
> + default n
> + help
> + When some bootloaders do not support EFI, and the arch does not
> + support SMBIOS_ENTRY_POINT_SCAN_START, then you can enable this option
> + to support the transfer of firmware information, such as smbios tables.
Could you express this dependency on !SMBIOS_ENTRY_POINT_SCAN_START in
Kconfig & then simply the text to:
"Enable this option to support the transfer of firmware information,
such as smbios tables, for bootloaders that do not support EFI."
since it would not even appear if the arch supports scanning for the
entry point?
If I was was a punter trying to configure my kernel in menuconfig or
whatever, I should be able to decide based on the help text if I need
this, not going grepping for #defines in headers.
> static void __init dmi_scan_machine(void)
> @@ -660,58 +686,22 @@ static void __init dmi_scan_machine(void)
> char __iomem *p, *q;
> char buf[32];
>
> +#ifdef CONFIG_FDT_FW_INTERFACE
> + if (dmi_sacn_smbios(ffi.smbios3, ffi.smbios))
"dmi_sacn_smbios"
> + goto error;
> +#endif
Does this not mean that if FDT_FW_INTERFACE is enabled, but the platform
wants to use EFI, it won't be able to? The `goto error;` makes this look
mutually exclusive to my efi-unaware eyes.
> if (efi_enabled(EFI_CONFIG_TABLES)) {
> - /*
> - * According to the DMTF SMBIOS reference spec v3.0.0, it is
> - * allowed to define both the 64-bit entry point (smbios3) and
> - * the 32-bit entry point (smbios), in which case they should
> - * either both point to the same SMBIOS structure table, or the
> - * table pointed to by the 64-bit entry point should contain a
> - * superset of the table contents pointed to by the 32-bit entry
> - * point (section 5.2)
> - * This implies that the 64-bit entry point should have
> - * precedence if it is defined and supported by the OS. If we
> - * have the 64-bit entry point, but fail to decode it, fall
> - * back to the legacy one (if available)
> - */
> - if (efi.smbios3 != EFI_INVALID_TABLE_ADDR) {
> - p = dmi_early_remap(efi.smbios3, 32);
> - if (p == NULL)
> - goto error;
> - memcpy_fromio(buf, p, 32);
> - dmi_early_unmap(p, 32);
> -
> - if (!dmi_smbios3_present(buf)) {
> - dmi_available = 1;
> - return;
> - }
> - }
> - if (efi.smbios == EFI_INVALID_TABLE_ADDR)
> + if (dmi_sacn_smbios(efi.smbios3, efi.smbios))
> goto error;
> -
> - /* This is called as a core_initcall() because it isn't
> - * needed during early boot. This also means we can
> - * iounmap the space when we're done with it.
> - */
> - p = dmi_early_remap(efi.smbios, 32);
> - if (p == NULL)
> - goto error;
> - memcpy_fromio(buf, p, 32);
> - dmi_early_unmap(p, 32);
> -
> - if (!dmi_present(buf)) {
> - dmi_available = 1;
> - return;
> - }
> diff --git a/drivers/firmware/ffi.c b/drivers/firmware/ffi.c
> new file mode 100644
> index 000000000000..169802b4a7a8
> --- /dev/null
> +++ b/drivers/firmware/ffi.c
> @@ -0,0 +1,36 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +
> +#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
> +
> +#include <linux/of.h>
> +#include <linux/of_fdt.h>
> +#include <linux/libfdt.h>
> +#include <linux/ffi.h>
> +
> +#define FFI_INVALID_TABLE_ADDR (~0UL)
> +
> +struct ffi __read_mostly ffi = {
> + .smbios = FFI_INVALID_TABLE_ADDR,
> + .smbios3 = FFI_INVALID_TABLE_ADDR,
> +};
> +EXPORT_SYMBOL(ffi);
> +// SPDX-License-Identifier: GPL-2.0-only
Why not EXPORT_SYMBOL_GPL? But also, who is the user of this export?
> +
> +void __init ffi_smbios_root_pointer(void)
> +{
> + int cfgtbl, len;
> + fdt64_t *prop;
> +
> + cfgtbl = fdt_path_offset(initial_boot_params, "/cfgtables");
These DT properties need to be documented in a binding.
> + if (cfgtbl < 0) {
> + pr_info("firmware table not found.\n");
Isn't it perfectly valid for a DT not to contain this table? This print
should be, at the very least, a pr_debug().
> + return;
> + }
> + prop = fdt_getprop_w(initial_boot_params, cfgtbl, "smbios_phy_ptr", &len);
Again, undocumented DT property. Please document them in a binding.
> + if (!prop || len != sizeof(u64))
> + pr_info("smbios entry point not found.\n");
> + else
> + ffi.smbios = fdt64_to_cpu(*prop);
> +
> + pr_info("smbios root pointer: %lx\n", ffi.smbios);
ffi.smbios is not set if (!prop || len != sizeof(u64)), looks like your
"if" should return and the contents of the else become unconditional?
Otherwise, this print seems wrong.
> +}
> +
> diff --git a/include/linux/ffi.h b/include/linux/ffi.h
> new file mode 100644
> index 000000000000..95298a805222
> --- /dev/null
> +++ b/include/linux/ffi.h
> @@ -0,0 +1,15 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +
> +#ifndef _LINUX_FFI_H
> +#define _LINUX_FFI_H
> +
> +extern struct ffi {
> + unsigned long smbios; /* SMBIOS table (32 bit entry point) */
> + unsigned long smbios3; /* SMBIOS table (64 bit entry point) */
> + unsigned long flags;
> +
> +} ffi;
> +
> +void ffi_smbios_root_pointer(void);
Please provide a stub for !FDT_FW_INTERFACE so that we don't need
ifdeffery at callsites.
Cheers,
Conor.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
next prev parent reply other threads:[~2023-07-02 12:41 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-07-02 9:57 [PATCH v2 1/3] riscv: obtain ACPI RSDP from FFI Yunhui Cui
2023-07-02 9:57 ` [PATCH v2 2/3] firmware: introduce FFI for SMBIOS entry Yunhui Cui
2023-07-02 12:41 ` Conor Dooley [this message]
2023-07-03 8:23 ` [External] " 运辉崔
2023-07-03 8:34 ` Conor Dooley
2023-07-03 12:41 ` 运辉崔
2023-07-03 13:02 ` Conor Dooley
2023-07-03 13:26 ` 运辉崔
2023-07-02 9:57 ` [PATCH v2 3/3] riscv: obtain SMBIOS entry from FFI Yunhui Cui
2023-07-02 12:42 ` Conor Dooley
2023-07-03 7:50 ` [External] " 运辉崔
2023-07-03 8:16 ` Conor Dooley
2023-07-02 13:47 ` [PATCH v2 1/3] riscv: obtain ACPI RSDP " Conor Dooley
2023-07-03 4:21 ` Sunil V L
2023-07-03 6:19 ` [External] " 运辉崔
2023-07-03 7:19 ` 运辉崔
2023-07-03 8:12 ` Conor Dooley
2023-07-03 10:16 ` 运辉崔
2023-07-03 12:18 ` Conor Dooley
2023-07-03 13:04 ` 运辉崔
2023-07-03 13:01 ` Andrew Jones
2023-07-03 13:30 ` [External] " 运辉崔
2023-07-03 14:17 ` Andrew Jones
2023-07-03 14:23 ` Conor Dooley
2023-07-03 18:58 ` Emil Renner Berthing
2023-07-03 21:32 ` [External] " Jessica Clarke
2023-07-05 14:42 ` Björn Töpel
2023-07-06 2:24 ` 运辉崔
2023-07-06 8:52 ` Björn Töpel
[not found] ` <CAP6exY+gTSxU95nDK14z-Y1suKeXPkLzZ_BZqr-vRVGO9qmcxg@mail.gmail.com>
2023-07-07 9:05 ` Björn Töpel
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=20230702-collide-rumor-f0d915a4f1b2@spud \
--to=conor@kernel.org \
--cc=allen-kh.cheng@mediatek.com \
--cc=angelogioacchino.delregno@collabora.com \
--cc=aou@eecs.berkeley.edu \
--cc=ardb@kernel.org \
--cc=cuiyunhui@bytedance.com \
--cc=geshijian@bytedance.com \
--cc=jdelvare@suse.com \
--cc=lenb@kernel.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-riscv@lists.infradead.org \
--cc=lpieralisi@kernel.org \
--cc=mark.rutland@arm.com \
--cc=palmer@dabbelt.com \
--cc=paul.walmsley@sifive.com \
--cc=pierre-louis.bossart@linux.intel.com \
--cc=rafael@kernel.org \
--cc=rminnich@gmail.com \
--cc=tinghan.shen@mediatek.com \
--cc=weidong.wd@bytedance.com \
--cc=yc.hung@mediatek.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