Re: [PATCH v2 0/2] reset: rzg2l-usbphy-ctrl: Add suspend to RAM support

[Claudiu Beznea]

On 12/5/25 13:55, Biju Das wrote:
> Hi Claudiu,
> 
>> -----Original Message-----
>> From: Biju Das
>> Sent: 05 December 2025 10:57
>> Subject: RE: [PATCH v2 0/2] reset: rzg2l-usbphy-ctrl: Add suspend to RAM support
>>
>>
>> Hi Claudiu,
>>
>>> -----Original Message-----
>>> From: Claudiu Beznea <claudiu.beznea@xxxxxxxxx>
>>> Sent: 05 December 2025 10:47
>>> Subject: Re: [PATCH v2 0/2] reset: rzg2l-usbphy-ctrl: Add suspend to
>>> RAM support
>>>
>>>
>>>
>>> On 12/5/25 12:17, Biju Das wrote:
>>>>
>>>>
>>>>> -----Original Message-----
>>>>> From: Claudiu Beznea <claudiu.beznea@xxxxxxxxx>
>>>>> Sent: 05 December 2025 10:00
>>>>> To: Biju Das <biju.das.jz@xxxxxxxxxxxxxx>; p.zabel@xxxxxxxxxxxxxx
>>>>> Cc: linux-kernel@xxxxxxxxxxxxxxx;
>>>>> linux-renesas-soc@xxxxxxxxxxxxxxx;
>>>>> Claudiu Beznea <claudiu.beznea.uj@xxxxxxxxxxxxxx>
>>>>> 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@xxxxxxxxx>
>>>>>>> Sent: 04 December 2025 18:26
>>>>>>> Subject: Re: [PATCH v2 0/2] reset: rzg2l-usbphy-ctrl: Add suspend
>>>>>>> to RAM support
>>>>>>>
>>>
>>> From my previous experience with suspend/resume implementations, I can
>>> say restoring the system in failure cases in suspend/resume or not, is
>>> up to the subsystem maintainer. So, I'll let Philipp to decide how he wants to go with it in this
>> driver.
>>>
>>
>> Agreed.
>>
>>> They are still supporting suspend to idle, where power is maintained,
>>> right? Shouldn't we cover this case?
>>
>> Yes, I agree. Probably best thing is zero failures, if there is a failure in suspend path, the same
>> device will fail in similar fashion, and the system never enters suspend state.
>>
>> So, report the failure and debug and fix the issue.
> 
> FYI, On your resume path, if the below call fails, then there is a pm imbalance for next suspend().
> 
> ret = pm_runtime_resume_and_get(dev);
> 
> Similarly, if reset_assert() fails for a shared reset.

Wouldn't be the same if there will be no failure path code?

Thank you,
Claudiu