From: sashiko-bot@kernel.org
To: "Sebastian Reichel" <sebastian.reichel@collabora.com>
Cc: olteanv@gmail.com, neil.armstrong@linaro.org, vkoul@kernel.org,
linux-phy@lists.infradead.org
Subject: Re: [PATCH v2 2/4] phy: rockchip: inno-usb2: drop duplicated update of rport->suspended
Date: Thu, 01 Oct 2026 13:23:52 +0000 [thread overview]
Message-ID: <20261001132352.E78DE1F000FF@smtp.kernel.org> (raw)
In-Reply-To: <20261001-phy-rockchip-inno-usb2-clock-fix-v2-2-e01bf509359e@collabora.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] phy: rockchip-inno-usb2: hotplug deadlock if rockchip_usb2phy_power_off() fails
--
commit a2dd4bb2fd5285c3bedf91d080a002423c1e6b40
Author: Sebastian Reichel <sebastian.reichel@collabora.com>
phy: rockchip: inno-usb2: drop duplicated update of rport->suspended
rockchip_usb2phy_power_on and rockchip_usb2phy_power_off already update
rport->suspended in their success path. In case of error it's not
sensible to update rport->suspended. So drop the duplicated update.
> diff --git a/drivers/phy/rockchip/phy-rockchip-inno-usb2.c b/drivers/phy/rockchip/phy-rockchip-inno-usb2.c
> index 0ab054ee84cbe..e4d8abf935c1b 100644
> --- a/drivers/phy/rockchip/phy-rockchip-inno-usb2.c
> +++ b/drivers/phy/rockchip/phy-rockchip-inno-usb2.c
[ ... ]
> @@ -1004,7 +1003,6 @@ static void rockchip_usb2phy_sm_work(struct work_struct *work)
> if (!rport->suspended) {
> dev_dbg(&rport->phy->dev, "Disconnected\n");
> rockchip_usb2phy_power_off(rport->phy);
> - rport->suspended = true;
[Severity: Medium]
If rockchip_usb2phy_power_off() fails, will rport->suspended remain false?
> }
>
> /*
> * activate the linestate detection to get the next device
> * plug-in irq.
> */
> property_enable(rphy->grf, &rport->port_cfg->ls_det_clr, true);
> property_enable(rphy->grf, &rport->port_cfg->ls_det_en, true);
>
> /*
> * we don't need to rearm the delayed work when the phy port
> * is suspended.
> */
> mutex_unlock(&rport->mutex);
> return;
[Severity: Medium]
Since the state machine exits here without re-arming the delayed work, and
rport->suspended could remain false, does this cause a permanent loss of
hotplug detection?
Looking at rockchip_usb2phy_linestate_irq(), the IRQ handler refuses to
re-arm the state machine if the port is not suspended:
static irqreturn_t rockchip_usb2phy_linestate_irq(int irq, void *data)
{
...
if (rport->suspended && rport->port_id == USB2PHY_PORT_HOST)
rockchip_usb2phy_sm_work(&rport->sm_work.work);
return IRQ_HANDLED;
}
If a USB device is disconnected and the underlying regmap_write() fails due
to local hardware or MMIO failure during rockchip_usb2phy_power_off(),
could this result in a hotplug deadlock for the USB host port?
While the code appears intended to handle this error path gracefully, it
seems to inadvertently break the state machine's re-arming condition. This
issue also appears to persist in the final commit of the series.
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261001-phy-rockchip-inno-usb2-clock-fix-v2-0-e01bf509359e@collabora.com?part=2
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
next prev parent reply other threads:[~2026-10-01 13:23 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-01 13:12 [PATCH v2 0/4] phy: rockchip: inno-usb2: ensure PHY is running when clock is requested Sebastian Reichel
2026-10-01 13:12 ` Sebastian Reichel
2026-10-01 13:12 ` Sebastian Reichel
2026-10-01 13:12 ` [PATCH v2 1/4] phy: rockchip: inno-usb2: simplify and unify PHY op debug messages Sebastian Reichel
2026-10-01 13:12 ` Sebastian Reichel
2026-10-01 13:12 ` Sebastian Reichel
2026-10-01 13:12 ` [PATCH v2 2/4] phy: rockchip: inno-usb2: drop duplicated update of rport->suspended Sebastian Reichel
2026-10-01 13:12 ` Sebastian Reichel
2026-10-01 13:12 ` Sebastian Reichel
2026-10-01 13:23 ` sashiko-bot [this message]
2026-10-01 13:12 ` [PATCH v2 3/4] phy: rockchip: inno-usb2: move suspend handling into new function Sebastian Reichel
2026-10-01 13:12 ` Sebastian Reichel
2026-10-01 13:12 ` Sebastian Reichel
2026-10-01 13:21 ` sashiko-bot
2026-10-01 13:12 ` [PATCH v2 4/4] phy: rockchip: inno-usb2: move suspend handling into clock prepare/unprepare for RK3588/RK3576 Sebastian Reichel
2026-10-01 13:12 ` Sebastian Reichel
2026-10-01 13:12 ` Sebastian Reichel
2026-10-01 13:23 ` sashiko-bot
2026-10-01 21:34 ` [PATCH v2 0/4] phy: rockchip: inno-usb2: ensure PHY is running when clock is requested Sebastian Reichel
2026-10-01 21:34 ` Sebastian Reichel
2026-10-01 21:34 ` Sebastian Reichel
2026-10-03 14:33 ` Vinod Koul
2026-10-03 14:33 ` Vinod Koul
2026-10-03 14:33 ` Vinod Koul
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=20261001132352.E78DE1F000FF@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=linux-phy@lists.infradead.org \
--cc=neil.armstrong@linaro.org \
--cc=olteanv@gmail.com \
--cc=sashiko-reviews@lists.linux.dev \
--cc=sebastian.reichel@collabora.com \
--cc=vkoul@kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.