[PATCH 0/4] usb: host: renesas: Handle reset signals on suspend/resume

[PATCH 0/4] usb: host: renesas: Handle reset signals on suspend/resume

[Claudiu]

From: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>

Hi,

This series adds handling of reset signals during suspend and resume.
This is necessary for the Renesas RZ/G3S SoC, which has a power-saving
mode that turns off power to most SoC components (including USB).
The reset signals need to be configured accordingly during
suspend and resume.

In addition, a cleanup patch (1/4) has been included.

Thank you,
Claudiu

Claudiu Beznea (4):
  usb: host: Do not check priv->clks[clk]
  usb: host: ehci-platform: Call reset assert/deassert on suspend/resume
  usb: host: ohci-platform: Call reset assert/deassert on suspend/resume
  usb: renesas_usbhs: Assert/de-assert reset signal on suspend/resume

 drivers/usb/host/ehci-platform.c   | 25 +++++++++++++++++----
 drivers/usb/host/ohci-platform.c   | 24 ++++++++++++++++----
 drivers/usb/renesas_usbhs/common.c | 35 ++++++++++++++++++++++--------
 3 files changed, 67 insertions(+), 17 deletions(-)

-- 
2.43.0

[PATCH 1/4] usb: host: Do not check priv->clks[clk]

[Claudiu]

From: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>

There is no need to check the entries in priv->clks[] array before passing
it to clk_disable_unprepare() as the clk_disable_unprepare() already
check if it receives a NULL or error pointer as argument. Remove this
check. This makes the code simpler.

Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
---
 drivers/usb/host/ehci-platform.c | 3 +--
 drivers/usb/host/ohci-platform.c | 3 +--
 2 files changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/usb/host/ehci-platform.c b/drivers/usb/host/ehci-platform.c
index bcd1c9073515..57d5a7ddac5f 100644
--- a/drivers/usb/host/ehci-platform.c
+++ b/drivers/usb/host/ehci-platform.c
@@ -112,8 +112,7 @@ static void ehci_platform_power_off(struct platform_device *dev)
 	int clk;
 
 	for (clk = EHCI_MAX_CLKS - 1; clk >= 0; clk--)
-		if (priv->clks[clk])
-			clk_disable_unprepare(priv->clks[clk]);
+		clk_disable_unprepare(priv->clks[clk]);
 }
 
 static struct hc_driver __read_mostly ehci_platform_hc_driver;
diff --git a/drivers/usb/host/ohci-platform.c b/drivers/usb/host/ohci-platform.c
index f47ae12cde6a..af26f1449bc2 100644
--- a/drivers/usb/host/ohci-platform.c
+++ b/drivers/usb/host/ohci-platform.c
@@ -69,8 +69,7 @@ static void ohci_platform_power_off(struct platform_device *dev)
 	int clk;
 
 	for (clk = OHCI_MAX_CLKS - 1; clk >= 0; clk--)
-		if (priv->clks[clk])
-			clk_disable_unprepare(priv->clks[clk]);
+		clk_disable_unprepare(priv->clks[clk]);
 }
 
 static struct hc_driver __read_mostly ohci_platform_hc_driver;
-- 
2.43.0

Re: [PATCH 1/4] usb: host: Do not check priv->clks[clk]

[Geert Uytterhoeven]

Hi Claudiu,

Thanks for your patch!

On Thu, 6 Nov 2025 at 15:36, Claudiu <claudiu.beznea@tuxon.dev> wrote:
> From: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
>
> There is no need to check the entries in priv->clks[] array before passing
> it to clk_disable_unprepare() as the clk_disable_unprepare() already

them ... as clk_disable_unprepare

> check if it receives a NULL or error pointer as argument. Remove this

checks

> check. This makes the code simpler.
>
> Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>

Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH 1/4] usb: host: Do not check priv->clks[clk]

[Alan Stern]

