Re: [cip-dev] [PATCH 6.12.y-cip 00/17] Backport RZ/G3S USB support

Hi, all,

Apologies for the late reply.

On 6/16/26 02:50, Nobuhiro Iwamatsu via lists.cip-project.org wrote:
> Hi all,
> 
>> -----Original Message-----
>> From: [email protected] <[email protected]> On Behalf Of Pavel Machek via lists.cip-project.org
>> Sent: Tuesday, June 16, 2026 6:03 AM
>> To: Claudiu Beznea <[email protected]>
>> Cc: [email protected]; iwamatsu nobuhiro(岩松 信洋 □ＤＩＴＣ○ＣＰＴ) <[email protected]>;
>> [email protected]
>> Subject: Re: [cip-dev] [PATCH 6.12.y-cip 00/17] Backport RZ/G3S USB support
>>
>> On Mon 2026-06-15 12:05:03, Claudiu Beznea wrote:
>>> Hi,
>>>
>>> On 6/12/26 00:04, Pavel Machek via lists.cip-project.org wrote:
>>>> Hi!
>>>>
>>>>> Thanks for your patch.
>>>>> I reviewed this and other series, these seems to be fine.
>>>>> I can apply this if tests are OK and there are no other comments.
>>>>>     Reviewed-by: Nobuhiro Iwamatsu
>>>>> <[email protected]>
>>>>
>>>> I'm looking into it. As this modifies generic code, I suggest we are
>>>> cautious here.
>>> Please let me know if you want me to limit that code to RZ/G3S SoC only.
>>
>> I'm still reviewing the series, sorry for delay.
>>
>> My first preffered option would be explanation why this is okay on
>> 5.10: (Will it change behaviour on non-renesas boards? How sure we are the behaviour change will not break something,
>> or slow things down
>> significantly?)
>>
>> +++ b/drivers/usb/host/ehci-platform.c
>> @@ -442,6 +442,17 @@ static int __maybe_unused ehci_platform_suspend(struct device *dev)
>>          if (pdata->power_suspend)
>>                  pdata->power_suspend(pdev);
>>
>> +       ret = reset_control_assert(priv->rsts);
>> +       if (ret) {
>> +               if (pdata->power_on)
>> +                       pdata->power_on(pdev);
>> +
>> +               ehci_resume(hcd, false);
>> +
>> +               if (priv->quirk_poll)
>> +                       quirk_poll_init(priv);
>> +       }
>> +
>>
>> If we can't have the explanation, limiting to renesas boards would be fine next option.
> 
> This concern was also discussed when the original patch was posted.
>     https://lkml.org/lkml/2025/11/7/557
> 
> If we are only addressing specific SoCs, I think we need to fix it in Upstream first.

The upstream discussion was about the code that tries to restore the USB state 
in case the reset_control_assert() fails.

+       if (ret) {
+               if (pdata->power_on)
+                       pdata->power_on(pdev);
+
+               ehci_resume(hcd, false);
+
+               if (priv->quirk_poll)
+                       quirk_poll_init(priv);
+       }

In the end the ohci/ehci platform driver maintainer agreed with the solution 
presented in this patch.

Could you please let me know what would you consider it should be fixed upstream?

Regarding the reset_control_assert()/reset_control_deassert() on the 
suspend/resume path, for the Renesas RZ/G3S SoC we need it as the SoC supports a 
suspend mode where power to the USB devices is turned off. On resume we need to 
re-configure the USB along with enabling the clocks and de-asserting the resets.

Thank you,
Claudiu