[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <50937606-46fd-4202-ad4b-9ede5bff76fc@tuxon.dev>
Date: Fri, 5 Dec 2025 11:59:51 +0200
From: Claudiu Beznea <claudiu.beznea@...on.dev>
To: Biju Das <biju.das.jz@...renesas.com>,
"p.zabel@...gutronix.de" <p.zabel@...gutronix.de>
Cc: "linux-kernel@...r.kernel.org" <linux-kernel@...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 v2 0/2] reset: rzg2l-usbphy-ctrl: Add suspend to RAM
support
Hi, Biju,
On 12/5/25 10:53, Biju Das wrote:
>
>
> Hi Claudiu,
>
>> -----Original Message-----
>> From: Claudiu Beznea <claudiu.beznea@...on.dev>
>> Sent: 04 December 2025 18:26
>> Subject: Re: [PATCH v2 0/2] reset: rzg2l-usbphy-ctrl: Add suspend to RAM support
>>
>> Hi, Philipp,
>>
>> Could you please let me know if there's anything I should do for this series?
>
> If rzg2l_usbphy_ctrl_suspend() fails, What is the probability that it will
> suspend again without any issue
How can I measure this?
The idea with this code was the following: if any instruction of suspend
fails, the suspend is aborted, thus code in rzg2l_usbphy_ctrl_suspend() is
trying to restore the runtime state of the HW so that no runtime users of
it to be affected. This is also how core suspend code is doing, e.g.
suspend_devices_and_enter().
> as currently we abort system suspend
> and enable clocks/deassert reset which keep draining the power.
The code is restoring the clocks and resets to their previous runtime state
so that any users of it to not be affected. Later, at runtime, if any power
needs to be saved the runtime PM framework will do its job.
Thank you,
Claudiu
Powered by blists - more mailing lists