[PATCH for 5.10.y] phy: renesas: rcar-gen3-usb2: Fix the use of msleep during spinlock

[PATCH for 5.10.y] phy: renesas: rcar-gen3-usb2: Fix the use of msleep during spinlock

[Nobuhiro Iwamatsu]

From: Nobuhiro Iwamatsu <iwamatsu@nigauri.org>

This fixes an issue caused by the use of msleep during spinlock.
In the original commit, msleep was changed to mdelay, but this fix was not
carried over during the backport to 5.10.y tree.

This is a backporting error, so no fix is needed in the upstream.

```
[   62.677594] BUG: scheduling while atomic: kworker/1:2/126/0x00000002
[   62.683957] Modules linked in:
[   62.687014] CPU: 1 PID: 126 Comm: kworker/1:2 Not tainted 5.10.253 #1
[   62.693447] Hardware name: HopeRun HiHope RZ/G2M with sub board (DT)
[   62.699812] Workqueue: events deferred_probe_work_func
[   62.704948] Call trace:
[   62.707397]  dump_backtrace+0x0/0x1c0
[   62.711058]  show_stack+0x18/0x40
[   62.714375]  dump_stack+0xe8/0x124
[   62.717776]  __schedule_bug+0x54/0x70
[   62.721436]  __schedule+0x6b4/0x710
[   62.724920]  schedule+0x70/0x104
[   62.728145]  schedule_timeout+0x80/0xf0
[   62.728153]  msleep+0x30/0x44
[   62.728165]  rcar_gen3_phy_usb2_init+0x180/0x1e0
[   62.736946]  phy_init+0x64/0x100
[   62.736955]  usb_phy_roothub_init+0x48/0xa0
[   62.736962]  usb_add_hcd+0x54/0x6c0
[   62.736974]  ehci_platform_probe+0x1ec/0x4b0
[   62.744541]  platform_drv_probe+0x54/0xac
[   62.744548]  really_probe+0xec/0x4f0
[   62.744552]  driver_probe_device+0x58/0xec
[   62.744556]  __device_attach_driver+0xb8/0x120
[   62.744562]  bus_for_each_drv+0x78/0xd0
[   62.744568]  __device_attach+0xa8/0x1c0
[   62.744575]  device_initial_probe+0x14/0x20
[   62.752315]  bus_probe_device+0x9c/0xa4
[   62.752319]  deferred_probe_work_func+0x88/0xc0
[   62.752327]  process_one_work+0x1cc/0x370
[   62.759977]  worker_thread+0x218/0x480
[   62.759984]  kthread+0x154/0x160
[   62.759990]  ret_from_fork+0x10/0x18
[   62.760115] ehci-platform ee080100.usb: EHCI Host Controller
[   62.839982] ehci-platform ee080100.usb: new USB bus registered, assigned bus number 3
```

Fixes: 0f86a559900f ("phy: renesas: rcar-gen3-usb2: Lock around hardware registers and driver data")
Cc: stable@vger.kernel.org
Cc: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
Cc: Sasha Levin <sashal@kernel.org>
Signed-off-by: Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
---

 drivers/phy/renesas/phy-rcar-gen3-usb2.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/phy/renesas/phy-rcar-gen3-usb2.c b/drivers/phy/renesas/phy-rcar-gen3-usb2.c
index 5166a115879ea..90f2a0e5b2aa0 100644
--- a/drivers/phy/renesas/phy-rcar-gen3-usb2.c
+++ b/drivers/phy/renesas/phy-rcar-gen3-usb2.c
@@ -386,7 +386,7 @@ static void rcar_gen3_init_otg(struct rcar_gen3_chan *ch)
 	val = readl(usb2_base + USB2_ADPCTRL);
 	writel(val | USB2_ADPCTRL_IDPULLUP, usb2_base + USB2_ADPCTRL);
 
-	msleep(20);
+	mdelay(20);
 
 	writel(0xffffffff, usb2_base + USB2_OBINTSTA);
 	writel(USB2_OBINT_BITS, usb2_base + USB2_OBINTEN);
-- 
2.53.0

Re: [cip-dev] [PATCH for 5.10.y] phy: renesas: rcar-gen3-usb2: Fix the use of msleep during spinlock

[Pavel Machek]

