lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAGXv+5FPaJMuN7wCP7g0Rxa0mXD3Ru0rxka=m8B_rv+XUkJPWA@mail.gmail.com>
Date: Tue, 25 Nov 2025 18:41:07 +0800
From: Chen-Yu Tsai <wenst@...omium.org>
To: Krzysztof Kozlowski <krzk@...nel.org>
Cc: Rob Herring <robh@...nel.org>, Krzysztof Kozlowski <krzk+dt@...nel.org>, 
	Conor Dooley <conor+dt@...nel.org>, devicetree@...r.kernel.org, 
	chrome-platform@...ts.linux.dev, Julius Werner <jwerner@...omium.org>, 
	linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] dt-bindings: firmware: coreboot: Convert to YAML

On Tue, Nov 25, 2025 at 6:08 PM Krzysztof Kozlowski <krzk@...nel.org> wrote:
>
> On Tue, Nov 25, 2025 at 02:48:49PM +0800, Chen-Yu Tsai wrote:
> > Convert the existing text binding to YAML.
> >
> > The description has been change to reflect the possibility of coreboot
> > inserting the node itself.
> >
> > The example has been modified to compile and pass validation without
> > any errors. A comment was added to note what the firmware actually
> > emits.
> >
> > Signed-off-by: Chen-Yu Tsai <wenst@...omium.org>
> > ---
> >  .../devicetree/bindings/firmware/coreboot.txt | 33 ----------
> >  .../bindings/firmware/coreboot.yaml           | 60 +++++++++++++++++++
> >  2 files changed, 60 insertions(+), 33 deletions(-)
> >  delete mode 100644 Documentation/devicetree/bindings/firmware/coreboot.txt
> >  create mode 100644 Documentation/devicetree/bindings/firmware/coreboot.yaml
> >
> > diff --git a/Documentation/devicetree/bindings/firmware/coreboot.txt b/Documentation/devicetree/bindings/firmware/coreboot.txt
> > deleted file mode 100644
> > index 4c955703cea8..000000000000
> > --- a/Documentation/devicetree/bindings/firmware/coreboot.txt
> > +++ /dev/null
> > @@ -1,33 +0,0 @@
> > -COREBOOT firmware information
> > -
> > -The device tree node to communicate the location of coreboot's memory-resident
> > -bookkeeping structures to the kernel. Since coreboot itself cannot boot a
> > -device-tree-based kernel (yet), this node needs to be inserted by a
> > -second-stage bootloader (a coreboot "payload").
> > -
> > -Required properties:
> > - - compatible: Should be "coreboot"
> > - - reg: Address and length of the following two memory regions, in order:
> > -     1.) The coreboot table. This is a list of variable-sized descriptors
> > -     that contain various compile- and run-time generated firmware
> > -     parameters. It is identified by the magic string "LBIO" in its first
> > -     four bytes.
> > -     See coreboot's src/commonlib/include/commonlib/coreboot_tables.h for
> > -     details.
> > -     2.) The CBMEM area. This is a downward-growing memory region used by
> > -     coreboot to dynamically allocate data structures that remain resident.
> > -     It may or may not include the coreboot table as one of its members. It
> > -     is identified by a root node descriptor with the magic number
> > -     0xc0389481 that resides in the topmost 8 bytes of the area.
> > -     See coreboot's src/include/imd.h for details.
> > -
> > -Example:
> > -     firmware {
> > -             ranges;
> > -
> > -             coreboot {
> > -                     compatible = "coreboot";
> > -                     reg = <0xfdfea000 0x264>,
> > -                           <0xfdfea000 0x16000>;
> > -             }
> > -     };
> > diff --git a/Documentation/devicetree/bindings/firmware/coreboot.yaml b/Documentation/devicetree/bindings/firmware/coreboot.yaml
> > new file mode 100644
> > index 000000000000..568afd1abb92
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/firmware/coreboot.yaml
> > @@ -0,0 +1,60 @@
> > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/firmware/coreboot.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: COREBOOT firmware information
>
> Coreboot

OK. Side note, coreboot is stylized in all lowercase letters.
Should I follow that or just use standard English rules?

> > +
> > +maintainers:
> > +  - Julius Werner <jwerner@...omium.org>
> > +
> > +description:
> > +  The device tree node to communicate the location of coreboot's
> > +  memory-resident bookkeeping structures to the kernel. Coreboot's
> > +  FIT image payload can insert the node into the device tree. If a
> > +  second-stage bootloader (a coreboot "payload") is used, then it
> > +  is responsible for inserting the node.
> > +
> > +properties:
> > +  compatible:
> > +    const: coreboot
>
> Blank line (it is always here, there is no example without, which makes
> me wonder which file you took as starting point)

I actually converted the existing text file directly, copying
boilerplate, i.e. the top few lines, from another file.

> > +  reg:
> > +    description: Address and length of the following two memory regions
>
> Drop description, redundant.

Ack.

> > +    items:
> > +      - description:
> > +          The coreboot table. This is a list of variable-sized descriptors
> > +          that contain various compile- and run-time generated firmware
> > +          parameters. It is identified by the magic string "LBIO" in its first
> > +          four bytes.
> > +
> > +          See coreboot's src/commonlib/include/commonlib/coreboot_tables.h for
> > +          details.
> > +      - description:
> > +          The CBMEM area. This is a downward-growing memory region used by
> > +          coreboot to dynamically allocate data structures that remain resident.
> > +          It may or may not include the coreboot table as one of its members. It
> > +          is identified by a root node descriptor with the magic number
> > +          0xc0389481 that resides in the topmost 8 bytes of the area.
> > +
> > +          See coreboot's src/include/imd.h for details.
> > +
> > +required:
> > +  - compatible
> > +  - reg
> > +
> > +additionalProperties: false
> > +
> > +examples:
> > +  - |
> > +    firmware {
> > +        #address-cells = <1>;
> > +        #size-cells = <1>;
> > +        ranges;
> > +
> > +        /* Firmware actually emits "coreboot" node without unit name */
> > +        coreboot@...ea000 {
> > +            compatible = "coreboot";
> > +            reg = <0xfdfea000 0x264>, <0xfdfea000 0x16000>;
>
> That's the same address in both places, so the same one entry. You need
> two distinctive addresses or binding needs changes to have only one item
> as well.

The description does mention that the latter block can include the
former. It's really up to the firmware. If you like I can include
two examples to cover both cases.


ChenYu

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