Re: [External] Re: [PATCH v3 4/4] dt-bindings: firmware: Document ffitbl binding

[Conor Dooley]

On 8 July 2023 04:04:05 IST, "运辉崔" <cuiyunhui at bytedance.com> wrote:
>Hi Conor,
>
>On Sat, Jul 8, 2023 at 12:53 AM 葛士建 <geshijian at bytedance.com> wrote:
>>
>>
>>
>>
>> On Sat, Jul 8, 2023 at 12:16 AM Conor Dooley <conor at kernel.org> 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 at bytedance.com>
>>> > ---
>>> >  .../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 at microchip.com>
>>>
>>> Cheers,
>>> Conor.
>>>
>>> [1] - https://lore.kernel.org/linux-riscv/20230707-attach-conjuror-306d967347ce@wendy/
>
>Thanks,
>Yunhui