On Thu, Nov 06, 2025 at 04:36:22PM +0200, Claudiu wrote:
> From: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
> 
> There is no need to check the entries in priv->clks[] array before passing
> it to clk_disable_unprepare() as the clk_disable_unprepare() already
> check if it receives a NULL or error pointer as argument. Remove this
> check. This makes the code simpler.
> 
> Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
> ---

Acked-by: Alan Stern <stern@rowland.harvard.edu>

>  drivers/usb/host/ehci-platform.c | 3 +--
>  drivers/usb/host/ohci-platform.c | 3 +--
>  2 files changed, 2 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/usb/host/ehci-platform.c b/drivers/usb/host/ehci-platform.c
> index bcd1c9073515..57d5a7ddac5f 100644
> --- a/drivers/usb/host/ehci-platform.c
> +++ b/drivers/usb/host/ehci-platform.c
> @@ -112,8 +112,7 @@ static void ehci_platform_power_off(struct platform_device *dev)
>  	int clk;
>  
>  	for (clk = EHCI_MAX_CLKS - 1; clk >= 0; clk--)
> -		if (priv->clks[clk])
> -			clk_disable_unprepare(priv->clks[clk]);
> +		clk_disable_unprepare(priv->clks[clk]);
>  }
>  
>  static struct hc_driver __read_mostly ehci_platform_hc_driver;
> diff --git a/drivers/usb/host/ohci-platform.c b/drivers/usb/host/ohci-platform.c
> index f47ae12cde6a..af26f1449bc2 100644
> --- a/drivers/usb/host/ohci-platform.c
> +++ b/drivers/usb/host/ohci-platform.c
> @@ -69,8 +69,7 @@ static void ohci_platform_power_off(struct platform_device *dev)
>  	int clk;
>  
>  	for (clk = OHCI_MAX_CLKS - 1; clk >= 0; clk--)
> -		if (priv->clks[clk])
> -			clk_disable_unprepare(priv->clks[clk]);
> +		clk_disable_unprepare(priv->clks[clk]);
>  }
>  
>  static struct hc_driver __read_mostly ohci_platform_hc_driver;
> -- 
> 2.43.0
> 

[PATCH 2/4] usb: host: ehci-platform: Call reset assert/deassert on suspend/resume

[Claudiu]

From: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>

The Renesas RZ/G3S SoC supports a power-saving mode in which power to most
of the SoC components is turned off, including the USB blocks. On the
resume path, the reset signal must be de-asserted before applying any
settings to the USB registers. To handle this properly, call
reset_control_assert() and reset_control_deassert() during suspend and
resume, respectively.

Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
---
 drivers/usb/host/ehci-platform.c | 22 ++++++++++++++++++++--
 1 file changed, 20 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/host/ehci-platform.c b/drivers/usb/host/ehci-platform.c
index 57d5a7ddac5f..f61f095cedab 100644
--- a/drivers/usb/host/ehci-platform.c
+++ b/drivers/usb/host/ehci-platform.c
@@ -454,6 +454,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);
+	}
+
 	return ret;
 }
 
@@ -464,11 +475,18 @@ static int __maybe_unused ehci_platform_resume(struct device *dev)
 	struct platform_device *pdev = to_platform_device(dev);
 	struct ehci_platform_priv *priv = hcd_to_ehci_priv(hcd);
 	struct device *companion_dev;
+	int err;
+
+	err = reset_control_deassert(priv->rsts);
+	if (err)
+		return err;
 
 	if (pdata->power_on) {
-		int err = pdata->power_on(pdev);
-		if (err < 0)
+		err = pdata->power_on(pdev);
+		if (err < 0) {
+			reset_control_assert(priv->rsts);
 			return err;
+		}
 	}
 
 	companion_dev = usb_of_get_companion_dev(hcd->self.controller);
-- 
2.43.0

Re: [PATCH 2/4] usb: host: ehci-platform: Call reset assert/deassert on suspend/resume

