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: <32ea84f2-621a-47d9-a661-9acd62d50662@tuxon.dev>
Date: Thu, 5 Feb 2026 19:20:51 +0200
From: Claudiu Beznea <claudiu.beznea@...on.dev>
To: Biju Das <biju.das.jz@...renesas.com>, 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, 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? 
clk_prepare_enable() skips applying the setting to hardware as the critical 
clock refcount cannot reach zero.

> 
> 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?

> 
> Other solution is implement the critical reset and check for all assert calls to skip
> the DMA resets.

I prefer this solution + restore the DMA critical clocks on clock driver 
suspend/resume.

Thank you,
Claudiu