Hi Ard, 1. Regarding the definition of DTS FFI nodes, according to your suggestion, we plan to make the following modifications: / { ... ffi_cfg { acpi_tbl { root_pinter = ; //u64 ... }; smbios_tbl { root_pinter = ; //u64 ... }; }; ... }; 2. Let's move on to the discussion: should we put code under arch/risc-v/? On Mon, Jun 26, 2023 at 6:19 PM 运辉崔 <cuiyunhui@xxxxxxxxxxxxx> wrote: > > Hi Ard, Mark, > > On Mon, Jun 26, 2023 at 4:23 PM Ard Biesheuvel <ardb@xxxxxxxxxx> wrote: > > > DT support for SMBIOS can live in generic code, but the binding has to > > be sane. As I suggested before, it probably makes sense to supplant > > the entrypoint rather than just carry its address - this means a 'reg' > > property with base and size to describe the physical region, and at > > least major/minor/docrev fields to describe the version. > > Regarding dts node binding, our current definition is as follows: > /dts > { > ... > cfgtables { > acpi_phy_ptr = 0000000000000000; //u64 > smbios_phy_ptr = 0000000000000000; //u64 > ... > } > ... > } > > x86 only gave a root_pointer entry address > u64 x86_default_get_root_pointer(void) > { > return boot_params.acpi_rsdp_addr; > } > > Regarding the naming of the binding above, Mark, do you have any suggestions? > > > > For the ACPI side, you should just implement > > acpi_arch_get_root_pointer() under arch/riscv, and wire it up in > > whichever way you want. But please check with the RISC-V maintainers > > if they are up for this, and whether they want to see this mechanism > > contributed to one of the pertinent specifications. > > You suggest putting SMBIOS in general code instead of ACPI, why? > From the perspective of firmware information passing, they are a class. > > SMBIOS and ACPI are not related to ARCH, nor is DTS to obtain firmware > information, > > Why do you have to put part of the ACPI code under arch/risc-v/? > The scope of the previous discussion was limited to RISC-V because of > historical reasons such as the binding with EFI on ARM64. We will only > enable this function on RISC-V in subsequent patches. > > The realization of the FFI scheme itself is irrelevant to the arch. > > Thanks, > Yunhui