[Geert Uytterhoeven]

Hi Claudiu,

On Thu, 6 Nov 2025 at 15:36, Claudiu <claudiu.beznea@tuxon.dev> wrote:
> From: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
>
> The Renesas RZ/G3S SoC supports a power-saving mode in which power to most
> of the SoC components is turned off, including the USB blocks. On the
> resume path, the reset signal must be de-asserted before applying any
> settings to the USB registers. To handle this properly, call
> reset_control_assert() and reset_control_deassert() during suspend and
> resume, respectively.
>
> Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>

Thanks for your patch!

> --- a/drivers/usb/host/ehci-platform.c
> +++ b/drivers/usb/host/ehci-platform.c
> @@ -454,6 +454,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);

I have my doubts about the effectiveness of this "reverse error
handling".  If the reset_control_assert() failed, what are the chances
that the device will actually work after trying to bring it up again?

Same comment for next patch.

> +       }
> +
>         return ret;
>  }
>

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH 2/4] usb: host: ehci-platform: Call reset assert/deassert on suspend/resume

[Claudiu Beznea]

Hi, Geert,

On 11/6/25 16:52, Geert Uytterhoeven wrote:
> Hi Claudiu,
> 
> On Thu, 6 Nov 2025 at 15:36, Claudiu <claudiu.beznea@tuxon.dev> wrote:
>> From: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
>>
>> The Renesas RZ/G3S SoC supports a power-saving mode in which power to most
>> of the SoC components is turned off, including the USB blocks. On the
>> resume path, the reset signal must be de-asserted before applying any
>> settings to the USB registers. To handle this properly, call
>> reset_control_assert() and reset_control_deassert() during suspend and
>> resume, respectively.
>>
>> Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
> 
> Thanks for your patch!
> 
>> --- a/drivers/usb/host/ehci-platform.c
>> +++ b/drivers/usb/host/ehci-platform.c
>> @@ -454,6 +454,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);
> 
> I have my doubts about the effectiveness of this "reverse error
> handling".  If the reset_control_assert() failed, what are the chances
> that the device will actually work after trying to bring it up again?
> 
> Same comment for next patch.

I wasn't sure if I should do this revert or not. In my mind, if the reset
assert fails, the reset signal is still de-asserted.

Thank you,
Claudiu

> 
>> +       }
>> +
>>         return ret;
>>  }
>>
> 
> Gr{oetje,eeting}s,
> 
>                         Geert
> 

Re: [PATCH 2/4] usb: host: ehci-platform: Call reset assert/deassert on suspend/resume

[Geert Uytterhoeven]

Hi Claudiu,

On Thu, 6 Nov 2025 at 19:56, Claudiu Beznea <claudiu.beznea@tuxon.dev> wrote:
> On 11/6/25 16:52, Geert Uytterhoeven wrote:
> > On Thu, 6 Nov 2025 at 15:36, Claudiu <claudiu.beznea@tuxon.dev> wrote:
> >> From: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
> >>
> >> The Renesas RZ/G3S SoC supports a power-saving mode in which power to most
> >> of the SoC components is turned off, including the USB blocks. On the
> >> resume path, the reset signal must be de-asserted before applying any
> >> settings to the USB registers. To handle this properly, call
> >> reset_control_assert() and reset_control_deassert() during suspend and
> >> resume, respectively.
> >>
> >> Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
> >
> >> --- a/drivers/usb/host/ehci-platform.c
> >> +++ b/drivers/usb/host/ehci-platform.c
> >> @@ -454,6 +454,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);
> >
> > I have my doubts about the effectiveness of this "reverse error
> > handling".  If the reset_control_assert() failed, what are the chances
> > that the device will actually work after trying to bring it up again?
> >
> > Same comment for next patch.
>
> I wasn't sure if I should do this revert or not. In my mind, if the reset
> assert fails, the reset signal is still de-asserted.

