From: Shawn Guo <shawnguo2@yeah.net>
To: Xu Yang <xu.yang_2@nxp.com>
Cc: Peter Chen <peter.chen@kernel.org>,
Shawn Guo <shawnguo@kernel.org>,
imx@lists.linux.dev, linux-usb@vger.kernel.org,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
Subject: Re: i.MX kernel hangup caused by chipidea USB gadget driver
Date: Tue, 10 Jun 2025 17:50:19 +0800 [thread overview]
Message-ID: <aEf/2+3MU5ED2sxE@dragon> (raw)
In-Reply-To: <c56pgxmfscg6tpqxjayu4mvxc2g5kgmfitpvp36lxulpq4jxmg@ces5l7ofab6s>
On Mon, Jun 09, 2025 at 07:53:22PM +0800, Xu Yang wrote:
<snip>
> During the scp process, the usb host won't put usb device to suspend state.
> In current design, then the ether driver doesn't know the system has
> suspended after echo mem. The root cause is that ether driver is still tring
> to queue usb request after usb controller has suspended where usb clock is off,
> then the system hang.
>
> With the above changes, I think the ether driver will fail to eth_start_xmit()
> at an ealier stage, so the issue can't be triggered.
>
> I think the ether driver needs call gether_suspend() accordingly, to do this,
> the controller driver need explicitly call suspend() function when it's going
> to be suspended. Could you check whether below patch fix the issue?
Thanks for the patch, Xu! It does fix the hangup but seems to be less
reliable than my/Peter's change (disconnecting gadget), per my testing
on a custom i.MX8MM board. With your change, host/PC doesn't disconnect
gadget when the board suspends. After a few suspend cycles, Ethernet
gadget stops working and the following workqueue lockup is seen. There
seems to some be other bugs?
[ 223.047990] rcu: INFO: rcu_preempt detected stalls on CPUs/tasks:
[ 223.054097] rcu: 1-...0: (7 ticks this GP) idle=bb7c/1/0x4000000000000000 softirq=5368/5370 fqs=2431
[ 223.063318] rcu: (detected by 0, t=5252 jiffies, g=4705, q=2400 ncpus=4)
[ 223.070105] Task dump for CPU 1:
[ 223.073330] task:systemd-network state:R running task stack:0 pid:406 ppid:1 flags:0x00000202
[ 223.083248] Call trace:
[ 223.085692] __switch_to+0xc0/0x124
[ 246.747996] BUG: workqueue lockup - pool cpus=1 node=0 flags=0x0 nice=0 stuck for 43s!
However, your change seems working fine on i.MX8MM EVK. It's probably
due to the fact that host disconnects gadget for some reason when EVK
suspends. This is a different behavior from the custom board above.
We do not really expect this disconnecting, do we?
Shawn
> ---8<--------------------
>
> diff --git a/drivers/usb/chipidea/udc.c b/drivers/usb/chipidea/udc.c
> index 8a9b31fd5c89..27a7674ed62c 100644
> --- a/drivers/usb/chipidea/udc.c
> +++ b/drivers/usb/chipidea/udc.c
> @@ -2367,6 +2367,8 @@ static void udc_id_switch_for_host(struct ci_hdrc *ci)
> #ifdef CONFIG_PM_SLEEP
> static void udc_suspend(struct ci_hdrc *ci)
> {
> + ci->driver->suspend(&ci->gadget);
> +
> /*
> * Set OP_ENDPTLISTADDR to be non-zero for
> * checking if controller resume from power lost
> @@ -2389,6 +2391,8 @@ static void udc_resume(struct ci_hdrc *ci, bool power_lost)
> /* Restore value 0 if it was set for power lost check */
> if (hw_read(ci, OP_ENDPTLISTADDR, ~0) == 0xFFFFFFFF)
> hw_write(ci, OP_ENDPTLISTADDR, ~0, 0);
> +
> + ci->driver->resume(&ci->gadget);
> }
> #endif
>
> ---->8------------------
next prev parent reply other threads:[~2025-06-10 10:56 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-06-09 5:31 i.MX kernel hangup caused by chipidea USB gadget driver Shawn Guo
2025-06-09 11:53 ` Xu Yang
2025-06-09 13:54 ` Alan Stern
2025-06-10 10:08 ` Shawn Guo
2025-06-10 11:27 ` Xu Yang
2025-06-09 14:17 ` John Ernberg
2025-06-10 2:12 ` Peter Chen (CIX)
2025-06-10 10:17 ` Shawn Guo
2025-06-10 11:33 ` Xu Yang
2025-06-10 3:04 ` Shawn Guo
2025-06-10 15:03 ` John Ernberg
2025-06-10 11:30 ` Xu Yang
2025-06-10 15:05 ` John Ernberg
2025-06-12 13:23 ` John Ernberg
2025-06-13 3:13 ` Xu Yang
2025-06-10 9:50 ` Shawn Guo [this message]
2025-06-10 11:54 ` Xu Yang
2025-06-11 2:59 ` Shawn Guo
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aEf/2+3MU5ED2sxE@dragon \
--to=shawnguo2@yeah.net \
--cc=imx@lists.linux.dev \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=peter.chen@kernel.org \
--cc=shawnguo@kernel.org \
--cc=xu.yang_2@nxp.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox