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: <CA+V-a8t3va8GFF+2Z4jB2n53mbaaCc+rc483kV5i5a8fPiafRA@mail.gmail.com>
Date: Thu, 8 Jan 2026 14:26:15 +0000
From: "Lad, Prabhakar" <prabhakar.csengg@...il.com>
To: Geert Uytterhoeven <geert@...ux-m68k.org>
Cc: Magnus Damm <magnus.damm@...il.com>, Rob Herring <robh@...nel.org>, 
	Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley <conor+dt@...nel.org>, 
	linux-renesas-soc@...r.kernel.org, devicetree@...r.kernel.org, 
	linux-kernel@...r.kernel.org, Biju Das <biju.das.jz@...renesas.com>, 
	Fabrizio Castro <fabrizio.castro.jz@...esas.com>, 
	Lad Prabhakar <prabhakar.mahadev-lad.rj@...renesas.com>
Subject: Re: [PATCH 1/2] arm64: dts: renesas: r9a09g056: Add DMA support for
 RSPI channels

Hi Geert,

On Thu, Jan 8, 2026 at 1:44 PM Geert Uytterhoeven <geert@...ux-m68k.org> wrote:
>
> Hi Prabhakar,
>
> On Thu, 8 Jan 2026 at 14:26, Lad, Prabhakar <prabhakar.csengg@...il.com> wrote:
> > On Thu, Jan 8, 2026 at 1:18 PM Geert Uytterhoeven <geert@...ux-m68k.org> wrote:
> > > On Mon, 15 Dec 2025 at 17:34, Prabhakar <prabhakar.csengg@...il.com> wrote:
> > > > From: Lad Prabhakar <prabhakar.mahadev-lad.rj@...renesas.com>
> > > >
> > > > Enable DMA support for RSPI channels.
> > > >
> > > > Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@...renesas.com>
> > >
> > > Thanks for your patch!
> > >
> > > > --- a/arch/arm64/boot/dts/renesas/r9a09g056.dtsi
> > > > +++ b/arch/arm64/boot/dts/renesas/r9a09g056.dtsi
> > > > @@ -679,6 +679,8 @@ rspi0: spi@...00000 {
> > > >                         clock-names = "pclk", "pclk_sfr", "tclk";
> > > >                         resets = <&cpg 0x7b>, <&cpg 0x7c>;
> > > >                         reset-names = "presetn", "tresetn";
> > > > +                       dmas = <&dmac0 0x448c>, <&dmac0 0x448d>;
> > > > +                       dma-names = "rx", "tx";
> > >
> > > RZ/V2N does not seem to have restrictions about which DMA controllers
> > > can be used by which SPI instance.  Hence shouldn't these point to
> > > all five DMA controllers?
> > >
> > >     dmas = <&dmac0 0x448c>, <&dmac0 0x448d>,
> > >            <&dmac1 0x448c>, <&dmac1 0x448d>,
> > >            <&dmac2 0x448c>, <&dmac2 0x448d>,
> > >            <&dmac3 0x448c>, <&dmac3 0x448d>,
> > >            <&dmac4 0x448c>, <&dmac4 0x448d>;
> > >     dma-names = "rx", "tx", "rx", "tx", "rx", "tx",
> > >                 "rx", "tx", "rx", "tx";
> > >
> > So the driver would choose the DMA channel based on the available one?
> > For example if all the 16 channels are consumed for dmac0 the driver
> > would switch to the next available one dmacX? and this would be the
> > job of a consumer driver? Or do we want to let the board user
> > choose/override in board DTS based on the available DMAC channels?
>
> When there are multiple dmas entries with the same dma, the DMA
> subsystem picks a (random?) available channel.  This is clearly
> visible on e.g. Salvator-XS, where the mapping from I2C channels
> to DMA controllers changes on almost every boot
> (see /sys/kernel/debug/dmaengine/summary).
>
Aha thanks for the explanation (and pointer).

Cheers,
Prabhakar

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