Possibly.  Most reset implementations either cannot fail, or can
fail due to a timeout.  What state the device is in in case of the latter is
hard to guess...

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH 2/4] usb: host: ehci-platform: Call reset assert/deassert on suspend/resume

[Claudiu Beznea]

Hi, Geert,

On 11/7/25 10:01, Geert Uytterhoeven wrote:
> Hi Claudiu,
> 
> On Thu, 6 Nov 2025 at 19:56, Claudiu Beznea <claudiu.beznea@tuxon.dev> wrote:
>> On 11/6/25 16:52, Geert Uytterhoeven wrote:
>>> On Thu, 6 Nov 2025 at 15:36, Claudiu <claudiu.beznea@tuxon.dev> wrote:
>>>> From: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
>>>>
>>>> The Renesas RZ/G3S SoC supports a power-saving mode in which power to most
>>>> of the SoC components is turned off, including the USB blocks. On the
>>>> resume path, the reset signal must be de-asserted before applying any
>>>> settings to the USB registers. To handle this properly, call
>>>> reset_control_assert() and reset_control_deassert() during suspend and
>>>> resume, respectively.
>>>>
>>>> Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
>>>
>>>> --- a/drivers/usb/host/ehci-platform.c
>>>> +++ b/drivers/usb/host/ehci-platform.c
>>>> @@ -454,6 +454,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);
>>>
>>> I have my doubts about the effectiveness of this "reverse error
>>> handling".  If the reset_control_assert() failed, what are the chances
>>> that the device will actually work after trying to bring it up again?
>>>
>>> Same comment for next patch.
>>
>> I wasn't sure if I should do this revert or not. In my mind, if the reset
>> assert fails, the reset signal is still de-asserted.
> 
> Possibly.  Most reset implementations either cannot fail, or can
> fail due to a timeout.  What state the device is in in case of the latter is
> hard to guess...

In theory there are also failures returned by the subsystem code (e.g. if
reset is shared and its reference counts don't have the proper values, if
not shared and ops->assert is missing).

In case of this particular driver and the ochi-platform one, as the resets
request is done with devm_reset_control_array_get_optional_shared() the
priv->resets is an array and the assert/de-assert is done through
reset_control_array_assert()/reset_control_array_deassert() which, in case
of failures, reverts the assert/de-assert operations. It is true that the
effectiveness of the revert operation is unknown and depends on the HW, but
the subsystem ensures it reverts the previous state in case of failure.

For the case resets is not an array, it is true, it depends on the reset
driver implementation and hardware.

Could you please let me know how would you suggest going forward with the
implementation for the patches in this series?

Thank you,
Claudiu

Re: [PATCH 2/4] usb: host: ehci-platform: Call reset assert/deassert on suspend/resume

[Geert Uytterhoeven]

Hi Claudiu,

On Fri, 7 Nov 2025 at 19:42, Claudiu Beznea <claudiu.beznea@tuxon.dev> wrote:
> On 11/7/25 10:01, Geert Uytterhoeven wrote:
> > On Thu, 6 Nov 2025 at 19:56, Claudiu Beznea <claudiu.beznea@tuxon.dev> wrote:
> >> On 11/6/25 16:52, Geert Uytterhoeven wrote:
> >>> On Thu, 6 Nov 2025 at 15:36, Claudiu <claudiu.beznea@tuxon.dev> wrote:
> >>>> From: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
> >>>>
> >>>> The Renesas RZ/G3S SoC supports a power-saving mode in which power to most
> >>>> of the SoC components is turned off, including the USB blocks. On the
> >>>> resume path, the reset signal must be de-asserted before applying any
> >>>> settings to the USB registers. To handle this properly, call
> >>>> reset_control_assert() and reset_control_deassert() during suspend and
> >>>> resume, respectively.
> >>>>
> >>>> Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
> >>>
> >>>> --- a/drivers/usb/host/ehci-platform.c
> >>>> +++ b/drivers/usb/host/ehci-platform.c
> >>>> @@ -454,6 +454,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);
> >>>
> >>> I have my doubts about the effectiveness of this "reverse error
> >>> handling".  If the reset_control_assert() failed, what are the chances
> >>> that the device will actually work after trying to bring it up again?
> >>>
> >>> Same comment for next patch.
> >>
> >> I wasn't sure if I should do this revert or not. In my mind, if the reset
> >> assert fails, the reset signal is still de-asserted.
> >
> > Possibly.  Most reset implementations either cannot fail, or can
> > fail due to a timeout.  What state the device is in in case of the latter is
> > hard to guess...
>
> In theory there are also failures returned by the subsystem code (e.g. if
> reset is shared and its reference counts don't have the proper values, if
> not shared and ops->assert is missing).
>
> In case of this particular driver and the ochi-platform one, as the resets
> request is done with devm_reset_control_array_get_optional_shared() the
> priv->resets is an array and the assert/de-assert is done through
> reset_control_array_assert()/reset_control_array_deassert() which, in case
> of failures, reverts the assert/de-assert operations. It is true that the
> effectiveness of the revert operation is unknown and depends on the HW, but
> the subsystem ensures it reverts the previous state in case of failure.
>
> For the case resets is not an array, it is true, it depends on the reset
> driver implementation and hardware.
>
> Could you please let me know how would you suggest going forward with the
> implementation for the patches in this series?

Up to the USB maintainer...

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH 2/4] usb: host: ehci-platform: Call reset assert/deassert on suspend/resume

[Alan Stern]

On Mon, Nov 10, 2025 at 10:29:22AM +0100, Geert Uytterhoeven wrote:
> Hi Claudiu,
> 
> On Fri, 7 Nov 2025 at 19:42, Claudiu Beznea <claudiu.beznea@tuxon.dev> wrote:
> > On 11/7/25 10:01, Geert Uytterhoeven wrote:
> > > On Thu, 6 Nov 2025 at 19:56, Claudiu Beznea <claudiu.beznea@tuxon.dev> wrote:
> > >> On 11/6/25 16:52, Geert Uytterhoeven wrote:
> > >>> On Thu, 6 Nov 2025 at 15:36, Claudiu <claudiu.beznea@tuxon.dev> wrote:
> > >>>> From: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
> > >>>>
> > >>>> The Renesas RZ/G3S SoC supports a power-saving mode in which power to most
> > >>>> of the SoC components is turned off, including the USB blocks. On the
> > >>>> resume path, the reset signal must be de-asserted before applying any
> > >>>> settings to the USB registers. To handle this properly, call
> > >>>> reset_control_assert() and reset_control_deassert() during suspend and
> > >>>> resume, respectively.
> > >>>>
> > >>>> Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
> > >>>
> > >>>> --- a/drivers/usb/host/ehci-platform.c
> > >>>> +++ b/drivers/usb/host/ehci-platform.c
> > >>>> @@ -454,6 +454,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);
> > >>>
> > >>> I have my doubts about the effectiveness of this "reverse error
> > >>> handling".  If the reset_control_assert() failed, what are the chances
> > >>> that the device will actually work after trying to bring it up again?
> > >>>
> > >>> Same comment for next patch.
> > >>
> > >> I wasn't sure if I should do this revert or not. In my mind, if the reset
> > >> assert fails, the reset signal is still de-asserted.
> > >
> > > Possibly.  Most reset implementations either cannot fail, or can
> > > fail due to a timeout.  What state the device is in in case of the latter is
> > > hard to guess...
> >
> > In theory there are also failures returned by the subsystem code (e.g. if
> > reset is shared and its reference counts don't have the proper values, if
> > not shared and ops->assert is missing).
> >
> > In case of this particular driver and the ochi-platform one, as the resets
> > request is done with devm_reset_control_array_get_optional_shared() the
> > priv->resets is an array and the assert/de-assert is done through
> > reset_control_array_assert()/reset_control_array_deassert() which, in case
> > of failures, reverts the assert/de-assert operations. It is true that the
> > effectiveness of the revert operation is unknown and depends on the HW, but
> > the subsystem ensures it reverts the previous state in case of failure.
> >
> > For the case resets is not an array, it is true, it depends on the reset
> > driver implementation and hardware.
> >
> > Could you please let me know how would you suggest going forward with the
> > implementation for the patches in this series?
> 
> Up to the USB maintainer...

