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] [day] [month] [year] [list]

Message-ID: <20260129-public-musty-ff00b2f8dda7@spud>
Date: Thu, 29 Jan 2026 09:16:21 +0000
From: Conor Dooley <conor@...nel.org>
To: Geert Uytterhoeven <geert@...ux-m68k.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

On Thu, Jan 29, 2026 at 09:04:45AM +0100, Geert Uytterhoeven wrote:
> 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?

Whether the SoC's number of dma controllers is the limiter or whether it's
the number of inputs to the spi controller isn't something I know the
answer to (and which it is in theory could vary between SoCs), so I used
device instead of "SoC integration of the spi controller represented by
a given compatible".

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

Right, that's largely what I had gathered from Cosmin-Gabriel's comments
and the patch itself. I think the comments I made here are all still
applicable? If there's a new SoC, there'll be a new compatible for the
spi controller's integration on that SoC and the limit can be bumped
then.

Cheers,
Conor.


Download attachment "signature.asc" of type "application/pgp-signature" (229 bytes)