From: sashiko-bot@kernel.org
To: "Sebastian Reichel" <sebastian.reichel@collabora.com>
Cc: robh@kernel.org, conor+dt@kernel.org, devicetree@vger.kernel.org,
vkoul@kernel.org, olteanv@gmail.com,
linux-phy@lists.infradead.org, neil.armstrong@linaro.org
Subject: Re: [PATCH v14 10/38] phy: rockchip: usbdp: Add missing mode_change update
Date: Fri, 14 Aug 2026 02:41:50 +0000 [thread overview]
Message-ID: <20260814024151.31F801F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260813-rockchip-usbdp-cleanup-v14-10-b5ad9c68fa11@collabora.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
Pre-existing issues:
- [High] Type-C state fallback to USB/Safe modes skips the PHY mode update and HPD reset, permanently breaking USB 3.0 and leaving a ghost DisplayPort connection.
- [High] The PHY driver indefinitely leaks active power states (clocks and resets) if the Type-C mux mode changes before the USB or DP controllers execute their teardown routines.
--
--- Patch [10]: [PATCH v14 10/38] phy: rockchip: usbdp: Add missing mode_change update ---
commit 9bed4fa08dd116716a39f228bdd961c66a8f8b64
Author: Sebastian Reichel <sebastian.reichel@collabora.com>
phy: rockchip: usbdp: Add missing mode_change update
rk_udphy_set_typec_default_mapping() updates the available modes,
but does not set the mode_change as required. This results in
missing re-initialization and thus non-working DisplayPort.
> diff --git a/drivers/phy/rockchip/phy-rockchip-usbdp.c b/drivers/phy/rockchip/phy-rockchip-usbdp.c
> index 982315535caf7..7540c897dde13 100644
> --- a/drivers/phy/rockchip/phy-rockchip-usbdp.c
> +++ b/drivers/phy/rockchip/phy-rockchip-usbdp.c
> @@ -617,6 +617,15 @@ static void rk_udphy_dp_hpd_event_trigger(struct rk_udphy *udphy, bool hpd)
> rk_udphy_grfreg_write(udphy->vogrf, &cfg->vogrfcfg[udphy->id].hpd_trigger, hpd);
> }
>
> +static void rk_udphy_mode_set(struct rk_udphy *udphy, u8 mode)
> +{
> + if (udphy->mode == mode)
> + return;
> +
> + udphy->mode_change = true;
> + udphy->mode = mode;
> +}
[Severity: High]
This isn't a bug introduced by this patch, but since we are updating how the
mode is set, can this asynchronous update to udphy->mode lead to a power state
leak?
If the Type-C subsystem asynchronously updates the requested mode via
rk_udphy_typec_mux_set() (e.g., changing from UDPHY_MODE_DP_USB to
UDPHY_MODE_DP), does this cause later teardown routines to fail?
For example, when the USB controller suspends and calls phy_exit() or
phy_power_off(), routines like rk_udphy_usb3_phy_exit() check the mode:
drivers/phy/rockchip/phy-rockchip-usbdp.c:rk_udphy_usb3_phy_exit() {
...
/* DP only or high-speed */
if (!(udphy->mode & UDPHY_MODE_USB) || udphy->hs)
goto unlock;
...
}
Similarly in rk_udphy_power_off():
drivers/phy/rockchip/phy-rockchip-usbdp.c:rk_udphy_power_off() {
...
if (!(udphy->mode & mode)) {
dev_info(udphy->dev, "mode 0x%02x is not support\n", mode);
return;
}
...
}
Because udphy->mode has already changed, do these functions return early
without clearing the USB bit from udphy->status, leaving active hardware
clocks and resets leaked indefinitely?
[ ... ]
> @@ -1361,10 +1370,7 @@ static int rk_udphy_typec_mux_set(struct typec_mux_dev *mux,
> usleep_range(750, 800);
> rk_udphy_dp_hpd_event_trigger(udphy, true);
> } else if (data->status & DP_STATUS_HPD_STATE) {
> - if (udphy->mode != mode) {
> - udphy->mode = mode;
> - udphy->mode_change = true;
> - }
> + rk_udphy_mode_set(udphy, mode);
> rk_udphy_dp_hpd_event_trigger(udphy, true);
> } else {
> rk_udphy_dp_hpd_event_trigger(udphy, false);
[Severity: High]
This is a pre-existing issue, but I have a question about the broader logic
in rk_udphy_typec_mux_set() when the mode changes.
When the Type-C port exits Alt Mode to a safe or USB-only state, does this
skip the PHY mode update and HPD reset entirely?
It looks like the vital state updates (including the new rk_udphy_mode_set()
call) are gated behind an earlier check in rk_udphy_typec_mux_set():
drivers/phy/rockchip/phy-rockchip-usbdp.c:rk_udphy_typec_mux_set() {
...
if (state->alt && state->alt->svid == USB_TYPEC_DP_SID) {
struct typec_displayport_data *data = state->data;
...
}
Because state->alt is NULL when exiting DisplayPort Alt Mode, this block is
bypassed. Can this leave udphy->mode stuck in UDPHY_MODE_DP, potentially
breaking USB 3.0 functionality and leaving a ghost DisplayPort connection?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260813-rockchip-usbdp-cleanup-v14-0-b5ad9c68fa11@collabora.com?part=10
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
WARNING: multiple messages have this Message-ID (diff)
From: sashiko-bot@kernel.org
To: "Sebastian Reichel" <sebastian.reichel@collabora.com>
Cc: robh@kernel.org, conor+dt@kernel.org, devicetree@vger.kernel.org,
vkoul@kernel.org, olteanv@gmail.com,
linux-phy@lists.infradead.org, neil.armstrong@linaro.org
Subject: Re: [PATCH v14 10/38] phy: rockchip: usbdp: Add missing mode_change update
Date: Fri, 14 Aug 2026 02:41:50 +0000 [thread overview]
Message-ID: <20260814024151.31F801F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260813-rockchip-usbdp-cleanup-v14-10-b5ad9c68fa11@collabora.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
Pre-existing issues:
- [High] Type-C state fallback to USB/Safe modes skips the PHY mode update and HPD reset, permanently breaking USB 3.0 and leaving a ghost DisplayPort connection.
- [High] The PHY driver indefinitely leaks active power states (clocks and resets) if the Type-C mux mode changes before the USB or DP controllers execute their teardown routines.
--
--- Patch [10]: [PATCH v14 10/38] phy: rockchip: usbdp: Add missing mode_change update ---
commit 9bed4fa08dd116716a39f228bdd961c66a8f8b64
Author: Sebastian Reichel <sebastian.reichel@collabora.com>
phy: rockchip: usbdp: Add missing mode_change update
rk_udphy_set_typec_default_mapping() updates the available modes,
but does not set the mode_change as required. This results in
missing re-initialization and thus non-working DisplayPort.
> diff --git a/drivers/phy/rockchip/phy-rockchip-usbdp.c b/drivers/phy/rockchip/phy-rockchip-usbdp.c
> index 982315535caf7..7540c897dde13 100644
> --- a/drivers/phy/rockchip/phy-rockchip-usbdp.c
> +++ b/drivers/phy/rockchip/phy-rockchip-usbdp.c
> @@ -617,6 +617,15 @@ static void rk_udphy_dp_hpd_event_trigger(struct rk_udphy *udphy, bool hpd)
> rk_udphy_grfreg_write(udphy->vogrf, &cfg->vogrfcfg[udphy->id].hpd_trigger, hpd);
> }
>
> +static void rk_udphy_mode_set(struct rk_udphy *udphy, u8 mode)
> +{
> + if (udphy->mode == mode)
> + return;
> +
> + udphy->mode_change = true;
> + udphy->mode = mode;
> +}
[Severity: High]
This isn't a bug introduced by this patch, but since we are updating how the
mode is set, can this asynchronous update to udphy->mode lead to a power state
leak?
If the Type-C subsystem asynchronously updates the requested mode via
rk_udphy_typec_mux_set() (e.g., changing from UDPHY_MODE_DP_USB to
UDPHY_MODE_DP), does this cause later teardown routines to fail?
For example, when the USB controller suspends and calls phy_exit() or
phy_power_off(), routines like rk_udphy_usb3_phy_exit() check the mode:
drivers/phy/rockchip/phy-rockchip-usbdp.c:rk_udphy_usb3_phy_exit() {
...
/* DP only or high-speed */
if (!(udphy->mode & UDPHY_MODE_USB) || udphy->hs)
goto unlock;
...
}
Similarly in rk_udphy_power_off():
drivers/phy/rockchip/phy-rockchip-usbdp.c:rk_udphy_power_off() {
...
if (!(udphy->mode & mode)) {
dev_info(udphy->dev, "mode 0x%02x is not support\n", mode);
return;
}
...
}
Because udphy->mode has already changed, do these functions return early
without clearing the USB bit from udphy->status, leaving active hardware
clocks and resets leaked indefinitely?
[ ... ]
> @@ -1361,10 +1370,7 @@ static int rk_udphy_typec_mux_set(struct typec_mux_dev *mux,
> usleep_range(750, 800);
> rk_udphy_dp_hpd_event_trigger(udphy, true);
> } else if (data->status & DP_STATUS_HPD_STATE) {
> - if (udphy->mode != mode) {
> - udphy->mode = mode;
> - udphy->mode_change = true;
> - }
> + rk_udphy_mode_set(udphy, mode);
> rk_udphy_dp_hpd_event_trigger(udphy, true);
> } else {
> rk_udphy_dp_hpd_event_trigger(udphy, false);
[Severity: High]
This is a pre-existing issue, but I have a question about the broader logic
in rk_udphy_typec_mux_set() when the mode changes.
When the Type-C port exits Alt Mode to a safe or USB-only state, does this
skip the PHY mode update and HPD reset entirely?
It looks like the vital state updates (including the new rk_udphy_mode_set()
call) are gated behind an earlier check in rk_udphy_typec_mux_set():
drivers/phy/rockchip/phy-rockchip-usbdp.c:rk_udphy_typec_mux_set() {
...
if (state->alt && state->alt->svid == USB_TYPEC_DP_SID) {
struct typec_displayport_data *data = state->data;
...
}
Because state->alt is NULL when exiting DisplayPort Alt Mode, this block is
bypassed. Can this leave udphy->mode stuck in UDPHY_MODE_DP, potentially
breaking USB 3.0 functionality and leaving a ghost DisplayPort connection?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260813-rockchip-usbdp-cleanup-v14-0-b5ad9c68fa11@collabora.com?part=10
next prev parent reply other threads:[~2026-08-14 2:41 UTC|newest]
Thread overview: 155+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-13 20:51 [PATCH v14 00/38] phy: rockchip: usbdp: Clean up the mess Sebastian Reichel
2026-08-13 20:51 ` Sebastian Reichel
2026-08-13 20:51 ` Sebastian Reichel
2026-08-13 20:51 ` [PATCH v14 01/38] dt-bindings: phy: rockchip-usbdp: add improved ports scheme Sebastian Reichel
2026-08-13 20:51 ` Sebastian Reichel
2026-08-13 20:51 ` Sebastian Reichel
2026-08-13 20:51 ` [PATCH v14 02/38] phy: rockchip: usbdp: Update mode_change after error handling Sebastian Reichel
2026-08-13 20:51 ` Sebastian Reichel
2026-08-13 20:51 ` Sebastian Reichel
2026-08-14 1:19 ` sashiko-bot
2026-08-14 1:19 ` sashiko-bot
2026-08-13 20:51 ` [PATCH v14 03/38] phy: rockchip: usbdp: Do not lose USB3 PHY status Sebastian Reichel
2026-08-13 20:51 ` Sebastian Reichel
2026-08-13 20:51 ` Sebastian Reichel
2026-08-14 1:33 ` sashiko-bot
2026-08-14 1:33 ` sashiko-bot
2026-08-13 20:51 ` [PATCH v14 04/38] phy: rockchip: usbdp: Fix devm_clk_bulk_get_all check Sebastian Reichel
2026-08-13 20:51 ` Sebastian Reichel
2026-08-13 20:51 ` Sebastian Reichel
2026-08-14 1:41 ` sashiko-bot
2026-08-14 1:41 ` sashiko-bot
2026-08-13 20:51 ` [PATCH v14 05/38] phy: rockchip: usbdp: Handle missing clock-names DT property gracefully Sebastian Reichel
2026-08-13 20:51 ` Sebastian Reichel
2026-08-13 20:51 ` Sebastian Reichel
2026-08-14 1:53 ` sashiko-bot
2026-08-14 1:53 ` sashiko-bot
2026-08-13 20:51 ` [PATCH v14 06/38] phy: rockchip: usbdp: Drop seamless DP takeover Sebastian Reichel
2026-08-13 20:51 ` Sebastian Reichel
2026-08-13 20:51 ` Sebastian Reichel
2026-08-14 2:06 ` sashiko-bot
2026-08-14 2:06 ` sashiko-bot
2026-08-13 20:51 ` [PATCH v14 07/38] phy: rockchip: usbdp: Keep clocks running on PHY re-init Sebastian Reichel
2026-08-13 20:51 ` Sebastian Reichel
2026-08-13 20:51 ` Sebastian Reichel
2026-08-14 2:16 ` sashiko-bot
2026-08-14 2:16 ` sashiko-bot
2026-08-13 20:51 ` [PATCH v14 08/38] phy: rockchip: usbdp: Amend SSC modulation deviation Sebastian Reichel
2026-08-13 20:51 ` Sebastian Reichel
2026-08-13 20:51 ` Sebastian Reichel
2026-08-13 20:51 ` [PATCH v14 09/38] phy: rockchip: usbdp: Fix LFPS detect threshold control Sebastian Reichel
2026-08-13 20:51 ` Sebastian Reichel
2026-08-13 20:51 ` Sebastian Reichel
2026-08-13 20:51 ` [PATCH v14 10/38] phy: rockchip: usbdp: Add missing mode_change update Sebastian Reichel
2026-08-13 20:51 ` Sebastian Reichel
2026-08-13 20:51 ` Sebastian Reichel
2026-08-14 2:41 ` sashiko-bot [this message]
2026-08-14 2:41 ` sashiko-bot
2026-08-13 20:51 ` [PATCH v14 11/38] phy: rockchip: usbdp: Support single-lane DP Sebastian Reichel
2026-08-13 20:51 ` Sebastian Reichel
2026-08-13 20:51 ` Sebastian Reichel
2026-08-14 2:55 ` sashiko-bot
2026-08-14 2:55 ` sashiko-bot
2026-08-13 20:51 ` [PATCH v14 12/38] phy: rockchip: usbdp: Limit DP lane count to muxed lanes Sebastian Reichel
2026-08-13 20:51 ` Sebastian Reichel
2026-08-13 20:51 ` Sebastian Reichel
2026-08-14 3:07 ` sashiko-bot
2026-08-14 3:07 ` sashiko-bot
2026-08-13 20:51 ` [PATCH v14 13/38] phy: rockchip: usbdp: Rename DP lane functions Sebastian Reichel
2026-08-13 20:51 ` Sebastian Reichel
2026-08-13 20:51 ` Sebastian Reichel
2026-08-13 20:51 ` [PATCH v14 14/38] phy: rockchip: usbdp: Use FIELD_PREP_WM16_CONST Sebastian Reichel
2026-08-13 20:51 ` Sebastian Reichel
2026-08-13 20:51 ` Sebastian Reichel
2026-08-13 20:51 ` [PATCH v14 15/38] phy: rockchip: usbdp: Cleanup DP lane selection function Sebastian Reichel
2026-08-13 20:51 ` Sebastian Reichel
2026-08-13 20:51 ` Sebastian Reichel
2026-08-13 20:51 ` [PATCH v14 16/38] phy: rockchip: usbdp: Register DP aux bridge Sebastian Reichel
2026-08-13 20:51 ` Sebastian Reichel
2026-08-13 20:51 ` Sebastian Reichel
2026-08-13 20:52 ` [PATCH v14 17/38] phy: rockchip: usbdp: Drop DP HPD handling Sebastian Reichel
2026-08-13 20:52 ` Sebastian Reichel
2026-08-13 20:52 ` Sebastian Reichel
2026-08-13 20:52 ` [PATCH v14 18/38] phy: rockchip: usbdp: Rename mode_change to phy_needs_reinit Sebastian Reichel
2026-08-13 20:52 ` Sebastian Reichel
2026-08-13 20:52 ` Sebastian Reichel
2026-08-13 20:52 ` [PATCH v14 19/38] phy: rockchip: usbdp: Re-init the PHY on orientation change Sebastian Reichel
2026-08-13 20:52 ` Sebastian Reichel
2026-08-13 20:52 ` Sebastian Reichel
2026-08-14 3:57 ` sashiko-bot
2026-08-14 3:57 ` sashiko-bot
2026-08-13 20:52 ` [PATCH v14 20/38] phy: rockchip: usbdp: Factor out lane_mux_sel setup Sebastian Reichel
2026-08-13 20:52 ` Sebastian Reichel
2026-08-13 20:52 ` Sebastian Reichel
2026-08-14 4:10 ` sashiko-bot
2026-08-14 4:10 ` sashiko-bot
2026-08-13 20:52 ` [PATCH v14 21/38] phy: rockchip: usbdp: Properly handle TYPEC_STATE_SAFE and TYPEC_STATE_USB Sebastian Reichel
2026-08-13 20:52 ` Sebastian Reichel
2026-08-13 20:52 ` Sebastian Reichel
2026-08-14 4:23 ` sashiko-bot
2026-08-14 4:23 ` sashiko-bot
2026-08-13 20:52 ` [PATCH v14 22/38] phy: rockchip: usbdp: Use guard functions for mutex Sebastian Reichel
2026-08-13 20:52 ` Sebastian Reichel
2026-08-13 20:52 ` Sebastian Reichel
2026-08-13 20:52 ` [PATCH v14 23/38] phy: rockchip: usbdp: Hold mutex in DP PHY configure Sebastian Reichel
2026-08-13 20:52 ` Sebastian Reichel
2026-08-13 20:52 ` Sebastian Reichel
2026-08-13 20:52 ` [PATCH v14 24/38] phy: rockchip: usbdp: Add some extra debug messages Sebastian Reichel
2026-08-13 20:52 ` Sebastian Reichel
2026-08-13 20:52 ` Sebastian Reichel
2026-08-13 20:52 ` [PATCH v14 25/38] phy: rockchip: usbdp: Avoid xHCI SErrors Sebastian Reichel
2026-08-13 20:52 ` Sebastian Reichel
2026-08-13 20:52 ` Sebastian Reichel
2026-08-14 4:52 ` sashiko-bot
2026-08-14 4:52 ` sashiko-bot
2026-08-13 20:52 ` [PATCH v14 26/38] phy: rockchip: usbdp: Handle rk_udphy_reset_deassert errors Sebastian Reichel
2026-08-13 20:52 ` Sebastian Reichel
2026-08-13 20:52 ` Sebastian Reichel
2026-08-13 20:52 ` [PATCH v14 27/38] phy: rockchip: usbdp: Only enable USB3 when not in high-speed mode Sebastian Reichel
2026-08-13 20:52 ` Sebastian Reichel
2026-08-13 20:52 ` Sebastian Reichel
2026-08-13 20:52 ` [PATCH v14 28/38] phy: core: add notifier infrastructure Sebastian Reichel
2026-08-13 20:52 ` Sebastian Reichel
2026-08-13 20:52 ` Sebastian Reichel
2026-08-14 5:14 ` sashiko-bot
2026-08-14 5:14 ` sashiko-bot
2026-08-13 20:52 ` [PATCH v14 29/38] usb: dwc3: rockchip: introduce glue driver Sebastian Reichel
2026-08-13 20:52 ` Sebastian Reichel
2026-08-13 20:52 ` Sebastian Reichel
2026-08-14 5:22 ` sashiko-bot
2026-08-14 5:22 ` sashiko-bot
2026-08-13 20:52 ` [PATCH v14 30/38] usb: dwc3: core: add post PHY registration hook for platform glue Sebastian Reichel
2026-08-13 20:52 ` Sebastian Reichel
2026-08-13 20:52 ` Sebastian Reichel
2026-08-13 20:52 ` [PATCH v14 31/38] usb: dwc3: rockchip: support PHY reset notifications Sebastian Reichel
2026-08-13 20:52 ` Sebastian Reichel
2026-08-13 20:52 ` Sebastian Reichel
2026-08-14 5:43 ` sashiko-bot
2026-08-14 5:43 ` sashiko-bot
2026-08-13 20:52 ` [PATCH v14 32/38] usb: dwc3: rockchip: fix USB-C reconnect in gadget mode Sebastian Reichel
2026-08-13 20:52 ` Sebastian Reichel
2026-08-13 20:52 ` Sebastian Reichel
2026-08-14 5:59 ` sashiko-bot
2026-08-14 5:59 ` sashiko-bot
2026-08-13 20:52 ` [PATCH v14 33/38] phy: rockchip: usbdp: Add phy reset notification support Sebastian Reichel
2026-08-13 20:52 ` Sebastian Reichel
2026-08-13 20:52 ` Sebastian Reichel
2026-08-14 6:12 ` sashiko-bot
2026-08-14 6:12 ` sashiko-bot
2026-08-13 20:52 ` [PATCH v14 34/38] phy: rockchip: usbdp: Drop -EPROBE_DEFER hack Sebastian Reichel
2026-08-13 20:52 ` Sebastian Reichel
2026-08-13 20:52 ` Sebastian Reichel
2026-08-13 20:52 ` [PATCH v14 35/38] phy: rockchip: usbdp: Rename mode to hw_mode Sebastian Reichel
2026-08-13 20:52 ` Sebastian Reichel
2026-08-13 20:52 ` Sebastian Reichel
2026-08-13 20:52 ` [PATCH v14 36/38] phy: rockchip: usbdp: Fix power state handling Sebastian Reichel
2026-08-13 20:52 ` Sebastian Reichel
2026-08-13 20:52 ` Sebastian Reichel
2026-08-13 20:52 ` [PATCH v14 37/38] phy: rockchip: usbdp: Re-init PHY on mux change Sebastian Reichel
2026-08-13 20:52 ` Sebastian Reichel
2026-08-13 20:52 ` Sebastian Reichel
2026-08-14 6:49 ` sashiko-bot
2026-08-14 6:49 ` sashiko-bot
2026-08-13 20:52 ` [PATCH v14 38/38] phy: rockchip: usbdp: Add USB-C state without DP enabled Sebastian Reichel
2026-08-13 20:52 ` Sebastian Reichel
2026-08-13 20:52 ` Sebastian Reichel
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=20260814024151.31F801F000E9@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=linux-phy@lists.infradead.org \
--cc=neil.armstrong@linaro.org \
--cc=olteanv@gmail.com \
--cc=robh@kernel.org \
--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.