If you don't have any objections, the patches to ehci-platform.c and 
ohci-platform.c are okay with me.

Acked-by: Alan Stern <stern@rowland.harvard.edu>

Alan Stern

[PATCH 3/4] usb: host: ohci-platform: Call reset assert/deassert on suspend/resume

[Claudiu]

From: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>

The Renesas RZ/G3S SoC supports a power-saving mode in which power to most
of the SoC components is turned off, including the USB blocks. On the
resume path, the reset signal must be de-asserted before applying any
settings to the USB registers. To handle this properly, call
reset_control_assert() and reset_control_deassert() during suspend and
resume, respectively.

Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
---
 drivers/usb/host/ohci-platform.c | 21 +++++++++++++++++++--
 1 file changed, 19 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/host/ohci-platform.c b/drivers/usb/host/ohci-platform.c
index af26f1449bc2..2e4bb5cc2165 100644
--- a/drivers/usb/host/ohci-platform.c
+++ b/drivers/usb/host/ohci-platform.c
@@ -270,6 +270,7 @@ static int ohci_platform_suspend(struct device *dev)
 	struct usb_hcd *hcd = dev_get_drvdata(dev);
 	struct usb_ohci_pdata *pdata = dev->platform_data;
 	struct platform_device *pdev = to_platform_device(dev);
+	struct ohci_platform_priv *priv = hcd_to_ohci_priv(hcd);
 	bool do_wakeup = device_may_wakeup(dev);
 	int ret;
 
@@ -280,6 +281,14 @@ static int ohci_platform_suspend(struct device *dev)
 	if (pdata->power_suspend)
 		pdata->power_suspend(pdev);
 
+	ret = reset_control_assert(priv->resets);
+	if (ret) {
+		if (pdata->power_on)
+			pdata->power_on(pdev);
+
+		ohci_resume(hcd, false);
+	}
+
 	return ret;
 }
 
@@ -288,11 +297,19 @@ static int ohci_platform_resume_common(struct device *dev, bool hibernated)
 	struct usb_hcd *hcd = dev_get_drvdata(dev);
 	struct usb_ohci_pdata *pdata = dev_get_platdata(dev);
 	struct platform_device *pdev = to_platform_device(dev);
+	struct ohci_platform_priv *priv = hcd_to_ohci_priv(hcd);
+	int err;
+
+	err = reset_control_deassert(priv->resets);
+	if (err)
+		return err;
 
 	if (pdata->power_on) {
-		int err = pdata->power_on(pdev);
-		if (err < 0)
+		err = pdata->power_on(pdev);
+		if (err < 0) {
+			reset_control_assert(priv->resets);
 			return err;
+		}
 	}
 
 	ohci_resume(hcd, hibernated);
-- 
2.43.0

Re: [PATCH 3/4] usb: host: ohci-platform: Call reset assert/deassert on suspend/resume

[Geert Uytterhoeven]

Hi Claudiu,

On Thu, 6 Nov 2025 at 15:36, Claudiu <claudiu.beznea@tuxon.dev> wrote:
> From: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
>
> The Renesas RZ/G3S SoC supports a power-saving mode in which power to most
> of the SoC components is turned off, including the USB blocks. On the
> resume path, the reset signal must be de-asserted before applying any
> settings to the USB registers. To handle this properly, call
> reset_control_assert() and reset_control_deassert() during suspend and
> resume, respectively.
>
> Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>

