diff mbox series

[v3,4/4] dt-bindings: firmware: Document ffitbl binding

Message ID 20230705114251.661-5-cuiyunhui@bytedance.com
State New
Headers show
Series Obtain SMBIOS and ACPI entry from FFI | expand

Commit Message

yunhui cui July 5, 2023, 11:42 a.m. UTC 
Add the description for ffitbl subnode.

Signed-off-by: Yunhui Cui <cuiyunhui@bytedance.com>
---
 .../devicetree/bindings/firmware/ffitbl.txt   | 27 +++++++++++++++++++
 MAINTAINERS                                   |  1 +
 2 files changed, 28 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/firmware/ffitbl.txt

Comments

yunhui cui July 6, 2023, 3:43 a.m. UTC | #1 
Hi Conor,

Added dts Maintainers,

On Wed, Jul 5, 2023 at 11:07 PM Conor Dooley <conor@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@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
>
> Firstly, new dt-bindings need to be done in yaml, not in text form.
> Secondly, you didn't re-run get_maintainer.pl after adding this binding,
> so you have not CCed any of the other dt-binding maintainers nor the
> devicetree mailing list.

Re-run get_maintainer.pl and added maintainers into the maillist.
emm.. There is some *txt in
Documentation/devicetree/bindings/firmware/, isn't it?

>
> > @@ -0,0 +1,27 @@
>
> > +FFI(FDT FIRMWARE INTERFACE) driver
> > +
> > +Required properties:
> > + - entry             : acpi or smbios root pointer, u64
> > + - reg                       : acpi or smbios version, u32
>
> Please go look at any other dt-binding (or the example schema) as to how
> these properties should be used. A "reg" certainly should not be being
> used to store the revision...

Okay, If so，I'll add a property "version" into the dts instead of
"reg", just like, WDYT?
ffitbl {
    smbios {
        entry = "";
        version = < 0x02 >;
    }
   acpi {
         entry = "";
         version = < 0x06 >;
  }
}

>
> Cheers,
> Conor.
>
> > +
> > +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.
> > +This feature is known as FDT Firmware Interface (FFI).
> > +
> > +Example:
> > +     ffitbl {
> > +
> > +             smbios {
> > +                             entry = "";
> > +                             reg = < 0x03 >;
> > +
> > +             }
> > +             acpi {
> > +                             entry = "";
> > +                             reg = < 0x06 >;
> > +
> > +             }
> > +     }
> > +
> > diff --git a/MAINTAINERS b/MAINTAINERS
> > index 9b886ef36587..008257e55062 100644
> > --- a/MAINTAINERS
> > +++ b/MAINTAINERS
> > @@ -7874,6 +7874,7 @@ F:      include/linux/efi*.h
> >  FDT FIRMWARE INTERFACE (FFI)
> >  M:   Yunhui Cui cuiyunhui@bytedance.com
> >  S:   Maintained
> > +F:   Documentation/devicetree/bindings/firmware/ffitbl.txt
> >  F:   drivers/firmware/ffi.c
> >  F:   include/linux/ffi.h
> >
> > --
> > 2.20.1
> >

Thanks,
Yunhui
Krzysztof Kozlowski July 6, 2023, 6 a.m. UTC | #2 
On 06/07/2023 05:43, 运辉崔 wrote:
> Hi Conor,
> 
> Added dts Maintainers,
> 
> On Wed, Jul 5, 2023 at 11:07 PM Conor Dooley <conor@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@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
>>
>> Firstly, new dt-bindings need to be done in yaml, not in text form.
>> Secondly, you didn't re-run get_maintainer.pl after adding this binding,
>> so you have not CCed any of the other dt-binding maintainers nor the
>> devicetree mailing list.
> 
> Re-run get_maintainer.pl and added maintainers into the maillist.


This does not work like this.

Please use scripts/get_maintainers.pl to get a list of necessary people
and lists to CC.  It might happen, that command when run on an older
kernel, gives you outdated entries.  Therefore please be sure you base
your patches on recent Linux kernel.

You missed at least DT list (maybe more), so this won't be tested by our
tools. Performing review on untested code might be a waste of time, thus
I will skip this patch entirely till you follow the process allowing the
patch to be tested.

Please kindly resend and include all necessary To/Cc entries.

> emm.. There is some *txt in
> Documentation/devicetree/bindings/firmware/, isn't it?

And what about it? Do you claim they were added recently?

Best regards,
Krzysztof
yunhui cui July 6, 2023, 6:24 a.m. UTC | #3 
Hi Krzysztof,

On Thu, Jul 6, 2023 at 2:01 PM Krzysztof Kozlowski
<krzysztof.kozlowski@linaro.org> wrote:
>
> On 06/07/2023 05:43, 运辉崔 wrote:
> > Hi Conor,
> >
> > Added dts Maintainers,
> >
> > On Wed, Jul 5, 2023 at 11:07 PM Conor Dooley <conor@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@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
> >>
> >> Firstly, new dt-bindings need to be done in yaml, not in text form.
> >> Secondly, you didn't re-run get_maintainer.pl after adding this binding,
> >> so you have not CCed any of the other dt-binding maintainers nor the
> >> devicetree mailing list.
> >
> > Re-run get_maintainer.pl and added maintainers into the maillist.
>
>
> This does not work like this.
>
> Please use scripts/get_maintainers.pl to get a list of necessary people
> and lists to CC.  It might happen, that command when run on an older
> kernel, gives you outdated entries.  Therefore please be sure you base
> your patches on recent Linux kernel.
>
> You missed at least DT list (maybe more), so this won't be tested by our
> tools. Performing review on untested code might be a waste of time, thus
> I will skip this patch entirely till you follow the process allowing the
> patch to be tested.
>
> Please kindly resend and include all necessary To/Cc entries.

This set of patches is applied on the tag next-20230706, and to
generate the mail list by scripts/get_maintainers.pl on the tag

./scripts/get_maintainer.pl
../riscv/linux/v3-0004-dt-bindings-firmware-Document-ffitbl-binding.patch
Yunhui Cui cuiyunhui@bytedance.com (maintainer:FDT FIRMWARE INTERFACE (FFI))
Rob Herring <robh+dt@kernel.org> (maintainer:OPEN FIRMWARE AND
FLATTENED DEVICE TREE BINDINGS)
Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>
(maintainer:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS)
Conor Dooley <conor+dt@kernel.org> (maintainer:OPEN FIRMWARE AND
FLATTENED DEVICE TREE BINDINGS)
devicetree@vger.kernel.org (open list:OPEN FIRMWARE AND FLATTENED
DEVICE TREE BINDINGS)
linux-kernel@vger.kernel.org (open list)

What am I missing ?


> > emm.. There is some *txt in
> > Documentation/devicetree/bindings/firmware/, isn't it?
>
> And what about it? Do you claim they were added recently?
>
> Best regards,
> Krzysztof
>

Thanks,
Yunhui
Krzysztof Kozlowski July 6, 2023, 6:41 a.m. UTC | #4 
On 06/07/2023 08:24, 运辉崔 wrote:
> Hi Krzysztof,
> 
> On Thu, Jul 6, 2023 at 2:01 PM Krzysztof Kozlowski
> <krzysztof.kozlowski@linaro.org> wrote:
>>
>> On 06/07/2023 05:43, 运辉崔 wrote:
>>> Hi Conor,
>>>
>>> Added dts Maintainers,
>>>
>>> On Wed, Jul 5, 2023 at 11:07 PM Conor Dooley <conor@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@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
>>>>
>>>> Firstly, new dt-bindings need to be done in yaml, not in text form.
>>>> Secondly, you didn't re-run get_maintainer.pl after adding this binding,
>>>> so you have not CCed any of the other dt-binding maintainers nor the
>>>> devicetree mailing list.
>>>
>>> Re-run get_maintainer.pl and added maintainers into the maillist.
>>
>>
>> This does not work like this.
>>
>> Please use scripts/get_maintainers.pl to get a list of necessary people
>> and lists to CC.  It might happen, that command when run on an older
>> kernel, gives you outdated entries.  Therefore please be sure you base
>> your patches on recent Linux kernel.
>>
>> You missed at least DT list (maybe more), so this won't be tested by our
>> tools. Performing review on untested code might be a waste of time, thus
>> I will skip this patch entirely till you follow the process allowing the
>> patch to be tested.
>>
>> Please kindly resend and include all necessary To/Cc entries.
> 
> This set of patches is applied on the tag next-20230706, and to
> generate the mail list by scripts/get_maintainers.pl on the tag
> 
> ./scripts/get_maintainer.pl
> ../riscv/linux/v3-0004-dt-bindings-firmware-Document-ffitbl-binding.patch
> Yunhui Cui cuiyunhui@bytedance.com (maintainer:FDT FIRMWARE INTERFACE (FFI))
> Rob Herring <robh+dt@kernel.org> (maintainer:OPEN FIRMWARE AND
> FLATTENED DEVICE TREE BINDINGS)
> Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>
> (maintainer:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS)
> Conor Dooley <conor+dt@kernel.org> (maintainer:OPEN FIRMWARE AND
> FLATTENED DEVICE TREE BINDINGS)
> devicetree@vger.kernel.org (open list:OPEN FIRMWARE AND FLATTENED
> DEVICE TREE BINDINGS)
> linux-kernel@vger.kernel.org (open list)
> 
> What am I missing ?

I did not receive the original patch. Neither did Patchwork. You cannot
just reply to some comment and hope it will fix something. We don't have
this patch simply.



Best regards,
Krzysztof
Conor Dooley July 6, 2023, 6:44 a.m. UTC | #5 
On Thu, Jul 06, 2023 at 11:43:55AM +0800, 运辉崔 wrote:
> On Wed, Jul 5, 2023 at 11:07 PM Conor Dooley <conor@kernel.org> wrote:
> > 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@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
> >
> > Firstly, new dt-bindings need to be done in yaml, not in text form.
> > Secondly, you didn't re-run get_maintainer.pl after adding this binding,
> > so you have not CCed any of the other dt-binding maintainers nor the
> > devicetree mailing list.
> 
> Re-run get_maintainer.pl and added maintainers into the maillist.
> emm.. There is some *txt in
> Documentation/devicetree/bindings/firmware/, isn't it?

There might be, but that's not an excuse for adding _new_ ones, sorry.

> > > +FFI(FDT FIRMWARE INTERFACE) driver
> > > +
> > > +Required properties:
> > > + - entry             : acpi or smbios root pointer, u64
> > > + - reg                       : acpi or smbios version, u32
> >
> > Please go look at any other dt-binding (or the example schema) as to how
> > these properties should be used. A "reg" certainly should not be being
> > used to store the revision...
> 
> Okay, If so，I'll add a property "version" into the dts instead of
> "reg", just like, WDYT?
> ffitbl {

Firstly, I'd much rather you spelt this out, like "ffi-table".

>     smbios {
>         entry = "";

I still don't understand why "entry", which is an address, is being
represented by an empty string.
I also don't really get why you have not used "reg" to describe its
start address and size.

>         version = < 0x02 >;

Probably missing a vendor prefix, and the spaces are unusual, but better
than it was, yes.

>     }
>    acpi {
>          entry = "";
>          version = < 0x06 >;
>   }
> }

Thanks,
Conor.
yunhui cui July 6, 2023, 6:55 a.m. UTC | #6 
Hi Krzysztof,


On Thu, Jul 6, 2023 at 2:41 PM Krzysztof Kozlowski
<krzysztof.kozlowski@linaro.org> wrote:
>
> On 06/07/2023 08:24, 运辉崔 wrote:
> > Hi Krzysztof,
> >
> > On Thu, Jul 6, 2023 at 2:01 PM Krzysztof Kozlowski
> > <krzysztof.kozlowski@linaro.org> wrote:
> >>
> >> On 06/07/2023 05:43, 运辉崔 wrote:
> >>> Hi Conor,
> >>>
> >>> Added dts Maintainers,
> >>>
> >>> On Wed, Jul 5, 2023 at 11:07 PM Conor Dooley <conor@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@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
> >>>>
> >>>> Firstly, new dt-bindings need to be done in yaml, not in text form.
> >>>> Secondly, you didn't re-run get_maintainer.pl after adding this binding,
> >>>> so you have not CCed any of the other dt-binding maintainers nor the
> >>>> devicetree mailing list.
> >>>
> >>> Re-run get_maintainer.pl and added maintainers into the maillist.
> >>
> >>
> >> This does not work like this.
> >>
> >> Please use scripts/get_maintainers.pl to get a list of necessary people
> >> and lists to CC.  It might happen, that command when run on an older
> >> kernel, gives you outdated entries.  Therefore please be sure you base
> >> your patches on recent Linux kernel.
> >>
> >> You missed at least DT list (maybe more), so this won't be tested by our
> >> tools. Performing review on untested code might be a waste of time, thus
> >> I will skip this patch entirely till you follow the process allowing the
> >> patch to be tested.
> >>
> >> Please kindly resend and include all necessary To/Cc entries.
> >
> > This set of patches is applied on the tag next-20230706, and to
> > generate the mail list by scripts/get_maintainers.pl on the tag
> >
> > ./scripts/get_maintainer.pl
> > ../riscv/linux/v3-0004-dt-bindings-firmware-Document-ffitbl-binding.patch
> > Yunhui Cui cuiyunhui@bytedance.com (maintainer:FDT FIRMWARE INTERFACE (FFI))
> > Rob Herring <robh+dt@kernel.org> (maintainer:OPEN FIRMWARE AND
> > FLATTENED DEVICE TREE BINDINGS)
> > Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>
> > (maintainer:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS)
> > Conor Dooley <conor+dt@kernel.org> (maintainer:OPEN FIRMWARE AND
> > FLATTENED DEVICE TREE BINDINGS)
> > devicetree@vger.kernel.org (open list:OPEN FIRMWARE AND FLATTENED
> > DEVICE TREE BINDINGS)
> > linux-kernel@vger.kernel.org (open list)
> >
> > What am I missing ?
>
> I did not receive the original patch. Neither did Patchwork. You cannot
> just reply to some comment and hope it will fix something. We don't have
> this patch simply.

Oh, I see, you only received the middle mail, and did not receive the patch.
Okay, I'll post it after the next version is updated.

>
> Best regards,
> Krzysztof
>

Thanks,
Yunhui
yunhui cui July 6, 2023, 9:02 a.m. UTC | #7 
Hi Conor,

On Thu, Jul 6, 2023 at 2:45 PM Conor Dooley <conor.dooley@microchip.com> wrote:
>
> On Thu, Jul 06, 2023 at 11:43:55AM +0800, 运辉崔 wrote:
> > On Wed, Jul 5, 2023 at 11:07 PM Conor Dooley <conor@kernel.org> wrote:
> > > 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@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
> > >
> > > Firstly, new dt-bindings need to be done in yaml, not in text form.
> > > Secondly, you didn't re-run get_maintainer.pl after adding this binding,
> > > so you have not CCed any of the other dt-binding maintainers nor the
> > > devicetree mailing list.
> >
> > Re-run get_maintainer.pl and added maintainers into the maillist.
> > emm.. There is some *txt in
> > Documentation/devicetree/bindings/firmware/, isn't it?
>
> There might be, but that's not an excuse for adding _new_ ones, sorry.

Okay, I'll update it on v4.


> > > > +FFI(FDT FIRMWARE INTERFACE) driver
> > > > +
> > > > +Required properties:
> > > > + - entry             : acpi or smbios root pointer, u64
> > > > + - reg                       : acpi or smbios version, u32
> > >
> > > Please go look at any other dt-binding (or the example schema) as to how
> > > these properties should be used. A "reg" certainly should not be being
> > > used to store the revision...
> >
> > Okay, If so，I'll add a property "version" into the dts instead of
> > "reg", just like, WDYT?
> > ffitbl {
>
> Firstly, I'd much rather you spelt this out, like "ffi-table".
>
> >     smbios {
> >         entry = "";
>
> I still don't understand why "entry", which is an address, is being
> represented by an empty string.
> I also don't really get why you have not used "reg" to describe its
> start address and size.
>
> >         version = < 0x02 >;
>
> Probably missing a vendor prefix, and the spaces are unusual, but better
> than it was, yes.

Based on your review, I plan to modify it as follows:

ffi-table {
#address-cells = <2>;
#size-cells = <0>;
        smbios@entry1 {
                compatible = "smbios";
                reg = <entry1>;
                version = <2>;
        };
        smbios@entry2 {
                compatible = "smbios";
                reg = <entry2>;
                version = <3>;
        };
        acpi@entry {
                compatible = "acpi";
                reg = <entry>;
                version = <6>;
        };
}

The reason why #size-cells is 0 is because only one item is needed,
#address-cells = <2>; because two u32 are needed to express the 64-bit
address.
The memory for the SMBIOS table itself will be preserved in "reserved
memory" , so we don't have to worry about this piece of memory getting
corrupted. ACPI as well. WDYT?

> >     }
> >    acpi {
> >          entry = "";
> >          version = < 0x06 >;
> >   }
> > }
>
> Thanks,
> Conor.

Thanks,
Yunhui
Conor Dooley July 7, 2023, 4:16 p.m. UTC | #8 
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@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

NAKed-by: Conor Dooley <conor.dooley@microchip.com>

Cheers,
Conor.

[1] - https://lore.kernel.org/linux-riscv/20230707-attach-conjuror-306d967347ce@wendy/
yunhui cui July 8, 2023, 3:04 a.m. UTC | #9 
Hi Conor,

On Sat, Jul 8, 2023 at 12:53 AM 葛士建 <geshijian@bytedance.com> wrote:
>
>
>
>
> On Sat, Jul 8, 2023 at 12:16 AM Conor Dooley <conor@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@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.
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 <conor.dooley@microchip.com>
>>
>> Cheers,
>> Conor.
>>
>> [1] - https://lore.kernel.org/linux-riscv/20230707-attach-conjuror-306d967347ce@wendy/

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

Patch

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.
+This feature is known as FDT Firmware Interface (FFI).
+
+Example:
+	ffitbl {
+
+		smbios {
+				entry = "";
+				reg = < 0x03 >;
+
+		}
+		acpi {
+				entry = "";
+				reg = < 0x06 >;
+
+		}
+	}
+
diff --git a/MAINTAINERS b/MAINTAINERS
index 9b886ef36587..008257e55062 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -7874,6 +7874,7 @@  F:	include/linux/efi*.h
 FDT FIRMWARE INTERFACE (FFI)
 M:	Yunhui Cui cuiyunhui@bytedance.com
 S:	Maintained
+F:	Documentation/devicetree/bindings/firmware/ffitbl.txt
 F:	drivers/firmware/ffi.c
 F:	include/linux/ffi.h