Message ID | 20210721140424.725744-1-maxime@cerno.tech |
---|---|
Headers | show |
Series | ARM: dts: Last round of DT schema fixes | expand |
On Wed, Jul 21, 2021 at 8:04 AM Maxime Ripard <maxime@cerno.tech> wrote: > > The Reserved Memory mechanism is supported by Linux thanks to its device > tree binding. > > Now that we have the DT validation in place, let's convert the device > tree bindings for that driver over to a YAML schema. Thanks for this! > > Cc: Mailing List <devicetree-spec@vger.kernel.org> > Signed-off-by: Maxime Ripard <maxime@cerno.tech> > --- > .../reserved-memory/reserved-memory.txt | 141 --------------- > .../reserved-memory/reserved-memory.yaml | 167 ++++++++++++++++++ > 2 files changed, 167 insertions(+), 141 deletions(-) > delete mode 100644 Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt > create mode 100644 Documentation/devicetree/bindings/reserved-memory/reserved-memory.yaml > diff --git a/Documentation/devicetree/bindings/reserved-memory/reserved-memory.yaml b/Documentation/devicetree/bindings/reserved-memory/reserved-memory.yaml > new file mode 100644 > index 000000000000..b61527f11953 > --- /dev/null > +++ b/Documentation/devicetree/bindings/reserved-memory/reserved-memory.yaml > @@ -0,0 +1,167 @@ > +# SPDX-License-Identifier: GPL-2.0 I think this is okay to dual license. Grant (Linaro) is the original author and there's only a few lines from other authors. > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/reserved-memory/reserved-memory.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: /reserved-memory Node > + > +maintainers: > + - Devicetree Specification Mailing List <devicetree-spec@vger.kernel.org> > + > +description: > > + Reserved memory is specified as a node under the /reserved-memory node. The > + operating system shall exclude reserved memory from normal usage one can > + create child nodes describing particular reserved (excluded from normal use) > + memory regions. Such memory regions are usually designed for the special > + usage by various device drivers. > + > +properties: > + $nodename: > + const: reserved-memory > + > + "#address-cells": true > + "#size-cells": true > + ranges: true > + > +patternProperties: > + "^(?!(ranges))[a-z,-]*(@[0-9]+)?$": Note that you could drop this and put under 'additionalProperties'. You would lose some node name checking, but there's really little standard on these nodes. > + type: object > + > + description: > > + Each child of the reserved-memory node specifies one or more regions of > + reserved memory. Each child node may either use a 'reg' property to > + specify a specific range of reserved memory, or a 'size' property with > + optional constraints to request a dynamically allocated block of memory. > + > + Following the generic-names recommended practice, node names should > + reflect the purpose of the node (ie. "framebuffer" or "dma-pool"). Unit > + address (@<address>) should be appended to the name if the node is a > + static allocation. > + > + properties: > + reg: true > + > + size: > + $ref: /schemas/types.yaml#/definitions/uint32-array > + description: > > + Length based on parent's \#size-cells. Size in bytes of memory to > + reserve. > + > + alignment: > + $ref: /schemas/types.yaml#/definitions/uint32-array > + description: > > + Length based on parent's \#size-cells. Address boundary for > + alignment of allocation. > + > + alloc-ranges: > + $ref: /schemas/types.yaml#/definitions/uint32-array > + description: > > + Address and Length pairs. Specifies regions of memory that are > + acceptable to allocate from. > + > + compatible: > + oneOf: > + - const: shared-dma-pool > + description: > > + This indicates a region of memory meant to be used as a shared > + pool of DMA buffers for a set of devices. It can be used by an > + operating system to instantiate the necessary pool management > + subsystem if necessary. > + > + # Vendor-specific compatibles in the form <vendor>,[<device>-]<usage> > + - const: mediatek,trustzone-bootinfo I think these should be separate schema files. At least, we're going to need to support separate files because I don't think we want ones adding custom properties here. This would fail unless we add every compatible here. We could also be a bit more exact as to which properties below apply (e.g. linux,.*-default is only valid for shared-dma-pool). > + > + no-map: > + type: boolean > + description: > > + Indicates the operating system must not create a virtual mapping of > + the region as part of its standard mapping of system memory, nor > + permit speculative access to it under any circumstances other than > + under the control of the device driver using the region. > + > + reusable: > + type: boolean > + description: > > + The operating system can use the memory in this region with the > + limitation that the device driver(s) owning the region need to be > + able to reclaim it back. Typically that means that the operating > + system can use that region to store volatile or cached data that > + can be otherwise regenerated or migrated elsewhere. > + > + linux,cma-default: > + type: boolean > + description: > > + If this property is present, then Linux will use the region for the > + default pool of the contiguous memory allocator. > + > + linux,dma-default: > + type: boolean > + description: > > + If this property is present, then Linux will use the region for the > + default pool of the consistent DMA allocator. > + > + allOf: > + - if: > + required: > + - no-map > + > + then: > + not: > + required: > + - reusable > + > + - if: > + required: > + - reusable > + > + then: > + not: > + required: > + - no-map > + > + oneOf: > + - required: > + - reg > + > + - required: > + - size > + > + additionalProperties: true > + > +additionalProperties: true This should be false, right? > + > +examples: > + - | > + / { > + #address-cells = <1>; > + #size-cells = <1>; > + model = "MediaTek MT2701 evaluation board"; > + compatible = "mediatek,mt2701-evb", "mediatek,mt2701"; > + > + reserved-memory { > + #address-cells = <1>; > + #size-cells = <1>; > + ranges; > + > + /* global autoconfigured region for contiguous allocations */ > + linux,cma { > + compatible = "shared-dma-pool"; > + reusable; > + size = <0x4000000>; > + alignment = <0x2000>; > + linux,cma-default; > + }; > + > + display_reserved: framebuffer@78000000 { > + reg = <0x78000000 0x800000>; > + }; > + > + trustzone-bootinfo@80002000 { > + compatible = "mediatek,trustzone-bootinfo"; > + reg = <0x80002000 0x1000>; > + }; > + }; > + }; > + > +... > -- > 2.31.1 >
On Wed, 21 Jul 2021 16:03:35 +0200, Maxime Ripard wrote: > The Reserved Memory mechanism is supported by Linux thanks to its device > tree binding. > > Now that we have the DT validation in place, let's convert the device > tree bindings for that driver over to a YAML schema. > > Cc: Mailing List <devicetree-spec@vger.kernel.org> > Signed-off-by: Maxime Ripard <maxime@cerno.tech> > --- > .../reserved-memory/reserved-memory.txt | 141 --------------- > .../reserved-memory/reserved-memory.yaml | 167 ++++++++++++++++++ > 2 files changed, 167 insertions(+), 141 deletions(-) > delete mode 100644 Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt > create mode 100644 Documentation/devicetree/bindings/reserved-memory/reserved-memory.yaml > My bot found errors running 'make DT_CHECKER_FLAGS=-m dt_binding_check' on your patch (DT_CHECKER_FLAGS is new in v5.13): yamllint warnings/errors: dtschema/dtc warnings/errors: /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/nvmem/rmem.example.dt.yaml: reserved-memory: nvram@10000000:compatible: 'oneOf' conditional failed, one must be fixed: ['raspberrypi,bootloader-config', 'nvmem-rmem'] is too long Additional items are not allowed ('nvmem-rmem' was unexpected) 'shared-dma-pool' was expected 'mediatek,trustzone-bootinfo' was expected From schema: /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/reserved-memory/reserved-memory.yaml /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra210-emc.example.dt.yaml: reserved-memory: emc-table@83400000:compatible: 'oneOf' conditional failed, one must be fixed: 'shared-dma-pool' was expected 'mediatek,trustzone-bootinfo' was expected From schema: /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/reserved-memory/reserved-memory.yaml \ndoc reference errors (make refcheckdocs): Documentation/devicetree/bindings/display/arm,hdlcd.txt: Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt Documentation/devicetree/bindings/display/arm,komeda.txt: Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt Documentation/devicetree/bindings/display/arm,malidp.txt: Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt Documentation/devicetree/bindings/display/arm,pl11x.txt: Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt Documentation/devicetree/bindings/firmware/intel,stratix10-svc.txt: Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt Documentation/devicetree/bindings/gpu/aspeed-gfx.txt: Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt Documentation/devicetree/bindings/media/aspeed-video.txt: Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt Documentation/devicetree/bindings/media/mediatek-vpu.txt: Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt Documentation/devicetree/bindings/remoteproc/ti,davinci-rproc.txt: Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt Documentation/devicetree/bindings/remoteproc/ti,k3-dsp-rproc.yaml: Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt Documentation/devicetree/bindings/remoteproc/ti,k3-r5f-rproc.yaml: Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt Documentation/devicetree/bindings/remoteproc/ti,keystone-rproc.txt: Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt Documentation/devicetree/bindings/remoteproc/ti,omap-remoteproc.yaml: Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt arch/arm/mm/dma-mapping-nommu.c: Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt See https://patchwork.ozlabs.org/patch/1508249 This check can fail if there are any dependencies. The base for a patch series is generally the most recent rc1. If you already ran 'make dt_binding_check' and didn't see the above error(s), then make sure 'yamllint' is installed and dt-schema is up to date: pip3 install dtschema --upgrade Please check and re-submit.
On Wed, 21 Jul 2021 16:03:43 +0200, Maxime Ripard wrote: > The X-Powers AXP PMICs feature a GPIO Controller supported by Linux > thanks to its device tree binding. > > Now that we have the DT validation in place, let's convert the device > tree bindings for that driver over to a YAML schema. > > Cc: Bartosz Golaszewski <bgolaszewski@baylibre.com> > Cc: Chen-Yu Tsai <wens@csie.org> > Cc: Linus Walleij <linus.walleij@linaro.org> > Cc: linux-gpio@vger.kernel.org > Signed-off-by: Maxime Ripard <maxime@cerno.tech> > --- > .../devicetree/bindings/gpio/gpio-axp209.txt | 75 ----------------- > .../bindings/gpio/x-powers,axp209-gpio.yaml | 84 +++++++++++++++++++ > 2 files changed, 84 insertions(+), 75 deletions(-) > delete mode 100644 Documentation/devicetree/bindings/gpio/gpio-axp209.txt > create mode 100644 Documentation/devicetree/bindings/gpio/x-powers,axp209-gpio.yaml > My bot found errors running 'make DT_CHECKER_FLAGS=-m dt_binding_check' on your patch (DT_CHECKER_FLAGS is new in v5.13): yamllint warnings/errors: dtschema/dtc warnings/errors: Documentation/devicetree/bindings/gpio/x-powers,axp209-gpio.example.dt.yaml:0:0: /example-0/i2c/pmic@34: failed to match any schema with compatible: ['x-powers,axp209'] \ndoc reference errors (make refcheckdocs): See https://patchwork.ozlabs.org/patch/1508257 This check can fail if there are any dependencies. The base for a patch series is generally the most recent rc1. If you already ran 'make dt_binding_check' and didn't see the above error(s), then make sure 'yamllint' is installed and dt-schema is up to date: pip3 install dtschema --upgrade Please check and re-submit.
On 7/21/21 9:03 AM, Maxime Ripard wrote: > Bluetooth SCO Link are supported by Linux with a matching device tree > binding. > > Now that we have the DT validation in place, let's convert the device > tree bindings for that driver over to a YAML schema. > > The value expected for #sound-dai-cells wasn't documented though, and > the users were inconsistent. The example didn't list it, and across the > 4 users we have in tree: > - 1 had a cells value of 1, but using only 0 as argument > - 1 had a cells value of 0, > - 2 didn't have this property at all, behaving as if it was 0, > > It seems like the consensus seems to be that it should be 0, so let's > enforce it. The driver has two DAIs: "bt-sco-pcm" and "bt-sco-pcm-wb". If #sound-dai-cells is 0, only the first DAI can be referenced from a device tree. So to declare support for wideband PCM, or explicitly declare a lack of support for it, #sound-dai-cells must be 1. Regards, Samuel > Cc: alsa-devel@alsa-project.org > Cc: devicetree@vger.kernel.org > Cc: Liam Girdwood <lgirdwood@gmail.com> > Cc: Mark Brown <broonie@kernel.org> > Cc: Samuel Holland <samuel@sholland.org> > Signed-off-by: Maxime Ripard <maxime@cerno.tech> > --- > .../devicetree/bindings/sound/bt-sco.txt | 13 ------- > .../bindings/sound/linux,bt-sco.yaml | 34 +++++++++++++++++++ > 2 files changed, 34 insertions(+), 13 deletions(-) > delete mode 100644 Documentation/devicetree/bindings/sound/bt-sco.txt > create mode 100644 Documentation/devicetree/bindings/sound/linux,bt-sco.yaml > > diff --git a/Documentation/devicetree/bindings/sound/bt-sco.txt b/Documentation/devicetree/bindings/sound/bt-sco.txt > deleted file mode 100644 > index 641edf75e184..000000000000 > --- a/Documentation/devicetree/bindings/sound/bt-sco.txt > +++ /dev/null > @@ -1,13 +0,0 @@ > -Bluetooth-SCO audio CODEC > - > -This device support generic Bluetooth SCO link. > - > -Required properties: > - > - - compatible : "delta,dfbmcs320" or "linux,bt-sco" > - > -Example: > - > -codec: bt_sco { > - compatible = "delta,dfbmcs320"; > -}; > diff --git a/Documentation/devicetree/bindings/sound/linux,bt-sco.yaml b/Documentation/devicetree/bindings/sound/linux,bt-sco.yaml > new file mode 100644 > index 000000000000..334b508205cd > --- /dev/null > +++ b/Documentation/devicetree/bindings/sound/linux,bt-sco.yaml > @@ -0,0 +1,34 @@ > +# SPDX-License-Identifier: GPL-2.0 > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/sound/linux,bt-sco.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: Bluetooth SCO Audio Codec Device Tree Bindings > + > +maintainers: > + - Mark Brown <broonie@kernel.org> > + > +properties: > + '#sound-dai-cells': > + const: 0 > + > + compatible: > + enum: > + - delta,dfbmcs320 > + - linux,bt-sco > + > +required: > + - '#sound-dai-cells' > + - compatible > + > +additionalProperties: false > + > +examples: > + - | > + codec { > + #sound-dai-cells = <0>; > + compatible = "linux,bt-sco"; > + }; > + > +... >
Hi Samuel, On Thu, Jul 22, 2021 at 12:35:33AM -0500, Samuel Holland wrote: > On 7/21/21 9:03 AM, Maxime Ripard wrote: > > Bluetooth SCO Link are supported by Linux with a matching device tree > > binding. > > > > Now that we have the DT validation in place, let's convert the device > > tree bindings for that driver over to a YAML schema. > > > > The value expected for #sound-dai-cells wasn't documented though, and > > the users were inconsistent. The example didn't list it, and across the > > 4 users we have in tree: > > - 1 had a cells value of 1, but using only 0 as argument > > - 1 had a cells value of 0, > > - 2 didn't have this property at all, behaving as if it was 0, > > > > It seems like the consensus seems to be that it should be 0, so let's > > enforce it. > > The driver has two DAIs: "bt-sco-pcm" and "bt-sco-pcm-wb". If > #sound-dai-cells is 0, only the first DAI can be referenced from a > device tree. So to declare support for wideband PCM, or explicitly > declare a lack of support for it, #sound-dai-cells must be 1. Yeah, I knew there was something else to it :) I'll fix it for the next iteration. Thanks! Maxime
On Wed, Jul 21, 2021 at 04:16:13PM +0200, Sam Ravnborg wrote: > On Wed, Jul 21, 2021 at 04:03:41PM +0200, Maxime Ripard wrote: > > The corpro,gm7123 was in use in a DT but was never properly documented, > > let's add it. > > > > Cc: dri-devel@lists.freedesktop.org > > Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> > > Signed-off-by: Maxime Ripard <maxime@cerno.tech> > Acked-by: Sam Ravnborg <sam@ravnborg.org> Applied to drm-misc-next, thanks! Maxime
On Wed, Jul 21, 2021 at 10:48:26AM -0600, Rob Herring wrote: > On Wed, Jul 21, 2021 at 04:03:30PM +0200, Maxime Ripard wrote: > > Hi, > > > > Here's another round of schema warnings fixes for the Allwinner platform. > > > > There's a fair share of new schemas in there since the schema tools now warn > > when a compatible is not documented in a schema. > > > > We don't have any warning anymore if we use the OPP binding Rob submitted, and > > since that means we have all our devices properly validated I don't expect more > > fixes now, aside from the usual bunch of regressions. > > Great! You deserve a prize. > > I want to start enabling the schema checks by default. (Though then I'd > have to worry about new warnings.) This should be pretty easy to do > where we have subdirs per family, but for arm32 we'd need to move dts > files to subdirs if we don't want a flag per dts file. That's definitely something that I'd be interested in. It's very easy for a warning / error to slip through during review, so having some builders somewhere reporting new issues would be awesome. On arm32 though, we have per-family defconfig so maybe we can opt-in by defconfig? It should work in most case Maxime
Hi Rob, On Wed, Jul 21, 2021 at 08:30:43AM -0600, Rob Herring wrote: > > +%YAML 1.2 > > +--- > > +$id: http://devicetree.org/schemas/reserved-memory/reserved-memory.yaml# > > +$schema: http://devicetree.org/meta-schemas/core.yaml# > > + > > +title: /reserved-memory Node > > + > > +maintainers: > > + - Devicetree Specification Mailing List <devicetree-spec@vger.kernel.org> > > + > > +description: > > > + Reserved memory is specified as a node under the /reserved-memory node. The > > + operating system shall exclude reserved memory from normal usage one can > > + create child nodes describing particular reserved (excluded from normal use) > > + memory regions. Such memory regions are usually designed for the special > > + usage by various device drivers. > > + > > +properties: > > + $nodename: > > + const: reserved-memory > > + > > + "#address-cells": true > > + "#size-cells": true > > + ranges: true > > + > > +patternProperties: > > + "^(?!(ranges))[a-z,-]*(@[0-9]+)?$": > > Note that you could drop this and put under 'additionalProperties'. > You would lose some node name checking, but there's really little > standard on these nodes. I didn't realise it could be used that way too, I'll change it. > > + type: object > > + > > + description: > > > + Each child of the reserved-memory node specifies one or more regions of > > + reserved memory. Each child node may either use a 'reg' property to > > + specify a specific range of reserved memory, or a 'size' property with > > + optional constraints to request a dynamically allocated block of memory. > > + > > + Following the generic-names recommended practice, node names should > > + reflect the purpose of the node (ie. "framebuffer" or "dma-pool"). Unit > > + address (@<address>) should be appended to the name if the node is a > > + static allocation. > > + > > + properties: > > + reg: true > > + > > + size: > > + $ref: /schemas/types.yaml#/definitions/uint32-array > > + description: > > > + Length based on parent's \#size-cells. Size in bytes of memory to > > + reserve. > > + > > + alignment: > > + $ref: /schemas/types.yaml#/definitions/uint32-array > > + description: > > > + Length based on parent's \#size-cells. Address boundary for > > + alignment of allocation. > > + > > + alloc-ranges: > > + $ref: /schemas/types.yaml#/definitions/uint32-array > > + description: > > > + Address and Length pairs. Specifies regions of memory that are > > + acceptable to allocate from. > > + > > + compatible: > > + oneOf: > > + - const: shared-dma-pool > > + description: > > > + This indicates a region of memory meant to be used as a shared > > + pool of DMA buffers for a set of devices. It can be used by an > > + operating system to instantiate the necessary pool management > > + subsystem if necessary. > > + > > + # Vendor-specific compatibles in the form <vendor>,[<device>-]<usage> > > + - const: mediatek,trustzone-bootinfo > > I think these should be separate schema files. At least, we're going > to need to support separate files because I don't think we want ones > adding custom properties here. This would fail unless we add every > compatible here. We could also be a bit more exact as to which > properties below apply (e.g. linux,.*-default is only valid for > shared-dma-pool). I'm not entirely sure how we can just ignore the vendor compatibles without raising a warning. Do you have any suggestion? Thanks! Maxime
On Wed, Aug 18, 2021 at 5:00 AM Maxime Ripard <maxime@cerno.tech> wrote: > > Hi Rob, > > On Wed, Jul 21, 2021 at 08:30:43AM -0600, Rob Herring wrote: > > > +%YAML 1.2 > > > +--- > > > +$id: http://devicetree.org/schemas/reserved-memory/reserved-memory.yaml# > > > +$schema: http://devicetree.org/meta-schemas/core.yaml# > > > + > > > +title: /reserved-memory Node > > > + > > > +maintainers: > > > + - Devicetree Specification Mailing List <devicetree-spec@vger.kernel.org> > > > + > > > +description: > > > > + Reserved memory is specified as a node under the /reserved-memory node. The > > > + operating system shall exclude reserved memory from normal usage one can > > > + create child nodes describing particular reserved (excluded from normal use) > > > + memory regions. Such memory regions are usually designed for the special > > > + usage by various device drivers. > > > + > > > +properties: > > > + $nodename: > > > + const: reserved-memory > > > + > > > + "#address-cells": true > > > + "#size-cells": true > > > + ranges: true > > > + > > > +patternProperties: > > > + "^(?!(ranges))[a-z,-]*(@[0-9]+)?$": > > > > Note that you could drop this and put under 'additionalProperties'. > > You would lose some node name checking, but there's really little > > standard on these nodes. > > I didn't realise it could be used that way too, I'll change it. > > > > + type: object > > > + > > > + description: > > > > + Each child of the reserved-memory node specifies one or more regions of > > > + reserved memory. Each child node may either use a 'reg' property to > > > + specify a specific range of reserved memory, or a 'size' property with > > > + optional constraints to request a dynamically allocated block of memory. > > > + > > > + Following the generic-names recommended practice, node names should > > > + reflect the purpose of the node (ie. "framebuffer" or "dma-pool"). Unit > > > + address (@<address>) should be appended to the name if the node is a > > > + static allocation. > > > + > > > + properties: > > > + reg: true > > > + > > > + size: > > > + $ref: /schemas/types.yaml#/definitions/uint32-array > > > + description: > > > > + Length based on parent's \#size-cells. Size in bytes of memory to > > > + reserve. > > > + > > > + alignment: > > > + $ref: /schemas/types.yaml#/definitions/uint32-array > > > + description: > > > > + Length based on parent's \#size-cells. Address boundary for > > > + alignment of allocation. > > > + > > > + alloc-ranges: > > > + $ref: /schemas/types.yaml#/definitions/uint32-array > > > + description: > > > > + Address and Length pairs. Specifies regions of memory that are > > > + acceptable to allocate from. > > > + > > > + compatible: > > > + oneOf: > > > + - const: shared-dma-pool > > > + description: > > > > + This indicates a region of memory meant to be used as a shared > > > + pool of DMA buffers for a set of devices. It can be used by an > > > + operating system to instantiate the necessary pool management > > > + subsystem if necessary. > > > + > > > + # Vendor-specific compatibles in the form <vendor>,[<device>-]<usage> > > > + - const: mediatek,trustzone-bootinfo > > > > I think these should be separate schema files. At least, we're going > > to need to support separate files because I don't think we want ones > > adding custom properties here. This would fail unless we add every > > compatible here. We could also be a bit more exact as to which > > properties below apply (e.g. linux,.*-default is only valid for > > shared-dma-pool). > > I'm not entirely sure how we can just ignore the vendor compatibles > without raising a warning. Do you have any suggestion? You need 1 schema file with all the common (child) properties and then 1 schema file for each compatible (maybe some can be grouped) that references the common schema. You'd lose checking that the child nodes are actually children of /reserved-memory, but I'm not too worried about that. Rob