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