On 06/02/2025 14:27, Mike Rapoport wrote: > From: "Mike Rapoport (Microsoft)" <rppt@xxxxxxxxxx> > > We introduced KHO into Linux: A framework that allows Linux to pass > metadata and memory across kexec from Linux to Linux. KHO reuses fdt > as file format and shares a lot of the same properties of firmware-to- > Linux boot formats: It needs a stable, documented ABI that allows for > forward and backward compatibility as well as versioning. Please use subject prefixes matching the subsystem. You can get them for example with `git log --oneline -- DIRECTORY_OR_FILE` on the directory your patch is touching. For bindings, the preferred subjects are explained here: https://www.kernel.org/doc/html/latest/devicetree/bindings/submitting-patches.html#i-for-patch-submitters > > As first user of KHO, we introduced memblock which can now preserve > memory ranges reserved with reserve_mem command line options contents > across kexec, so you can use the post-kexec kernel to read traces from > the pre-kexec kernel. > > This patch adds memblock schemas similar to "device" device tree ones to > a new kho bindings directory. This allows us to force contributors to > document the data that moves across KHO kexecs and catch breaking change > during review. > > Co-developed-by: Alexander Graf <graf@xxxxxxxxxx> > Signed-off-by: Alexander Graf <graf@xxxxxxxxxx> > Signed-off-by: Mike Rapoport (Microsoft) <rppt@xxxxxxxxxx> > --- > .../kho/bindings/memblock/reserve_mem.yaml | 41 ++++++++++++++++++ > .../bindings/memblock/reserve_mem_map.yaml | 42 +++++++++++++++++++ > 2 files changed, 83 insertions(+) > create mode 100644 Documentation/kho/bindings/memblock/reserve_mem.yaml > create mode 100644 Documentation/kho/bindings/memblock/reserve_mem_map.yaml > > diff --git a/Documentation/kho/bindings/memblock/reserve_mem.yaml b/Documentation/kho/bindings/memblock/reserve_mem.yaml > new file mode 100644 > index 000000000000..7b01791b10b3 > --- /dev/null > +++ b/Documentation/kho/bindings/memblock/reserve_mem.yaml > @@ -0,0 +1,41 @@ > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/memblock/reserve_mem.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: Memblock reserved memory > + > +maintainers: > + - Mike Rapoport <rppt@xxxxxxxxxx> > + > +description: | > + Memblock can serialize its current memory reservations created with > + reserve_mem command line option across kexec through KHO. > + The post-KHO kernel can then consume these reservations and they are > + guaranteed to have the same physical address. > + > +properties: > + compatible: > + enum: > + - reserve_mem-v1 NAK, underscores are not allowed. Please follow carefully DTS coding style. > + > +patternProperties: > + "$[0-9a-f_]+^": No underscores. > + $ref: reserve_mem_map.yaml# > + description: reserved memory regions > + > +required: > + - compatible > + > +additionalProperties: false > + > +examples: > + - | > + reserve_mem { Again, do not introduce own coding style. I don't understand why do you need this in the first place. There is already reserved-memory block. > + compatible = "reserve_mem-v1"; > + r1 { > + compatible = "reserve_mem_map-v1"; > + mem = <0xc07c 0x2000000 0x01 0x00>; > + }; > + }; > diff --git a/Documentation/kho/bindings/memblock/reserve_mem_map.yaml b/Documentation/kho/bindings/memblock/reserve_mem_map.yaml > new file mode 100644 > index 000000000000..09001c5f2124 > --- /dev/null > +++ b/Documentation/kho/bindings/memblock/reserve_mem_map.yaml > @@ -0,0 +1,42 @@ > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/memblock/reserve_mem_map.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: Memblock reserved memory regions > + > +maintainers: > + - Mike Rapoport <rppt@xxxxxxxxxx> > + > +description: | > + Memblock can serialize its current memory reservations created with > + reserve_mem command line option across kexec through KHO. > + This object describes each such region. > + > +properties: > + compatible: > + enum: > + - reserve_mem_map-v1 Explain why you cannot use existing reserved memory bindings. Best regards, Krzysztof