linux-kernel - Re: [PATCH 5/7] dmaengine: sh: rz-dmac: Add suspend to RAM support

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: <CAMuHMdWUpq1bUbNLu4WGheovQ1pYdEJGBMN3jdb6PZqXanN_GA@mail.gmail.com>
Date: Thu, 5 Feb 2026 14:33:52 +0100
From: Geert Uytterhoeven <geert@...ux-m68k.org>
To: Biju Das <biju.das.jz@...renesas.com>
Cc: "Claudiu.Beznea" <claudiu.beznea@...on.dev>, "vkoul@...nel.org" <vkoul@...nel.org>, 
	Prabhakar Mahadev Lad <prabhakar.mahadev-lad.rj@...renesas.com>, 
	"lgirdwood@...il.com" <lgirdwood@...il.com>, "broonie@...nel.org" <broonie@...nel.org>, 
	"perex@...ex.cz" <perex@...ex.cz>, "tiwai@...e.com" <tiwai@...e.com>, 
	"p.zabel@...gutronix.de" <p.zabel@...gutronix.de>, 
	"geert+renesas@...der.be" <geert+renesas@...der.be>, Fabrizio Castro <fabrizio.castro.jz@...esas.com>, 
	"dmaengine@...r.kernel.org" <dmaengine@...r.kernel.org>, 
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, 
	"linux-sound@...r.kernel.org" <linux-sound@...r.kernel.org>, 
	"linux-renesas-soc@...r.kernel.org" <linux-renesas-soc@...r.kernel.org>, 
	Claudiu Beznea <claudiu.beznea.uj@...renesas.com>
Subject: Re: [PATCH 5/7] dmaengine: sh: rz-dmac: Add suspend to RAM support

Hi Biju,

On Thu, 5 Feb 2026 at 14:30, Biju Das <biju.das.jz@...renesas.com> wrote:
> > From: Claudiu Beznea <claudiu.beznea@...on.dev>
> > On 1/26/26 17:28, Biju Das wrote:
> > >> For s2idle issue on RZ/G3L is DMA device is in asserted state, not
> > >> forwarding any IRQ to cpu for wakeup.
> > >>
> > >> For S2RAM issue on RZ/G3L is during suspend hardware turns DMAACLK
> > >> off/ Asserted state. Clock framwork is not turning On DMAACLK as it critical clk.
> > >>
> > >> Can you please check your TF-A for the second case? First case,
> > >> RZ/G3S may ok for reset assert state, it can forward IRQs to CPU.
> > >
> > > Just to summarize, currently there are 2 differences identified between RZ/G3S and RZ/G3L:
> > >
> > > SoC differences for s2idle:
> > >
> > > RZ/G3S: Can wake the system if the DMA device is in the assert state
> > >
> > > RZ/G3L: Cannot wake the system if the DMA device is in the assert state.
> > >
> > >
> > > TF-A differences for s2ram:
> > >
> > > RZ/G3S: TF_A turns on DMA_ACLK during boot/resume.
> > >
> > > RZ/G3L: TF_A does not handle DMA_ACLK during boot/resume.
> >
> > I'm seeing at [1] you are addressing these differences in the clock/reset drivers. With that, are you
> > still considering this patch is breaking your system?
>
> Still, thinking whether to add critical reset or go with SoC quirk in DMA driver.
> Some SoCs need DMA should be deasserted like critical clock
> that can be handled either
>
> 1) Add a simple SoC quirk in DMA driver
>
> Or
>
> 2) Implement critical reset in SoC specific clock driver and check for all resets.
>
> Is simple SoC quirk in DMA driver, something can be done for RZ/G2L family SoCs?

What if the DMA driver is not enabled?

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