Devicetree
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Sebastian Reichel" <sebastian.reichel@collabora.com>
Cc: olteanv@gmail.com, robh@kernel.org, conor+dt@kernel.org,
	devicetree@vger.kernel.org, vkoul@kernel.org,
	neil.armstrong@linaro.org, linux-phy@lists.infradead.org
Subject: Re: [PATCH v8 13/29] phy: rockchip: usbdp: Limit DP lane count to muxed lanes
Date: Fri, 26 Jun 2026 21:17:36 +0000	[thread overview]
Message-ID: <20260626211737.38CCC1F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260626-rockchip-usbdp-cleanup-v8-13-47f682987895@collabora.com>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] This problem wasn't introduced by this patch, but the patch's fix is incomplete. The lane count validation added to prevent DP configurations from corrupting USB3 PHY state is bypassed during voltage-only updates. If the Type-C state dynamically reduces the available DP lanes, `udphy->dp_lanes` is updated but the cached `udphy->lanes` remains stale. A subsequent voltage-only update will iterate up to the stale `udphy->lanes` and write DP voltage configurations to the physically reassigned USB3 lanes, corrupting the USB3 PHY state.
--

commit e11a3cd1b181c4fdc9e18a16f2893d3ae7465cb5
Author: Sebastian Reichel <sebastian.reichel@collabora.com>

phy: rockchip: usbdp: Limit DP lane count to muxed lanes

This commit limits the DisplayPort lane count to 2 if the PHY is
restricted due to USB3 usage. It aims to prevent USB3 state corruption
during voltage configuration.

Closes: https://lore.kernel.org/linux-phy/20260612165546.98E1F1F000E9@smtp.kernel.org/

> diff --git a/drivers/phy/rockchip/phy-rockchip-usbdp.c b/drivers/phy/rockchip/phy-rockchip-usbdp.c
> index 5c38da0dadd22..6de8ac3f91441 100644
> --- a/drivers/phy/rockchip/phy-rockchip-usbdp.c
> +++ b/drivers/phy/rockchip/phy-rockchip-usbdp.c
> @@ -1132,6 +1132,9 @@ static int rk_udphy_dp_phy_verify_link_rate(struct rk_udphy *udphy,
>  static int rk_udphy_dp_phy_verify_lanes(struct rk_udphy *udphy,
>  					struct phy_configure_opts_dp *dp)
>  {
> +	if (dp->lanes > udphy->dp_lanes)
> +		return -EINVAL;
> +

[Severity: High]
This isn't a bug introduced by this patch, but is the fix incomplete for
voltage-only updates?

If a Type-C event renegotiates the connection and restricts udphy->dp_lanes
to 2, udphy->lanes could still hold a stale value (like 4).

Looking at rk_udphy_dp_phy_configure(), the lane verification is skipped
if dp->set_lanes is false:

drivers/phy/rockchip/phy-rockchip-usbdp.c:rk_udphy_dp_phy_configure() {
	...
	if (dp->set_lanes) {
		ret = rk_udphy_dp_phy_verify_lanes(udphy, dp);
		if (ret)
			return ret;
	}
	...
}

If the driver then issues a phy_configure() with set_lanes=false and
set_voltages=true, the voltage loop will iterate using the stale
udphy->lanes value:

drivers/phy/rockchip/phy-rockchip-usbdp.c:rk_udphy_dp_phy_configure() {
	...
	if (dp->set_voltages) {
		for (i = 0; i < udphy->lanes; i++) {
			lane = udphy->dp_lane_sel[i];
	...
}

Could this still result in writing DP voltage configurations to reassigned
USB3 lanes, corrupting the USB3 PHY state?

>  	switch (dp->lanes) {
>  	case 1:
>  	case 2:
[ ... ]

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260626-rockchip-usbdp-cleanup-v8-0-47f682987895@collabora.com?part=13

  reply	other threads:[~2026-06-26 21:17 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-06-26 20:54 [PATCH v8 00/29] phy: rockchip: usbdp: Fixes, DP 1-lane support and cleanups Sebastian Reichel
2026-06-26 20:54 ` [PATCH v8 01/29] dt-bindings: phy: rockchip-usbdp: add improved ports scheme Sebastian Reichel
2026-06-26 21:13   ` sashiko-bot
2026-06-26 20:54 ` [PATCH v8 02/29] phy: rockchip: usbdp: Update mode_change after error handling Sebastian Reichel
2026-06-26 20:54 ` [PATCH v8 03/29] phy: rockchip: usbdp: Do not lose USB3 PHY status Sebastian Reichel
2026-06-26 21:16   ` sashiko-bot
2026-06-26 20:54 ` [PATCH v8 04/29] phy: rockchip: usbdp: Fix devm_clk_bulk_get_all check Sebastian Reichel
2026-06-26 20:54 ` [PATCH v8 05/29] phy: rockchip: usbdp: Handle missing clock-names DT property gracefully Sebastian Reichel
2026-06-26 21:12   ` sashiko-bot
2026-06-26 20:54 ` [PATCH v8 06/29] phy: rockchip: usbdp: Drop seamless DP takeover Sebastian Reichel
2026-06-26 21:16   ` sashiko-bot
2026-06-26 20:55 ` [PATCH v8 07/29] phy: rockchip: usbdp: Handle rk_udphy_reset_deassert_all errors in init check Sebastian Reichel
2026-06-26 21:11   ` sashiko-bot
2026-06-26 20:55 ` [PATCH v8 08/29] phy: rockchip: usbdp: Keep clocks running on PHY re-init Sebastian Reichel
2026-06-26 20:55 ` [PATCH v8 09/29] phy: rockchip: usbdp: Amend SSC modulation deviation Sebastian Reichel
2026-06-26 20:55 ` [PATCH v8 10/29] phy: rockchip: usbdp: Fix LFPS detect threshold control Sebastian Reichel
2026-06-26 20:55 ` [PATCH v8 11/29] phy: rockchip: usbdp: Add missing mode_change update Sebastian Reichel
2026-06-26 20:55 ` [PATCH v8 12/29] phy: rockchip: usbdp: Support single-lane DP Sebastian Reichel
2026-06-26 21:19   ` sashiko-bot
2026-06-26 20:55 ` [PATCH v8 13/29] phy: rockchip: usbdp: Limit DP lane count to muxed lanes Sebastian Reichel
2026-06-26 21:17   ` sashiko-bot [this message]
2026-06-26 20:55 ` [PATCH v8 14/29] phy: rockchip: usbdp: Rename DP lane functions Sebastian Reichel
2026-06-26 20:55 ` [PATCH v8 15/29] phy: rockchip: usbdp: Use FIELD_PREP_WM16_CONST Sebastian Reichel
2026-06-26 20:55 ` [PATCH v8 16/29] phy: rockchip: usbdp: Cleanup DP lane selection function Sebastian Reichel
2026-06-26 20:55 ` [PATCH v8 17/29] phy: rockchip: usbdp: Register DP aux bridge Sebastian Reichel
2026-06-26 21:14   ` sashiko-bot
2026-06-26 20:55 ` [PATCH v8 18/29] phy: rockchip: usbdp: Drop DP HPD handling Sebastian Reichel
2026-06-26 20:55 ` [PATCH v8 19/29] phy: rockchip: usbdp: Rename mode_change to phy_needs_reinit Sebastian Reichel
2026-06-26 20:55 ` [PATCH v8 20/29] phy: rockchip: usbdp: Re-init the PHY on orientation change Sebastian Reichel
2026-06-26 21:18   ` sashiko-bot
2026-06-26 20:55 ` [PATCH v8 21/29] phy: rockchip: usbdp: Factor out lane_mux_sel setup Sebastian Reichel
2026-06-26 20:55 ` [PATCH v8 22/29] phy: rockchip: usbdp: Properly handle TYPEC_STATE_SAFE and TYPEC_STATE_USB Sebastian Reichel
2026-06-26 20:55 ` [PATCH v8 23/29] phy: rockchip: usbdp: Use guard functions for mutex Sebastian Reichel
2026-06-26 20:55 ` [PATCH v8 24/29] phy: rockchip: usbdp: Support going from DP-only mode to USB mode Sebastian Reichel
2026-06-26 21:17   ` sashiko-bot
2026-06-26 20:55 ` [PATCH v8 25/29] phy: rockchip: usbdp: Clear USB status on PHY exit Sebastian Reichel
2026-06-26 21:17   ` sashiko-bot
2026-06-26 20:55 ` [PATCH v8 26/29] phy: rockchip: usbdp: Hold mutex in DP PHY configure Sebastian Reichel
2026-06-26 20:55 ` [PATCH v8 27/29] phy: rockchip: usbdp: Add some extra debug messages Sebastian Reichel
2026-06-26 20:55 ` [PATCH v8 28/29] phy: rockchip: usbdp: Avoid xHCI SErrors Sebastian Reichel
2026-06-26 21:24   ` sashiko-bot
2026-06-26 20:55 ` [PATCH v8 29/29] phy: rockchip: usbdp: Disable USB3 on probe Sebastian Reichel
2026-06-26 21:24   ` sashiko-bot

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=20260626211737.38CCC1F000E9@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox