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:
 <TY3PR01MB113467EFBC5CE4BABBE2F4FF58666A@TY3PR01MB11346.jpnprd01.prod.outlook.com>
Date: Fri, 6 Feb 2026 10:08:03 +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: 06 February 2026 09:59
> Subject: Re: [PATCH 5/7] dmaengine: sh: rz-dmac: Add suspend to RAM support
> 
> Hi, Biju,
> 
> On 2/5/26 19:41, Biju Das wrote:
> > 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?
> 
> I see no conditions in your code. Just raw writes for DMA clocks and resets. 

The bootloader handling part is now moved to CPG, so raw write is fine
for probe/resume, that will address the below cases.

To boot the system without DMA driver
To boot without bootloader turning on DMA clk/resets
To turn on DMA clk/resets to get console during s2ram.

Cheers,
Biju