linux-kernel - Re: [PATCH v2 1/3] dt-bindings: spi: renesas,rzv2h-rspi: allow multiple DMAs

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAMuHMdWYKFoBnGaCfvVJFwYXEvtVyxXiAzHC2JvmTCwc5H91wQ@mail.gmail.com>
Date: Thu, 29 Jan 2026 09:04:45 +0100
From: Geert Uytterhoeven <geert@...ux-m68k.org>
To: Conor Dooley <conor@...nel.org>
Cc: Cosmin-Gabriel Tanislav <cosmin-gabriel.tanislav.xa@...esas.com>, 
	Fabrizio Castro <fabrizio.castro.jz@...esas.com>, Mark Brown <broonie@...nel.org>, 
	Rob Herring <robh@...nel.org>, Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley <conor+dt@...nel.org>, 
	Geert Uytterhoeven <geert+renesas@...der.be>, "magnus.damm" <magnus.damm@...il.com>, 
	"linux-spi@...r.kernel.org" <linux-spi@...r.kernel.org>, 
	"linux-renesas-soc@...r.kernel.org" <linux-renesas-soc@...r.kernel.org>, 
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>, 
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2 1/3] dt-bindings: spi: renesas,rzv2h-rspi: allow
 multiple DMAs

Hi Conor,

On Wed, 28 Jan 2026 at 21:09, Conor Dooley <conor@...nel.org> wrote:
> On Wed, Jan 28, 2026 at 06:51:48PM +0000, Cosmin-Gabriel Tanislav wrote:
> > > From: Conor Dooley <conor@...nel.org>

> > > 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.

The device is the SPI controller, or the SoC where the SPI controller
is integrated?

> >
> > 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.

The actual maximum number of dmas pairs does not depend on the SPI
controller, but on the SoC integration.  I think the (single) DMA
request signal from the SPI controller is just wired to all DMACs
present (on this SoC, IIRC there were some Renesas SoCs where some
 DMA clients are wired to only a single DMAC).

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@...ux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds