Hi Conor,
On Sat, Jul 8, 2023 at 12:53 AM 葛士建 <[email protected]> wrote:
>
>
>
>
> On Sat, Jul 8, 2023 at 12:16 AM Conor Dooley <[email protected]> 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 <[email protected]>
>> > ---
>> > .../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.
The so-called specifications represent the ideas of FFI opponents.
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.
>>
>>
>>
>> NAKed-by: Conor Dooley <[email protected]>
>>
>> Cheers,
>> Conor.
>>
>> [1] - https://lore.kernel.org/linux-riscv/20230707-attach-conjuror-306d967347ce@wendy/
Thanks,
Yunhui
On 8 July 2023 04:04:05 IST, "运辉崔" <[email protected]> wrote:
>Hi Conor,
>
>On Sat, Jul 8, 2023 at 12:53 AM 葛士建 <[email protected]> wrote:
>>
>>
>>
>>
>> On Sat, Jul 8, 2023 at 12:16 AM Conor Dooley <[email protected]> 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 <[email protected]>
>>> > ---
>>> > .../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 <[email protected]>
>>>
>>> Cheers,
>>> Conor.
>>>
>>> [1] - https://lore.kernel.org/linux-riscv/20230707-attach-conjuror-306d967347ce@wendy/
>
>Thanks,
>Yunhui