[-- Attachment #1: Type: text/plain, Size: 1379 bytes --]

Hi!

> From: Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
> 
> This fixes an issue caused by the use of msleep during spinlock.
> In the original commit, msleep was changed to mdelay, but this fix was not
> carried over during the backport to 5.10.y tree.

Doing this as a quick fix is probably okay, but this should not be
final version.

You are right that msleep inside spinlock will blow up immediately:

> ```
> [   62.677594] BUG: scheduling while atomic: kworker/1:2/126/0x00000002
> [   62.683957] Modules linked in:

But mdelay for 20 msec inside irqsave spinlock is borderline
unacceptable, too.

I believe we'll need Renesas to analyze/fix this properly after the
CVE emergency is done.

This fix is good for now, but better fix is needed.

Claudiu, are you right person for this, or should we cc someone else?

Best regards,
								Pavel


> index 5166a115879ea..90f2a0e5b2aa0 100644
> --- a/drivers/phy/renesas/phy-rcar-gen3-usb2.c
> +++ b/drivers/phy/renesas/phy-rcar-gen3-usb2.c
> @@ -386,7 +386,7 @@ static void rcar_gen3_init_otg(struct rcar_gen3_chan *ch)
>  	val = readl(usb2_base + USB2_ADPCTRL);
>  	writel(val | USB2_ADPCTRL_IDPULLUP, usb2_base + USB2_ADPCTRL);
>  
> -	msleep(20);
> +	mdelay(20);
>  
>  	writel(0xffffffff, usb2_base + USB2_OBINTSTA);
>  	writel(USB2_OBINT_BITS, usb2_base + USB2_OBINTEN);


-- 

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: [cip-dev] [PATCH for 5.10.y] phy: renesas: rcar-gen3-usb2: Fix the use of msleep during spinlock

[Nobuhiro Iwamatsu]

Hi Pavel,

2026年5月4日(月) 18:18 Pavel Machek via lists.cip-project.org
<pavel=nabladev.com@lists.cip-project.org>:
>
> Hi!
>
> > From: Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
> >
> > This fixes an issue caused by the use of msleep during spinlock.
> > In the original commit, msleep was changed to mdelay, but this fix was not
> > carried over during the backport to 5.10.y tree.
>
> Doing this as a quick fix is probably okay, but this should not be
> final version.
>
> You are right that msleep inside spinlock will blow up immediately:
>
> > ```
> > [   62.677594] BUG: scheduling while atomic: kworker/1:2/126/0x00000002
> > [   62.683957] Modules linked in:
>
> But mdelay for 20 msec inside irqsave spinlock is borderline
> unacceptable, too.

Thanks for pointing that out.
You’re absolutely right.
I had completely forgotten about that....

>
> I believe we'll need Renesas to analyze/fix this properly after the
> CVE emergency is done.
>
> This fix is good for now, but better fix is needed.
>
> Claudiu, are you right person for this, or should we cc someone else?
>
> Best regards,
>                                                                 Pavel

Best regards,
  Nouhiro
-- 
Nobuhiro Iwamatsu

Re: [cip-dev] [PATCH for 5.10.y] phy: renesas: rcar-gen3-usb2: Fix the use of msleep during spinlock

[Claudiu Beznea]

Hi, all,

On 5/4/26 12:18, Pavel Machek via lists.cip-project.org wrote:
> Hi!
> 
>> From: Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
>>
>> This fixes an issue caused by the use of msleep during spinlock.
>> In the original commit, msleep was changed to mdelay, but this fix was not
>> carried over during the backport to 5.10.y tree.
> 
> Doing this as a quick fix is probably okay, but this should not be
> final version.
> 
> You are right that msleep inside spinlock will blow up immediately:
> 
>> ```
>> [   62.677594] BUG: scheduling while atomic: kworker/1:2/126/0x00000002
>> [   62.683957] Modules linked in:
> 
> But mdelay for 20 msec inside irqsave spinlock is borderline
> unacceptable, too.
> 
> I believe we'll need Renesas to analyze/fix this properly after the
> CVE emergency is done.
> 
> This fix is good for now, but better fix is needed.
> 
> Claudiu, are you right person for this, or should we cc someone else?

I'm going to investigate and come with a better approach for this.

Thank you and apologies for any inconveniences,
Claudiu

Re: [cip-dev] [PATCH for 5.10.y] phy: renesas: rcar-gen3-usb2: Fix the use of msleep during spinlock

[Claudiu Beznea]

On 5/5/26 11:40, Claudiu Beznea wrote:
> Hi, all,
> 
> On 5/4/26 12:18, Pavel Machek via lists.cip-project.org wrote:
>> Hi!
>>
>>> From: Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
>>>
>>> This fixes an issue caused by the use of msleep during spinlock.
>>> In the original commit, msleep was changed to mdelay, but this fix was not
>>> carried over during the backport to 5.10.y tree.
>>
>> Doing this as a quick fix is probably okay, but this should not be
>> final version.
>>
>> You are right that msleep inside spinlock will blow up immediately:
>>
>>> ```
>>> [   62.677594] BUG: scheduling while atomic: kworker/1:2/126/0x00000002
>>> [   62.683957] Modules linked in:
>>
>> But mdelay for 20 msec inside irqsave spinlock is borderline
>> unacceptable, too.
>>
>> I believe we'll need Renesas to analyze/fix this properly after the
>> CVE emergency is done.
>>
>> This fix is good for now, but better fix is needed.
>>
>> Claudiu, are you right person for this, or should we cc someone else?
> 
> I'm going to investigate and come with a better approach for this.

On a second thought, the proper fix would have to go to upstream first. To fix 
the problem currently seen, could we integrate this patch as is?

Thank you,
Claudiu

Re: [cip-dev] [PATCH for 5.10.y] phy: renesas: rcar-gen3-usb2: Fix the use of msleep during spinlock

[Greg KH]

On Tue, May 05, 2026 at 11:49:24AM +0300, Claudiu Beznea wrote:
> 
> 
> On 5/5/26 11:40, Claudiu Beznea wrote:
> > Hi, all,
> > 
> > On 5/4/26 12:18, Pavel Machek via lists.cip-project.org wrote:
> > > Hi!
> > > 
> > > > From: Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
> > > > 
> > > > This fixes an issue caused by the use of msleep during spinlock.
> > > > In the original commit, msleep was changed to mdelay, but this fix was not
> > > > carried over during the backport to 5.10.y tree.
> > > 
> > > Doing this as a quick fix is probably okay, but this should not be
> > > final version.
> > > 
> > > You are right that msleep inside spinlock will blow up immediately:
> > > 
> > > > ```
> > > > [   62.677594] BUG: scheduling while atomic: kworker/1:2/126/0x00000002
> > > > [   62.683957] Modules linked in:
> > > 
> > > But mdelay for 20 msec inside irqsave spinlock is borderline
> > > unacceptable, too.
> > > 
> > > I believe we'll need Renesas to analyze/fix this properly after the
> > > CVE emergency is done.
> > > 
> > > This fix is good for now, but better fix is needed.
> > > 
> > > Claudiu, are you right person for this, or should we cc someone else?
> > 
> > I'm going to investigate and come with a better approach for this.
> 
> On a second thought, the proper fix would have to go to upstream first. To
> fix the problem currently seen, could we integrate this patch as is?

No, please work upstream first.

Re: [cip-dev] [PATCH for 5.10.y] phy: renesas: rcar-gen3-usb2: Fix the use of msleep during spinlock

[Pavel Machek]

[-- Attachment #1: Type: text/plain, Size: 2074 bytes --]

Hi!

> > > > > From: Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
> > > > > 
> > > > > This fixes an issue caused by the use of msleep during spinlock.
> > > > > In the original commit, msleep was changed to mdelay, but this fix was not
> > > > > carried over during the backport to 5.10.y tree.
> > > > 
> > > > Doing this as a quick fix is probably okay, but this should not be
> > > > final version.
> > > > 
> > > > You are right that msleep inside spinlock will blow up immediately:
> > > > 
> > > > > ```
> > > > > [   62.677594] BUG: scheduling while atomic: kworker/1:2/126/0x00000002
> > > > > [   62.683957] Modules linked in:
> > > > 
> > > > But mdelay for 20 msec inside irqsave spinlock is borderline
> > > > unacceptable, too.
...
> > > I'm going to investigate and come with a better approach for this.
> > 
> > On a second thought, the proper fix would have to go to upstream first. To
> > fix the problem currently seen, could we integrate this patch as is?
> 
> No, please work upstream first.

Upstream has the mdelay:

drivers/phy/renesas/phy-rcar-gen3-usb2.c in rcar_gen3_init_otg() --
mdelay(20) and has the spinlock,

static int rcar_gen3_phy_usb2_init(struct phy *p)
{
	...
        guard(spinlock_irqsave)(&channel->lock);
	...
        /* Initialize otg part (only if we initialize a PHY with IRQs). */
        if (rphy->int_enable_bits)
                rcar_gen3_init_otg(channel);


So what Iwamatsu-san's patch matches upstream, and is good solution
for -stable for now. I have just pointed out, that, well, mdelay(20)
inside a spinlock is not great.

7.1-rc2: mdelay inside spinlock -- not great

5.10.250: msleep but no spinlock -- missing locking, bad!

5.10.254: msleep inside spinlock -- fails to boot, bad, bad, BAD! (and
also regression from 5.10.250).

Please allow Iwamatsu-san / Renesas to get this to 7.1 level of "not
great" situation; Claudiu will work with upstream to get 7.1 to "good"
situation, and then we can thing about backports.

Thanks and best regards,
								Pavel

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]