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

Message-ID:
 <TY3PR01MB113460619AE8C46BC674B28078699A@TY3PR01MB11346.jpnprd01.prod.outlook.com>
Date: Thu, 5 Feb 2026 17:41:47 +0000
From: Biju Das <biju.das.jz@...renesas.com>
To: Claudiu.Beznea <claudiu.beznea@...on.dev>, geert <geert@...ux-m68k.org>
CC: "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 Claudiu,

> -----Original Message-----
> From: Claudiu Beznea <claudiu.beznea@...on.dev>
> Sent: 05 February 2026 17:21
> Subject: Re: [PATCH 5/7] dmaengine: sh: rz-dmac: Add suspend to RAM support
> 
> Hi, Biju,
> 
> On 2/5/26 16:06, Biju Das wrote:
> > Hi Geert,
> >
> >> -----Original Message-----
> >> From: Geert Uytterhoeven <geert@...ux-m68k.org>
> >> Sent: 05 February 2026 13:34
> >> 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?
> >
> > The below use cases will work (patch[1] - removing the code for
> > deassert in cpg_resume) as there is no DMA driver to assert the reset.
> >
> > 1) system will boot without DMA driver
> > 2) s2idle will work as there is no DMA driver to assert the reset.
> > 3) s2ram will work without DMA driver.
> >
> > If DMA driver is enabled, then there is an issue with  s2idle as DMA
> > driver assert the reset and we cannot use serial console as wakeup
> > source
> 
> I think we're taking here about both DMA clocks and resets.
> 
> What if the DMA clocks are declared critical in Linux and clocks and resets are not handled by
> bootloader in probe or resume? Who will restore critical clocks?

Patch [1] will restore critical clocks.
> 
> >
> > One solution is SoC quirk will prevent assert/deassert  of the DMA
> > reset during
> > suspend/resume() for affected SoCs.
> 
> This can't work w/o taking care of the DMA clocks in the clock driver resume function (in case DMA
> clocks are critical). If so, why handling DMA clocks and resets differently?


What will you prefer 

a single check in suspend/resume of DMA driver?

Or

Around 100 checks in suspend/resume in clock driver for checking critical resets for skipping DMA reset?

Cheers,
Biju