[PATCH] dt-bindings: mtd: arasan: Add ZynqMP props

[PATCH] dt-bindings: mtd: arasan: Add ZynqMP props

[Rob Herring (Arm)]

ZynqMP NAND controller nodes contain "num-cs" and "power-domains"
properties. Add num-cs with a range of one to two chip selects and allow
one power-domain.

Assisted-by: LLM
Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
---
 .../devicetree/bindings/mtd/arasan,nand-controller.yaml   | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/Documentation/devicetree/bindings/mtd/arasan,nand-controller.yaml b/Documentation/devicetree/bindings/mtd/arasan,nand-controller.yaml
index b90d3b48c2f2..4262996dd51e 100644
--- a/Documentation/devicetree/bindings/mtd/arasan,nand-controller.yaml
+++ b/Documentation/devicetree/bindings/mtd/arasan,nand-controller.yaml
@@ -35,6 +35,14 @@ properties:
   interrupts:
     maxItems: 1
 
+  num-cs:
+    $ref: /schemas/types.yaml#/definitions/uint32
+    minimum: 1
+    maximum: 2
+
+  power-domains:
+    maxItems: 1
+
 required:
   - compatible
   - reg
-- 
2.53.0

Re: [PATCH] dt-bindings: mtd: arasan: Add ZynqMP props

[Miquel Raynal]

Hi Rob,

> +  num-cs:
> +    $ref: /schemas/types.yaml#/definitions/uint32
> +    minimum: 1
> +    maximum: 2

I am not sure I get what is the purpose of this property. It looks like
a downstream property resurfacing. We expect one DT subnode per chip, so
I don't see the need for num-cs, we just need to count the children
nodes. For me, the correct fix is to drop num-cs from the upstream DT.
The only real use for it would be if the hardware could be synthesized
differently, with a single CS instead of 2, but I don't think it's the
case here.

> +
> +  power-domains:
> +    maxItems: 1

This one, even though we don't actively use it in Linux, it may serve a
real purpose.

Thanks,
Miquèl

Re: [PATCH] dt-bindings: mtd: arasan: Add ZynqMP props

[Rob Herring]

On Fri, Sep 25, 2026 at 11:16:21AM +0200, Miquel Raynal wrote:
> Hi Rob,
> 
> > +  num-cs:
> > +    $ref: /schemas/types.yaml#/definitions/uint32
> > +    minimum: 1
> > +    maximum: 2
> 
> I am not sure I get what is the purpose of this property. It looks like
> a downstream property resurfacing. We expect one DT subnode per chip, so
> I don't see the need for num-cs, we just need to count the children
> nodes. For me, the correct fix is to drop num-cs from the upstream DT.
> The only real use for it would be if the hardware could be synthesized
> differently, with a single CS instead of 2, but I don't think it's the
> case here.

Indeed.

> > +
> > +  power-domains:
> > +    maxItems: 1
> 
> This one, even though we don't actively use it in Linux, it may serve a
> real purpose.

The driver core takes care of 'power-domains', so how is it not used?

Rob

Re: [PATCH] dt-bindings: mtd: arasan: Add ZynqMP props

[Miquel Raynal]

On 25/09/2026 at 07:20:03 -05, Rob Herring <robh@kernel.org> wrote:

> On Fri, Sep 25, 2026 at 11:16:21AM +0200, Miquel Raynal wrote:
>> Hi Rob,
>> 
>> > +  num-cs:
>> > +    $ref: /schemas/types.yaml#/definitions/uint32
>> > +    minimum: 1
>> > +    maximum: 2
>> 
>> I am not sure I get what is the purpose of this property. It looks like
>> a downstream property resurfacing. We expect one DT subnode per chip, so
>> I don't see the need for num-cs, we just need to count the children
>> nodes. For me, the correct fix is to drop num-cs from the upstream DT.
>> The only real use for it would be if the hardware could be synthesized
>> differently, with a single CS instead of 2, but I don't think it's the
>> case here.
>
> Indeed.
>
>> > +
>> > +  power-domains:
>> > +    maxItems: 1
>> 
>> This one, even though we don't actively use it in Linux, it may serve a
>> real purpose.
>
> The driver core takes care of 'power-domains', so how is it not used?

Yes, it is probably useful. I am pretty sure I did not use that property
when I tested the driver, but the controller was either already set up
by the Bootloader or in a domain enabled by another device. In both
cases, it is worth adding.

Re: [PATCH] dt-bindings: mtd: arasan: Add ZynqMP props

[Michal Simek]

On 9/25/26 14:52, Miquel Raynal wrote:
> On 25/09/2026 at 07:20:03 -05, Rob Herring <robh@kernel.org> wrote:
> 
>> On Fri, Sep 25, 2026 at 11:16:21AM +0200, Miquel Raynal wrote:
>>> Hi Rob,
>>>
>>>> +  num-cs:
>>>> +    $ref: /schemas/types.yaml#/definitions/uint32
>>>> +    minimum: 1
>>>> +    maximum: 2
>>>
>>> I am not sure I get what is the purpose of this property. It looks like
>>> a downstream property resurfacing. We expect one DT subnode per chip, so
>>> I don't see the need for num-cs, we just need to count the children
>>> nodes. For me, the correct fix is to drop num-cs from the upstream DT.
>>> The only real use for it would be if the hardware could be synthesized
>>> differently, with a single CS instead of 2, but I don't think it's the
>>> case here.
>>
>> Indeed.
>>
>>>> +
>>>> +  power-domains:
>>>> +    maxItems: 1
>>>
>>> This one, even though we don't actively use it in Linux, it may serve a
>>> real purpose.
>>
>> The driver core takes care of 'power-domains', so how is it not used?
> 
> Yes, it is probably useful. I am pretty sure I did not use that property
> when I tested the driver, but the controller was either already set up
> by the Bootloader or in a domain enabled by another device. In both
> cases, it is worth adding.

It shouldn't be a problem to list it. We have never used it but obviously there 
is power domain.

Thanks,
Michal