From: Miquel Raynal <miquel.raynal@bootlin.com>
To: Rob Herring <robh@kernel.org>
Cc: Michal Simek <michal.simek@amd.com>,
Richard Weinberger <richard@nod.at>,
Vignesh Raghavendra <vigneshr@ti.com>,
Krzysztof Kozlowski <krzk+dt@kernel.org>,
Conor Dooley <conor+dt@kernel.org>,
linux-mtd@lists.infradead.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] dt-bindings: mtd: arasan: Add ZynqMP props
Date: Fri, 25 Sep 2026 14:52:56 +0200 [thread overview]
Message-ID: <87wls9jxw7.fsf@bootlin.com> (raw)
In-Reply-To: <20260925122003.GD677989-robh@kernel.org> (Rob Herring's message of "Fri, 25 Sep 2026 07:20:03 -0500")
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.
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
WARNING: multiple messages have this Message-ID (diff)
From: Miquel Raynal <miquel.raynal@bootlin.com>
To: Rob Herring <robh@kernel.org>
Cc: Michal Simek <michal.simek@amd.com>,
Richard Weinberger <richard@nod.at>,
Vignesh Raghavendra <vigneshr@ti.com>,
Krzysztof Kozlowski <krzk+dt@kernel.org>,
Conor Dooley <conor+dt@kernel.org>,
linux-mtd@lists.infradead.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] dt-bindings: mtd: arasan: Add ZynqMP props
Date: Fri, 25 Sep 2026 14:52:56 +0200 [thread overview]
Message-ID: <87wls9jxw7.fsf@bootlin.com> (raw)
In-Reply-To: <20260925122003.GD677989-robh@kernel.org> (Rob Herring's message of "Fri, 25 Sep 2026 07:20:03 -0500")
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.
next prev parent reply other threads:[~2026-09-25 12:53 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-22 18:31 [PATCH] dt-bindings: mtd: arasan: Add ZynqMP props Rob Herring (Arm)
2026-09-22 18:31 ` Rob Herring (Arm)
2026-09-25 9:16 ` Miquel Raynal
2026-09-25 9:16 ` Miquel Raynal
2026-09-25 12:20 ` Rob Herring
2026-09-25 12:20 ` Rob Herring
2026-09-25 12:52 ` Miquel Raynal [this message]
2026-09-25 12:52 ` Miquel Raynal
2026-09-25 12:58 ` Michal Simek
2026-09-25 12:58 ` Michal Simek
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87wls9jxw7.fsf@bootlin.com \
--to=miquel.raynal@bootlin.com \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=krzk+dt@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mtd@lists.infradead.org \
--cc=michal.simek@amd.com \
--cc=richard@nod.at \
--cc=robh@kernel.org \
--cc=vigneshr@ti.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.