[External] Re: [PATCH v3 0/4] Obtain SMBIOS and ACPI entry from FFI

[运辉崔]

Hi Palmer,

On Wed, Jul 5, 2023 at 10:17 PM Palmer Dabbelt <palmer at dabbelt.com> wrote:
>
> On Wed, 05 Jul 2023 04:42:47 PDT (-0700), cuiyunhui at bytedance.com wrote:
> > Here's version 3 of patch series.
> >
> > V1: The FFI (FDT FIRMWARE INTERFACE) scheme has reached a
> > consensus with the Maintainers.
> > Please refer to:
> > https://patches.linaro.org/project/linux-acpi/patch/20230426034001.16-1-cuiyunhui@bytedance.com/
>
> From looking at that thread it seems that the consensus is this is a bad
> idea?  Sorry if I'm just missing something...
>

First of all, Coreboot does not support EFI, Ron has expressed, as follows:
"I am wondering if we can focus on risc-v here, and not drag in ARM,
b/c the ARM ACPI+UEFI ship has sailed. I had that discussion in 2013
;-) and it's clear we don't want to redo it.
In general, in my world, because of the many problems that come with
UEFI (security, code quality, performance), we'd like to avoid
requiring a dependency on UEFI just to get ACPI on RISC-V. It also
seems, from other discussions I'm having, that there is some belief
that ACPI will be wanted on RISC-V. It would be nice to separate those
pieces on RISC-V; certainly they were separate for a very long time in
the x86 world (we had ACPI+SMM on coreboot laptops without UEFI for
example)."

Then, a consensus was reached with Ard, that FFI can be applied to RISC-V.

Please look at this patch again: [PATCH v3 1/4] riscv: obtain ACPI
RSDP from devicetree
Why do you think it is a bad idea?


> > Changes v1->v2:
> > Adjusted the code structure, put the ACPI part under the RISC-V architecture,
> > and put the general part of obtaining SMBIOS entry through FFI
> > under driver/firmware/.
> > Please refer to:
> > https://lore.kernel.org/lkml/20230703-71f67eb66a037f5c0fb825c6@orel/T/
> >
> > Changes v2->v3:
> > According to the suggestions of maintainers, the code has been modified as follows:
> > 1. Modified the commit log.
> > 2. Added description of "ffitbl" subnod in dt-bindings.
> > 3. Add stub function to the function
> > 4. arch/riscv/ and driver/firmware/ use CONFIG_FDT_FW_INTERFACE to control
> > 5. Modified the ffi_smbios_root_pointer() function logic and printing
> > etc.
> >
> > Yunhui Cui (4):
> >   riscv: obtain ACPI RSDP from devicetree
> >   firmware: introduce FFI for SMBIOS entry
> >   riscv: obtain SMBIOS entry from FFI
> >   dt-bindings: firmware: Document ffitbl binding
> >
> >  .../devicetree/bindings/firmware/ffitbl.txt   | 27 ++++++
> >  MAINTAINERS                                   | 13 +++
> >  arch/riscv/include/asm/acpi.h                 |  9 ++
> >  arch/riscv/include/asm/ffi.h                  | 14 +++
> >  arch/riscv/kernel/Makefile                    |  1 +
> >  arch/riscv/kernel/ffi.c                       | 40 ++++++++
> >  arch/riscv/kernel/setup.c                     |  2 +
> >  drivers/firmware/Kconfig                      | 11 +++
> >  drivers/firmware/Makefile                     |  1 +
> >  drivers/firmware/dmi_scan.c                   | 97 +++++++++++--------
> >  drivers/firmware/ffi.c                        | 42 ++++++++
> >  include/linux/ffi.h                           | 29 ++++++
> >  12 files changed, 246 insertions(+), 40 deletions(-)
> >  create mode 100644 Documentation/devicetree/bindings/firmware/ffitbl.txt
> >  create mode 100644 arch/riscv/include/asm/ffi.h
> >  create mode 100644 arch/riscv/kernel/ffi.c
> >  create mode 100644 drivers/firmware/ffi.c
> >  create mode 100644 include/linux/ffi.h

Thanks,
Yunhui