On 5/22/2026 4:18 AM, Laurentiu Mihalcea wrote:
> From: Laurentiu Mihalcea <[email protected]>
>
> Document the optional "memory-region-names" property.
>
> Signed-off-by: Laurentiu Mihalcea <[email protected]>
> ---
> .../devicetree/bindings/remoteproc/fsl,imx-rproc.yaml | 8 ++++++++
> 1 file changed, 8 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml
> b/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml
> index c18f71b64889..6679b10f9da5 100644
> --- a/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml
> +++ b/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml
> @@ -62,6 +62,14 @@ properties:
> minItems: 1
> maxItems: 32
>
> + memory-region-names:
> + minItems: 1
> + maxItems: 32
> + items:
> + oneOf:
> + - const: rsc-table
> + - pattern: '^vdev[0-9](buffer|vring[0-9])$'
> +
> power-domains:
> minItems: 2
> maxItems: 8
So, I think the AI bot is right on this one. I've missed the fact that the
programming
model allows you to specify additional carveouts (currently not allowed by the
constraints
here), based on the firmware used. An in-tree example of this would be
imx95-verdin, which
takes another carveout called "m7_reserved".
Based on this, I wonder if it would make more sense to leave this property
unconstrained
w.r.t the names we allow.
