From: Conor Dooley <conor@kernel.org>
To: Cosmin-Gabriel Tanislav <cosmin-gabriel.tanislav.xa@renesas.com>
Cc: Fabrizio Castro <fabrizio.castro.jz@renesas.com>,
Mark Brown <broonie@kernel.org>, Rob Herring <robh@kernel.org>,
Krzysztof Kozlowski <krzk+dt@kernel.org>,
Conor Dooley <conor+dt@kernel.org>,
Geert Uytterhoeven <geert+renesas@glider.be>,
"magnus.damm" <magnus.damm@gmail.com>,
"linux-spi@vger.kernel.org" <linux-spi@vger.kernel.org>,
"linux-renesas-soc@vger.kernel.org"
<linux-renesas-soc@vger.kernel.org>,
"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v2 1/3] dt-bindings: spi: renesas,rzv2h-rspi: allow multiple DMAs
Date: Wed, 28 Jan 2026 20:09:25 +0000 [thread overview]
Message-ID: <20260128-debatable-scribe-4e55c208b31a@spud> (raw)
In-Reply-To: <TYRPR01MB15619DCD987445778003A81588591A@TYRPR01MB15619.jpnprd01.prod.outlook.com>
[-- Attachment #1: Type: text/plain, Size: 4948 bytes --]
On Wed, Jan 28, 2026 at 06:51:48PM +0000, Cosmin-Gabriel Tanislav wrote:
> Hi Conor, thank you for your response.
>
> > From: Conor Dooley <conor@kernel.org>
> > Sent: Wednesday, January 28, 2026 8:09 PM
> >
> > On Tue, Jan 27, 2026 at 10:17:04PM +0200, Cosmin Tanislav wrote:
> > > The Renesas RZ/T2H and RZ/N2H SoCs have multiple DMA controllers that
> > > can be used with the RSPI peripheral. The current bindings only allow a
> > > single pair of RX and TX DMAs.
> > >
> > > Allow multiple DMAs by only restricting the possible names of the DMA
> > > channels.
> > >
> >
> > > All '.*-names$' properties must conform to the string-array.yaml
> > > meta-schema, which requires both minItems and maxItems properties to be
> > > present before the items can be a schema. Otherwise, the items need to
> > > be an array.
> >
> > Why is this in the commit message?
> >
>
> To provide a context for the maxItems that are needed below, even if
> there's not really a maximum. Which is why having a maxItems does not
> really make sense but it is expected by the meta-schema so we can
> constrain the names of the DMA channels.
>
> dtschema/meta-schemas/string-array.yaml:
>
> if:
> not:
> required:
> - minItems
> - maxItems
> then:
> properties:
> items:
> type: array
Right. You can probably remove all that since I'm asking you to add
actual constraints to the property.
> > > Declare a generous maxItems of 32, which should be enough for 16 DMA
> > > controllers, so that we don't have to update this value ever again, even
> > > if currently the maximum number of DMA controllers on a Renesas SoC is
> > > 5.
> >
> > Huh, No. The binding should constrain this to fit what the actual
> > devices do.
> >
>
> Should the binding for SPI be updated if a device ever comes up with
> 6 DMA controllers? It seems a bit unrelated to me. In this case, should
> we constrain the number of dmas and dma-names per SoC? Some may have 2
> DMA controllers, while others may have 5. Please let me know your
> thoughts, taking into account that I only added maxItems to satisfy the
> meta-schema.
Yes, I think you should constrain it to the correct number of providers
for each device.
Whether that's done or not, there's not all that much reason to set it
above whatever the current maximum is, since the binding will have to be
updated to add the compatible for whatever device exceeds the current max
and the limit can be increased then.
> > > Signed-off-by: Cosmin Tanislav <cosmin-gabriel.tanislav.xa@renesas.com>
> > > ---
> > >
> > > V2:
> > > * new patch
> > >
> > > .../devicetree/bindings/spi/renesas,rzv2h-rspi.yaml | 10 ++++++----
> > > 1 file changed, 6 insertions(+), 4 deletions(-)
> > >
> > > diff --git a/Documentation/devicetree/bindings/spi/renesas,rzv2h-rspi.yaml
> > b/Documentation/devicetree/bindings/spi/renesas,rzv2h-rspi.yaml
> > > index a588b112e11e..383e97f0dabd 100644
> > > --- a/Documentation/devicetree/bindings/spi/renesas,rzv2h-rspi.yaml
> > > +++ b/Documentation/devicetree/bindings/spi/renesas,rzv2h-rspi.yaml
> > > @@ -57,13 +57,15 @@ properties:
> > > - const: presetn
> > > - const: tresetn
> > >
> > > - dmas:
> > > - maxItems: 2
> > > + dmas: true
> >
> > This should have the same constraints as dma-names. You've now allowed
> > this to have 1 and 33 dmas, because there's no requirement to have
> > dma-names when you have dmas.
> >
>
> I agree, I will fix it for V2 once you decide how to proceed with the
> other comments.
>
> > >
> > > dma-names:
> > > + minItems: 2
> > > + maxItems: 32
> > > items:
> > > - - const: rx
> > > - - const: tx
> > > + enum:
> > > + - rx
> > > + - tx
> >
> > You've changed this to allow 32 dma-names, but they all need to be
> > called either "rx" or "tx", how is a driver meant to use dma-names to
> > get the second pair of dma channels? Shouldn't anything in excess of the
> > first two start getting numbers appended so that a driver can actually
> > request them?
> >
>
> The DMA core handles multiple DMA channels with the same name by checking
> their availability consecutively until finding an available one.
TIL
> I agree that this is not pretty but this pattern is already used in the
> bindings / device tree for many Renesas IPs.
>
> There's even an exception inside dt-schema specifically for this.
Hmm, I see. Can you please put this into the commit message cos otherwise
this looks really strange!
>
> dtschema/schemas/dma/dma.yaml:
> dma-names:
> anyOf:
> - uniqueItems: true
> - items:
> # Hack around Renesas bindings which repeat entries to support
> # multiple possible DMA providers
> enum: [rx, tx]
>
> > pw-bot: changes-requested
> >
> > Conor.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
next prev parent reply other threads:[~2026-01-28 20:09 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-27 20:17 [PATCH v2 0/3] Add DMA support for RZ/T2H RSPI Cosmin Tanislav
2026-01-27 20:17 ` [PATCH v2 1/3] dt-bindings: spi: renesas,rzv2h-rspi: allow multiple DMAs Cosmin Tanislav
2026-01-28 18:08 ` Conor Dooley
2026-01-28 18:51 ` Cosmin-Gabriel Tanislav
2026-01-28 20:09 ` Conor Dooley [this message]
2026-01-28 20:31 ` Cosmin-Gabriel Tanislav
2026-01-29 8:04 ` Geert Uytterhoeven
2026-01-29 9:16 ` Conor Dooley
2026-01-27 20:17 ` [PATCH v2 2/3] arm64: dts: renesas: r9a09g077: wire up DMA support for SPI Cosmin Tanislav
2026-01-27 20:17 ` [PATCH v2 3/3] arm64: dts: renesas: r9a09g087: " Cosmin Tanislav
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=20260128-debatable-scribe-4e55c208b31a@spud \
--to=conor@kernel.org \
--cc=broonie@kernel.org \
--cc=conor+dt@kernel.org \
--cc=cosmin-gabriel.tanislav.xa@renesas.com \
--cc=devicetree@vger.kernel.org \
--cc=fabrizio.castro.jz@renesas.com \
--cc=geert+renesas@glider.be \
--cc=krzk+dt@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-renesas-soc@vger.kernel.org \
--cc=linux-spi@vger.kernel.org \
--cc=magnus.damm@gmail.com \
--cc=robh@kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox