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:
 <TY3PR01MB11346321A9AAE93C7070C6E578699A@TY3PR01MB11346.jpnprd01.prod.outlook.com>
Date: Thu, 5 Feb 2026 13:30:32 +0000
From: Biju Das <biju.das.jz@...renesas.com>
To: 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>
CC: "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 Claudiu Beznea,

> -----Original Message-----
> From: Claudiu Beznea <claudiu.beznea@...on.dev>
> Sent: 05 February 2026 13:00
> Subject: Re: [PATCH 5/7] dmaengine: sh: rz-dmac: Add suspend to RAM support
> 
> Hi, Biju,
> 
> On 1/26/26 17:28, Biju Das wrote:
> > Hi All,
> >
> >> -----Original Message-----
> >> From: Biju Das
> >> Sent: 26 January 2026 13:12
> >> Subject: RE: [PATCH 5/7] dmaengine: sh: rz-dmac: Add suspend to RAM
> >> support
> >>
> 
> [ ... ]
> 
> >>
> >> 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?

Cheers,
Biju