| Message ID | 20250206132754.2596694-15-rppt@kernel.org (mailing list archive) |
|---|---|
| State | New |
| Headers | show |
| Series | kexec: introduce Kexec HandOver (KHO) | expand |
On 06/02/2025 14:27, Mike Rapoport wrote: > From: "Mike Rapoport (Microsoft)" <rppt@kernel.org> > > 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@amazon.com> > Signed-off-by: Alexander Graf <graf@amazon.com> > Signed-off-by: Mike Rapoport (Microsoft) <rppt@kernel.org> > --- > .../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@kernel.org> > + > +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@kernel.org> > + > +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
On Sun, Feb 09, 2025 at 11:29:41AM +0100, Krzysztof Kozlowski wrote: > On 06/02/2025 14:27, Mike Rapoport wrote: > > From: "Mike Rapoport (Microsoft)" <rppt@kernel.org> > > > > 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 These are not devicetree binding for communicating data from firmware to the kernel. These bindings are specific to KHO which is perfectly reflected by the subject. Just a brief reminder from v2 discussion: (https://lore.kernel.org/linux-mm/20231222193607.15474-1-graf@amazon.com/) "For quick reference: KHO is a new mechanism this patch set introduces which allows Linux to pass arbitrary memory and metadata between kernels on kexec. I'm reusing FDTs to implement the hand over protocol, as Linux-to-Linux boot communication holds very similar properties to firmware-to-Linux boot communication. So this binding is not about hardware; it's about preserving Linux subsystem state across kexec. For more details, please refer to the KHO documentation which is part of patch 7 of this patch set: https://lore.kernel.org/lkml/20231222195144.24532-2-graf@amazon.com/" and "This is our own data structure for KHO that just happens to again contain a DT structure. The reason is simple: I want a unified, versioned, introspectable data format that is cross platform so you don't need to touch every architecture specific boot passing logic every time you want to add a tiny piece of data." > > 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@amazon.com> > > Signed-off-by: Alexander Graf <graf@amazon.com> > > Signed-off-by: Mike Rapoport (Microsoft) <rppt@kernel.org> > > --- > > .../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@kernel.org> > > + > > +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. > > + > > +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. Because these regions are not "... designed for the special usage by various device drivers" and should not be exclude by the operating system from normal usage. > Best regards, > Krzysztof
On 09/02/2025 16:10, Mike Rapoport wrote: > On Sun, Feb 09, 2025 at 11:29:41AM +0100, Krzysztof Kozlowski wrote: >> On 06/02/2025 14:27, Mike Rapoport wrote: >>> From: "Mike Rapoport (Microsoft)" <rppt@kernel.org> >>> >>> 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 > > These are not devicetree binding for communicating data from firmware to > the kernel. These bindings are specific to KHO which is perfectly > reflected by the subject. No, it is not. None of the bindings use above subject prefix. > > Just a brief reminder from v2 discussion: > (https://lore.kernel.org/linux-mm/20231222193607.15474-1-graf@amazon.com/) > > "For quick reference: KHO is a new mechanism this patch set introduces > which allows Linux to pass arbitrary memory and metadata between kernels > on kexec. I'm reusing FDTs to implement the hand over protocol, as > Linux-to-Linux boot communication holds very similar properties to > firmware-to-Linux boot communication. So this binding is not about > hardware; it's about preserving Linux subsystem state across kexec. does not matter. You added file to ABI documentation so you must follow that ABI documentation rules. One rule is proper subject prefix. > > For more details, please refer to the KHO documentation which is part of > patch 7 of this patch set: > https://lore.kernel.org/lkml/20231222195144.24532-2-graf@amazon.com/" I fail to see how this is related to the incorrect subject prefix as I pointed. > > and > > "This is our own data structure for KHO that just happens to again > contain a DT structure. The reason is simple: I want a unified, > versioned, introspectable data format that is cross platform so you > don't need to touch every architecture specific boot passing logic every > time you want to add a tiny piece of data." > >>> 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@amazon.com> >>> Signed-off-by: Alexander Graf <graf@amazon.com> >>> Signed-off-by: Mike Rapoport (Microsoft) <rppt@kernel.org> >>> --- >>> .../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@kernel.org> >>> + >>> +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. >>> + >>> +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. > > Because these regions are not "... designed for the special usage by > various device drivers" So you use now very similar name, but different with few letters just to note that you do not fit into existing formats. If this does not fit existing usage, then use different name. > and should not be exclude by the operating system > from normal usage. Then it does not look like a reserved memory > >> Best regards, >> Krzysztof > Best regards, Krzysztof
On Sun, Feb 09, 2025 at 04:23:09PM +0100, Krzysztof Kozlowski wrote: > On 09/02/2025 16:10, Mike Rapoport wrote: > > On Sun, Feb 09, 2025 at 11:29:41AM +0100, Krzysztof Kozlowski wrote: > >> On 06/02/2025 14:27, Mike Rapoport wrote: > >>> From: "Mike Rapoport (Microsoft)" <rppt@kernel.org> > >>> > >>> 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 > > > > These are not devicetree binding for communicating data from firmware to > > the kernel. These bindings are specific to KHO which is perfectly > > reflected by the subject. > > No, it is not. None of the bindings use above subject prefix. > > > > > Just a brief reminder from v2 discussion: > > (https://lore.kernel.org/linux-mm/20231222193607.15474-1-graf@amazon.com/) > > > > "For quick reference: KHO is a new mechanism this patch set introduces > > which allows Linux to pass arbitrary memory and metadata between kernels > > on kexec. I'm reusing FDTs to implement the hand over protocol, as > > Linux-to-Linux boot communication holds very similar properties to > > firmware-to-Linux boot communication. So this binding is not about > > hardware; it's about preserving Linux subsystem state across kexec. > > does not matter. You added file to ABI documentation so you must follow > that ABI documentation rules. One rule is proper subject prefix. No, it does not. It's a different ABI. FDT is a _data structure_ that provides cross platform unified, versioned, introspectable data format. Documentation/devicetree/bindings standardizes it's use for describing hardware, but KHO uses FDT _data structure_ to describe state of the kernel components that will be reused by the kexec'ed kernel. KHO is a different namespace from Open Firmware Device Tree, with different requirements and different stakeholders. Putting descriptions of KHO data formats in Documentation/kho rather than in Documentation/devicetree/bindings was not done to evade review of Open Firmware Device Tree maintainers, but rather to emphasize that KHO FDT _is not_ Open Firmware Device Tree. > Best regards, > Krzysztof
On 09/02/2025 21:41, Mike Rapoport wrote: > On Sun, Feb 09, 2025 at 04:23:09PM +0100, Krzysztof Kozlowski wrote: >> On 09/02/2025 16:10, Mike Rapoport wrote: >>> On Sun, Feb 09, 2025 at 11:29:41AM +0100, Krzysztof Kozlowski wrote: >>>> On 06/02/2025 14:27, Mike Rapoport wrote: >>>>> From: "Mike Rapoport (Microsoft)" <rppt@kernel.org> >>>>> >>>>> 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 >>> >>> These are not devicetree binding for communicating data from firmware to >>> the kernel. These bindings are specific to KHO which is perfectly >>> reflected by the subject. >> >> No, it is not. None of the bindings use above subject prefix. >> >>> >>> Just a brief reminder from v2 discussion: >>> (https://lore.kernel.org/linux-mm/20231222193607.15474-1-graf@amazon.com/) >>> >>> "For quick reference: KHO is a new mechanism this patch set introduces >>> which allows Linux to pass arbitrary memory and metadata between kernels >>> on kexec. I'm reusing FDTs to implement the hand over protocol, as >>> Linux-to-Linux boot communication holds very similar properties to >>> firmware-to-Linux boot communication. So this binding is not about >>> hardware; it's about preserving Linux subsystem state across kexec. >> >> does not matter. You added file to ABI documentation so you must follow >> that ABI documentation rules. One rule is proper subject prefix. > > No, it does not. It's a different ABI. > > FDT is a _data structure_ that provides cross platform unified, versioned, > introspectable data format. > > Documentation/devicetree/bindings standardizes it's use for describing > hardware, but KHO uses FDT _data structure_ to describe state of the kernel > components that will be reused by the kexec'ed kernel. > > KHO is a different namespace from Open Firmware Device Tree, with different > requirements and different stakeholders. Putting descriptions of KHO data > formats in Documentation/kho rather than in > Documentation/devicetree/bindings was not done to evade review of Open > Firmware Device Tree maintainers, but rather to emphasize that KHO FDT _is > not_ Open Firmware Device Tree. Ah, neat, that would almost solve the problem but you wrote: +$id: http://devicetree.org/schemas/memblock/reserve_mem.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# so no, this does not work like that. You use devicetree here namespace and ignore its rules. You cannot pretend this is not devicetree if you put it into devicetree schemas. Best regards, Krzysztof
On 09/02/2025 21:49, Krzysztof Kozlowski wrote: >>>> >>>> These are not devicetree binding for communicating data from firmware to >>>> the kernel. These bindings are specific to KHO which is perfectly >>>> reflected by the subject. >>> >>> No, it is not. None of the bindings use above subject prefix. >>> >>>> >>>> Just a brief reminder from v2 discussion: >>>> (https://lore.kernel.org/linux-mm/20231222193607.15474-1-graf@amazon.com/) >>>> >>>> "For quick reference: KHO is a new mechanism this patch set introduces >>>> which allows Linux to pass arbitrary memory and metadata between kernels >>>> on kexec. I'm reusing FDTs to implement the hand over protocol, as >>>> Linux-to-Linux boot communication holds very similar properties to >>>> firmware-to-Linux boot communication. So this binding is not about >>>> hardware; it's about preserving Linux subsystem state across kexec. >>> >>> does not matter. You added file to ABI documentation so you must follow >>> that ABI documentation rules. One rule is proper subject prefix. >> >> No, it does not. It's a different ABI. >> >> FDT is a _data structure_ that provides cross platform unified, versioned, >> introspectable data format. >> >> Documentation/devicetree/bindings standardizes it's use for describing >> hardware, but KHO uses FDT _data structure_ to describe state of the kernel >> components that will be reused by the kexec'ed kernel. >> >> KHO is a different namespace from Open Firmware Device Tree, with different >> requirements and different stakeholders. Putting descriptions of KHO data >> formats in Documentation/kho rather than in >> Documentation/devicetree/bindings was not done to evade review of Open >> Firmware Device Tree maintainers, but rather to emphasize that KHO FDT _is >> not_ Open Firmware Device Tree. > > > Ah, neat, that would almost solve the problem but you wrote: > > +$id: http://devicetree.org/schemas/memblock/reserve_mem.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > > so no, this does not work like that. You use devicetree here namespace > and ignore its rules. ... and that obviously is barely parseable, so maybe one more try: "You use here devicetree namespace but ignore its rules." > > You cannot pretend this is not devicetree if you put it into devicetree > schemas. Best regards, Krzysztof
On Sun, Feb 09, 2025 at 09:50:37PM +0100, Krzysztof Kozlowski wrote: > > Ah, neat, that would almost solve the problem but you wrote: > > > > +$id: http://devicetree.org/schemas/memblock/reserve_mem.yaml# > > +$schema: http://devicetree.org/meta-schemas/core.yaml# > > > > so no, this does not work like that. You use devicetree here namespace > > and ignore its rules. > > ... and that obviously is barely parseable, so maybe one more try: > "You use here devicetree namespace but ignore its rules." It makes sense to me, there should be zero cross-over of the two specs, KHO should be completely self defined and stand alone. There is some documentation missing, I think. This yaml describes one node type, but the entire overall structure of the fdt does not seem to have documentation? Jason
On 10/02/2025 20:15, Jason Gunthorpe wrote: > On Sun, Feb 09, 2025 at 09:50:37PM +0100, Krzysztof Kozlowski wrote: >>> Ah, neat, that would almost solve the problem but you wrote: >>> >>> +$id: http://devicetree.org/schemas/memblock/reserve_mem.yaml# >>> +$schema: http://devicetree.org/meta-schemas/core.yaml# >>> >>> so no, this does not work like that. You use devicetree here namespace >>> and ignore its rules. >> >> ... and that obviously is barely parseable, so maybe one more try: >> "You use here devicetree namespace but ignore its rules." > > It makes sense to me, there should be zero cross-over of the two > specs, KHO should be completely self defined and stand alone. > > There is some documentation missing, I think. This yaml describes one > node type, but the entire overall structure of the fdt does not seem > to have documentation? A lot of ABI is missing there and undocumented like: node name (which for every standard DT would be a NAK), few properties. This binding describes only subset while skipping all the rest and effectively introducing implied/undocumented ABI. Best regards, Krzysztof
On Mon, Feb 10, 2025 at 08:27:34PM +0100, Krzysztof Kozlowski wrote: > On 10/02/2025 20:15, Jason Gunthorpe wrote: > > On Sun, Feb 09, 2025 at 09:50:37PM +0100, Krzysztof Kozlowski wrote: > >>> Ah, neat, that would almost solve the problem but you wrote: > >>> > >>> +$id: http://devicetree.org/schemas/memblock/reserve_mem.yaml# > >>> +$schema: http://devicetree.org/meta-schemas/core.yaml# > >>> > >>> so no, this does not work like that. You use devicetree here namespace > >>> and ignore its rules. > >> > >> ... and that obviously is barely parseable, so maybe one more try: > >> "You use here devicetree namespace but ignore its rules." > > > > It makes sense to me, there should be zero cross-over of the two > > specs, KHO should be completely self defined and stand alone. > > > > There is some documentation missing, I think. This yaml describes one > > node type, but the entire overall structure of the fdt does not seem > > to have documentation? > > A lot of ABI is missing there and undocumented like: node name (which > for every standard DT would be a NAK), few properties. This binding > describes only subset while skipping all the rest and effectively > introducing implied/undocumented ABI. I agree, I think it can be easily adressed - the docs should have a sample of the overal DT from the root node and yaml for each of the blocks, laying out the purpose very much like the open dt spec.. Jason
On Mon, Feb 10, 2025 at 04:20:40PM -0400, Jason Gunthorpe wrote: > On Mon, Feb 10, 2025 at 08:27:34PM +0100, Krzysztof Kozlowski wrote: > > On 10/02/2025 20:15, Jason Gunthorpe wrote: > > > On Sun, Feb 09, 2025 at 09:50:37PM +0100, Krzysztof Kozlowski wrote: > > >>> Ah, neat, that would almost solve the problem but you wrote: > > >>> > > >>> +$id: http://devicetree.org/schemas/memblock/reserve_mem.yaml# > > >>> +$schema: http://devicetree.org/meta-schemas/core.yaml# > > >>> > > >>> so no, this does not work like that. You use devicetree here namespace > > >>> and ignore its rules. > > >> > > >> ... and that obviously is barely parseable, so maybe one more try: > > >> "You use here devicetree namespace but ignore its rules." > > > > > > It makes sense to me, there should be zero cross-over of the two > > > specs, KHO should be completely self defined and stand alone. > > > > > > There is some documentation missing, I think. This yaml describes one > > > node type, but the entire overall structure of the fdt does not seem > > > to have documentation? > > > > A lot of ABI is missing there and undocumented like: node name (which > > for every standard DT would be a NAK), few properties. This binding > > describes only subset while skipping all the rest and effectively > > introducing implied/undocumented ABI. > > I agree, I think it can be easily adressed - the docs should have a > sample of the overal DT from the root node and yaml for each of the > blocks, laying out the purpose very much like the open dt spec.. I'll update the docs with more details about overall structure and will make it clear that it's a different namespace. > Jason
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@kernel.org> + +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 + +patternProperties: + "$[0-9a-f_]+^": + $ref: reserve_mem_map.yaml# + description: reserved memory regions + +required: + - compatible + +additionalProperties: false + +examples: + - | + reserve_mem { + 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@kernel.org> + +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 + + mem: + $ref: /schemas/types.yaml#/definitions/uint32-array + description: | + Array of { u64 phys_addr, u64 len } elements that describe a list of + memory ranges. + +required: + - compatible + - mem + +additionalProperties: false + +examples: + - | + reserve_mem { + compatible = "reserve_mem-v1"; + r1 { + compatible = "reserve_mem_map-v1"; + mem = <0xc07c 0x2000000 0x01 0x00>; + }; + };