On 8 July 2023 04:04:05 IST, "运辉崔" <cuiyunhui@xxxxxxxxxxxxx> wrote: >Hi Conor, > >On Sat, Jul 8, 2023 at 12:53 AM 葛士建 <geshijian@xxxxxxxxxxxxx> wrote: >> >> >> >> >> On Sat, Jul 8, 2023 at 12:16 AM Conor Dooley <conor@xxxxxxxxxx> wrote: >>> >>> Hey, >>> >>> On Wed, Jul 05, 2023 at 07:42:51PM +0800, Yunhui Cui wrote: >>> > Add the description for ffitbl subnode. >>> > >>> > Signed-off-by: Yunhui Cui <cuiyunhui@xxxxxxxxxxxxx> >>> > --- >>> > .../devicetree/bindings/firmware/ffitbl.txt | 27 +++++++++++++++++++ >>> > MAINTAINERS | 1 + >>> > 2 files changed, 28 insertions(+) >>> > create mode 100644 Documentation/devicetree/bindings/firmware/ffitbl.txt >>> > >>> > diff --git a/Documentation/devicetree/bindings/firmware/ffitbl.txt b/Documentation/devicetree/bindings/firmware/ffitbl.txt >>> > new file mode 100644 >>> > index 000000000000..c42368626199 >>> > --- /dev/null >>> > +++ b/Documentation/devicetree/bindings/firmware/ffitbl.txt >>> > @@ -0,0 +1,27 @@ >>> > +FFI(FDT FIRMWARE INTERFACE) driver >>> > + >>> > +Required properties: >>> > + - entry : acpi or smbios root pointer, u64 >>> > + - reg : acpi or smbios version, u32 >>> > + >>> > +Some bootloaders, such as Coreboot do not support EFI, >>> > +only devicetree and some arches do not have a reserved >>> > +address segment. Add "ffitbl" subnode to obtain ACPI RSDP >>> > +and SMBIOS entry. >>> >>> Since the conversation on this stuff all seems to be going absolutely >>> nowhere, the ACPI portion of this is intended for use on RISC-V in >>> violation of the RISC-V ACPI specs. It also goes against the >>> requirements of the platform spec. Quoting from [1]: >>> >>> | > Just so we're all on the same page, I just now asked Mark Himelstein >>> | > of RISC-V International if there is anything in RISC-V standards that >>> | > requires UEFI, and the answer is a solid "no." >>> | >>> | Huh? Firstly, running off to invoke RVI is not productive - they don't >>> | maintain the various operating system kernels etc. >>> | Secondly, that does not seem to be true. The platform spec mandates UEFI >>> | for the OS-A server platform, alongside ACPI: >>> | https://github.com/riscv/riscv-platform-specs/blob/main/riscv-platform-spec.adoc#32-boot-process >>> | and the OS-A embedded platform needs to comply with EBBR & use DT: >>> | https://github.com/riscv/riscv-platform-specs/blob/main/riscv-platform-spec.adoc#32-boot-process >>> | >>> | EBBR does say that systems must not provide both ACPI and DT to the OS >>> | loader, but I am far from an expert on these kind of things & am not >>> | sure where something like this where the DT "contains" ACPI would stand. >>> | >>> | The RISC-V ACPI spec also says "UEFI firmware is mandatory to support >>> | ACPI": >>> | https://github.com/riscv-non-isa/riscv-acpi/blob/master/riscv-acpi-guidance.adoc >> >> UEFI firmware is mandatory to support ACPI and coreboot is an option to support ACPI as well. i think it works well for both, I don't think UEFI and ACPI need to be binding together, each UEFI and ACPI also works well with other solutions. > >Thanks for shijian(Nill)'s suggestions. > >Hi Conor, >Thank you very much for your valuable comments on this set of patch >codes, which are very helpful. > >Judging from the current specifications, maybe yes, you can NACK, but >it's better not to rush to conclusions. Naks are not permanent, I can remove it in the future if the specs change. >The so-called specifications represent the ideas of FFI opponents. "So-called"? They _are_ the specs. >What we have to do is to discuss with them and get an effective >consensus, so as to achieve the purpose of updating the specification. Yes, but that needs to be done on tech-brs, not lkml. Thanks, Conor. > >>> >>> >>> >>> NAKed-by: Conor Dooley <conor.dooley@xxxxxxxxxxxxx> >>> >>> Cheers, >>> Conor. >>> >>> [1] - https://lore.kernel.org/linux-riscv/20230707-attach-conjuror-306d967347ce@wendy/ > >Thanks, >Yunhui