Thanks for your patch!

> --- a/drivers/usb/host/ohci-platform.c
> +++ b/drivers/usb/host/ohci-platform.c
> @@ -280,6 +281,14 @@ static int ohci_platform_suspend(struct device *dev)
>         if (pdata->power_suspend)
>                 pdata->power_suspend(pdev);
>
> +       ret = reset_control_assert(priv->resets);
> +       if (ret) {
> +               if (pdata->power_on)
> +                       pdata->power_on(pdev);
> +
> +               ohci_resume(hcd, false);

Same comment as previous patch: if the reset_control_assert() failed,
what are the chances that the device will actually work after trying
to bring it up again?

> +       }
> +
>         return ret;
>  }
>

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

[PATCH 4/4] usb: renesas_usbhs: Assert/de-assert reset signals on suspend/resume

[Claudiu]

From: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>

The Renesas RZ/G3S SoC supports a power-saving mode in which power to most
SoC components is turned off, including the USB subsystem.

To properly restore from such a state, the reset signal needs to be
asserted/de-asserted during suspend/resume. Add reset assert/de-assert on
suspend/resume.

The resume code has been moved into a separate function to allow reusing
it in case reset_control_assert() from suspend fails.

Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
---
 drivers/usb/renesas_usbhs/common.c | 35 ++++++++++++++++++++++--------
 1 file changed, 26 insertions(+), 9 deletions(-)

diff --git a/drivers/usb/renesas_usbhs/common.c b/drivers/usb/renesas_usbhs/common.c
index dc2fec9168b7..cf4a0367d6d6 100644
--- a/drivers/usb/renesas_usbhs/common.c
+++ b/drivers/usb/renesas_usbhs/common.c
@@ -827,10 +827,26 @@ static void usbhs_remove(struct platform_device *pdev)
 	pm_runtime_disable(&pdev->dev);
 }
 
+static void usbhsc_restore(struct device *dev)
+{
+	struct usbhs_priv *priv = dev_get_drvdata(dev);
+	struct platform_device *pdev = usbhs_priv_to_pdev(priv);
+
+	if (!usbhs_get_dparam(priv, runtime_pwctrl)) {
+		usbhsc_power_ctrl(priv, 1);
+		usbhs_mod_autonomy_mode(priv);
+	}
+
+	usbhs_platform_call(priv, phy_reset, pdev);
+
+	usbhsc_schedule_notify_hotplug(pdev);
+}
+
 static int usbhsc_suspend(struct device *dev)
 {
 	struct usbhs_priv *priv = dev_get_drvdata(dev);
 	struct usbhs_mod *mod = usbhs_mod_get_current(priv);
+	int ret;
 
 	if (mod) {
 		usbhs_mod_call(priv, stop, priv);
@@ -840,22 +856,23 @@ static int usbhsc_suspend(struct device *dev)
 	if (mod || !usbhs_get_dparam(priv, runtime_pwctrl))
 		usbhsc_power_ctrl(priv, 0);
 
-	return 0;
+	ret = reset_control_assert(priv->rsts);
+	if (ret)
+		usbhsc_restore(dev);
+
+	return ret;
 }
 
 static int usbhsc_resume(struct device *dev)
 {
 	struct usbhs_priv *priv = dev_get_drvdata(dev);
-	struct platform_device *pdev = usbhs_priv_to_pdev(priv);
-
-	if (!usbhs_get_dparam(priv, runtime_pwctrl)) {
-		usbhsc_power_ctrl(priv, 1);
-		usbhs_mod_autonomy_mode(priv);
-	}
+	int ret;
 
-	usbhs_platform_call(priv, phy_reset, pdev);
+	ret = reset_control_deassert(priv->rsts);
+	if (ret)
+		return ret;
 
-	usbhsc_schedule_notify_hotplug(pdev);
+	usbhsc_restore(dev);
 
 	return 0;
 }
-- 
2.43.0