All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Sebastian Reichel" <sebastian.reichel@collabora.com>
Cc: olteanv@gmail.com, robh@kernel.org, neil.armstrong@linaro.org,
	conor+dt@kernel.org, devicetree@vger.kernel.org,
	linux-phy@lists.infradead.org, vkoul@kernel.org
Subject: Re: [PATCH v15 11/16] phy: rockchip: usbdp: Support single-lane DP
Date: Tue, 15 Sep 2026 14:03:37 +0000	[thread overview]
Message-ID: <20260915140337.C31661F000FF@smtp.kernel.org> (raw)
In-Reply-To: <20260915-rockchip-usbdp-cleanup-v15-11-80e2c11d1ce8@collabora.com>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] phy: rockchip: usbdp: errant DP lane enable in USB-only mode
--

commit eaea7c0e371c41abc4589c0ac17cb5d7fe7f1179
Author: Zhang Yubing <yubing.zhang@rock-chips.com>

phy: rockchip: usbdp: Support single-lane DP

This commit implements support for using just a single DisplayPort line in
the rockchip usbdp phy driver.

> diff --git a/drivers/phy/rockchip/phy-rockchip-usbdp.c b/drivers/phy/rockchip/phy-rockchip-usbdp.c
> index b72daf80af15f..4fce9cd664735 100644
> --- a/drivers/phy/rockchip/phy-rockchip-usbdp.c
> +++ b/drivers/phy/rockchip/phy-rockchip-usbdp.c

[ ... ]

> @@ -1049,18 +1038,17 @@ static int rk_udphy_dp_phy_power_on(struct phy *phy)
>  static int rk_udphy_dp_phy_power_on(struct phy *phy)
>  {
>  	struct rk_udphy *udphy = phy_get_drvdata(phy);
> -	int ret, dp_lanes;
> +	int ret;
>  
>  	mutex_lock(&udphy->mutex);
>  
> -	dp_lanes = rk_udphy_dplane_get(udphy);
> -	phy_set_bus_width(phy, dp_lanes);
> +	phy_set_bus_width(phy, udphy->dp_lanes);
>  
>  	ret = rk_udphy_power_on(udphy, UDPHY_MODE_DP);
>  	if (ret)
>  		goto unlock;
>  
> -	rk_udphy_dplane_enable(udphy, dp_lanes);
> +	rk_udphy_dplane_enable(udphy, udphy->dp_lanes);

[Severity: Medium]
Could this unintentionally enable unclocked DP lane drivers on the physical
pins in USB-only mode?

If the DP controller calls phy_power_on(), rk_udphy_power_on() might detect
that UDPHY_MODE_DP is not supported in udphy->mode. If it does, it prints a
message and returns 0 (success) without powering up the DP PLLs. Execution
then proceeds to this rk_udphy_dplane_enable() call.

Prior to this patch, rk_udphy_dplane_get() returned 0 when DP was disabled,
which safely disabled the lanes and asserted CMN_DP_CMN_RSTN. Now, since
rk_udphy_typec_mux_set() unconditionally sets udphy->dp_lanes to 2 or 4 in
Type-C states (even without DP altmode), a non-zero value is passed here.

Does passing the decoupled udphy->dp_lanes skip asserting the reset and
erroneously enable unclocked DP lane drivers, potentially causing undefined
PHY behavior or electrical contention on shared pins?

[ ... ]

> @@ -1356,6 +1345,7 @@ static int rk_udphy_typec_mux_set(struct typec_mux_dev *mux,
>  			udphy->lane_mux_sel[3] = PHY_LANE_MUX_DP;
>  		}
>  		mode = UDPHY_MODE_DP_USB;
> +		udphy->dp_lanes = 2;
>  		break;
>  	}

[Severity: Medium]
Does this unconditionally set dp_lanes to 2 for USB-only Type-C states without
updating udphy->mode, contributing to the DP lane enable issue mentioned above
in rk_udphy_dp_phy_power_on()?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260915-rockchip-usbdp-cleanup-v15-0-80e2c11d1ce8@collabora.com?part=11

-- 
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: olteanv@gmail.com, robh@kernel.org, neil.armstrong@linaro.org,
	conor+dt@kernel.org, devicetree@vger.kernel.org,
	linux-phy@lists.infradead.org, vkoul@kernel.org
Subject: Re: [PATCH v15 11/16] phy: rockchip: usbdp: Support single-lane DP
Date: Tue, 15 Sep 2026 14:03:37 +0000	[thread overview]
Message-ID: <20260915140337.C31661F000FF@smtp.kernel.org> (raw)
In-Reply-To: <20260915-rockchip-usbdp-cleanup-v15-11-80e2c11d1ce8@collabora.com>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] phy: rockchip: usbdp: errant DP lane enable in USB-only mode
--

commit eaea7c0e371c41abc4589c0ac17cb5d7fe7f1179
Author: Zhang Yubing <yubing.zhang@rock-chips.com>

phy: rockchip: usbdp: Support single-lane DP

This commit implements support for using just a single DisplayPort line in
the rockchip usbdp phy driver.

> diff --git a/drivers/phy/rockchip/phy-rockchip-usbdp.c b/drivers/phy/rockchip/phy-rockchip-usbdp.c
> index b72daf80af15f..4fce9cd664735 100644
> --- a/drivers/phy/rockchip/phy-rockchip-usbdp.c
> +++ b/drivers/phy/rockchip/phy-rockchip-usbdp.c

[ ... ]

> @@ -1049,18 +1038,17 @@ static int rk_udphy_dp_phy_power_on(struct phy *phy)
>  static int rk_udphy_dp_phy_power_on(struct phy *phy)
>  {
>  	struct rk_udphy *udphy = phy_get_drvdata(phy);
> -	int ret, dp_lanes;
> +	int ret;
>  
>  	mutex_lock(&udphy->mutex);
>  
> -	dp_lanes = rk_udphy_dplane_get(udphy);
> -	phy_set_bus_width(phy, dp_lanes);
> +	phy_set_bus_width(phy, udphy->dp_lanes);
>  
>  	ret = rk_udphy_power_on(udphy, UDPHY_MODE_DP);
>  	if (ret)
>  		goto unlock;
>  
> -	rk_udphy_dplane_enable(udphy, dp_lanes);
> +	rk_udphy_dplane_enable(udphy, udphy->dp_lanes);

[Severity: Medium]
Could this unintentionally enable unclocked DP lane drivers on the physical
pins in USB-only mode?

If the DP controller calls phy_power_on(), rk_udphy_power_on() might detect
that UDPHY_MODE_DP is not supported in udphy->mode. If it does, it prints a
message and returns 0 (success) without powering up the DP PLLs. Execution
then proceeds to this rk_udphy_dplane_enable() call.

Prior to this patch, rk_udphy_dplane_get() returned 0 when DP was disabled,
which safely disabled the lanes and asserted CMN_DP_CMN_RSTN. Now, since
rk_udphy_typec_mux_set() unconditionally sets udphy->dp_lanes to 2 or 4 in
Type-C states (even without DP altmode), a non-zero value is passed here.

Does passing the decoupled udphy->dp_lanes skip asserting the reset and
erroneously enable unclocked DP lane drivers, potentially causing undefined
PHY behavior or electrical contention on shared pins?

[ ... ]

> @@ -1356,6 +1345,7 @@ static int rk_udphy_typec_mux_set(struct typec_mux_dev *mux,
>  			udphy->lane_mux_sel[3] = PHY_LANE_MUX_DP;
>  		}
>  		mode = UDPHY_MODE_DP_USB;
> +		udphy->dp_lanes = 2;
>  		break;
>  	}

[Severity: Medium]
Does this unconditionally set dp_lanes to 2 for USB-only Type-C states without
updating udphy->mode, contributing to the DP lane enable issue mentioned above
in rk_udphy_dp_phy_power_on()?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260915-rockchip-usbdp-cleanup-v15-0-80e2c11d1ce8@collabora.com?part=11

  reply	other threads:[~2026-09-15 14:03 UTC|newest]

Thread overview: 101+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-15 13:49 [PATCH v15 00/16] phy: rockchip: usbdp: Clean up the mess (part 1) Sebastian Reichel
2026-09-15 13:49 ` Sebastian Reichel
2026-09-15 13:49 ` Sebastian Reichel
2026-09-15 13:49 ` [PATCH v15 01/16] dt-bindings: phy: rockchip-usbdp: add improved ports scheme Sebastian Reichel
2026-09-15 13:49   ` Sebastian Reichel
2026-09-15 13:49   ` Sebastian Reichel
2026-09-15 13:49 ` [PATCH v15 02/16] phy: rockchip: usbdp: Update mode_change after error handling Sebastian Reichel
2026-09-15 13:49   ` Sebastian Reichel
2026-09-15 13:49   ` Sebastian Reichel
2026-09-26  3:18   ` Manivannan Sadhasivam
2026-09-26  3:18     ` Manivannan Sadhasivam
2026-09-26  3:18     ` Manivannan Sadhasivam
2026-09-15 13:49 ` [PATCH v15 03/16] phy: rockchip: usbdp: Do not lose USB3 PHY status Sebastian Reichel
2026-09-15 13:49   ` Sebastian Reichel
2026-09-15 13:49   ` Sebastian Reichel
2026-09-26  3:28   ` Manivannan Sadhasivam
2026-09-26  3:28     ` Manivannan Sadhasivam
2026-09-26  3:28     ` Manivannan Sadhasivam
2026-09-15 13:49 ` [PATCH v15 04/16] phy: rockchip: usbdp: Fix devm_clk_bulk_get_all check Sebastian Reichel
2026-09-15 13:49   ` Sebastian Reichel
2026-09-15 13:49   ` Sebastian Reichel
2026-09-26  3:30   ` Manivannan Sadhasivam
2026-09-26  3:30     ` Manivannan Sadhasivam
2026-09-26  3:30     ` Manivannan Sadhasivam
2026-09-15 13:49 ` [PATCH v15 05/16] phy: rockchip: usbdp: Handle missing clock-names DT property gracefully Sebastian Reichel
2026-09-15 13:49   ` Sebastian Reichel
2026-09-15 13:49   ` Sebastian Reichel
2026-09-26  3:32   ` Manivannan Sadhasivam
2026-09-26  3:32     ` Manivannan Sadhasivam
2026-09-26  3:32     ` Manivannan Sadhasivam
2026-09-15 13:49 ` [PATCH v15 06/16] phy: rockchip: usbdp: Drop seamless DP takeover Sebastian Reichel
2026-09-15 13:49   ` Sebastian Reichel
2026-09-15 13:49   ` Sebastian Reichel
2026-09-26  3:33   ` Manivannan Sadhasivam
2026-09-26  3:33     ` Manivannan Sadhasivam
2026-09-26  3:33     ` Manivannan Sadhasivam
2026-09-15 13:49 ` [PATCH v15 07/16] phy: rockchip: usbdp: Keep clocks running on PHY re-init Sebastian Reichel
2026-09-15 13:49   ` Sebastian Reichel
2026-09-15 13:49   ` Sebastian Reichel
2026-09-26  3:37   ` Manivannan Sadhasivam
2026-09-26  3:37     ` Manivannan Sadhasivam
2026-09-26  3:37     ` Manivannan Sadhasivam
2026-09-15 13:49 ` [PATCH v15 08/16] phy: rockchip: usbdp: Amend SSC modulation deviation Sebastian Reichel
2026-09-15 13:49   ` Sebastian Reichel
2026-09-15 13:49   ` Sebastian Reichel
2026-09-26  3:59   ` Manivannan Sadhasivam
2026-09-26  3:59     ` Manivannan Sadhasivam
2026-09-26  3:59     ` Manivannan Sadhasivam
2026-09-15 13:49 ` [PATCH v15 09/16] phy: rockchip: usbdp: Fix LFPS detect threshold control Sebastian Reichel
2026-09-15 13:49   ` Sebastian Reichel
2026-09-15 13:49   ` Sebastian Reichel
2026-09-26  4:00   ` Manivannan Sadhasivam
2026-09-26  4:00     ` Manivannan Sadhasivam
2026-09-26  4:00     ` Manivannan Sadhasivam
2026-09-15 13:49 ` [PATCH v15 10/16] phy: rockchip: usbdp: Add missing mode_change update Sebastian Reichel
2026-09-15 13:49   ` Sebastian Reichel
2026-09-15 13:49   ` Sebastian Reichel
2026-09-26  4:01   ` Manivannan Sadhasivam
2026-09-26  4:01     ` Manivannan Sadhasivam
2026-09-26  4:01     ` Manivannan Sadhasivam
2026-09-15 13:49 ` [PATCH v15 11/16] phy: rockchip: usbdp: Support single-lane DP Sebastian Reichel
2026-09-15 13:49   ` Sebastian Reichel
2026-09-15 13:49   ` Sebastian Reichel
2026-09-15 14:03   ` sashiko-bot [this message]
2026-09-15 14:03     ` sashiko-bot
2026-09-26  4:03   ` Manivannan Sadhasivam
2026-09-26  4:03     ` Manivannan Sadhasivam
2026-09-26  4:03     ` Manivannan Sadhasivam
2026-09-15 13:49 ` [PATCH v15 12/16] phy: rockchip: usbdp: Limit DP lane count to muxed lanes Sebastian Reichel
2026-09-15 13:49   ` Sebastian Reichel
2026-09-15 13:49   ` Sebastian Reichel
2026-09-26  4:04   ` Manivannan Sadhasivam
2026-09-26  4:04     ` Manivannan Sadhasivam
2026-09-26  4:04     ` Manivannan Sadhasivam
2026-09-15 13:50 ` [PATCH v15 13/16] phy: rockchip: usbdp: Rename DP lane functions Sebastian Reichel
2026-09-15 13:50   ` Sebastian Reichel
2026-09-15 13:50   ` Sebastian Reichel
2026-09-26  4:06   ` Manivannan Sadhasivam
2026-09-26  4:06     ` Manivannan Sadhasivam
2026-09-26  4:06     ` Manivannan Sadhasivam
2026-09-15 13:50 ` [PATCH v15 14/16] phy: rockchip: usbdp: Use FIELD_PREP_WM16_CONST Sebastian Reichel
2026-09-15 13:50   ` Sebastian Reichel
2026-09-15 13:50   ` Sebastian Reichel
2026-09-26  4:10   ` Manivannan Sadhasivam
2026-09-26  4:10     ` Manivannan Sadhasivam
2026-09-26  4:10     ` Manivannan Sadhasivam
2026-09-15 13:50 ` [PATCH v15 15/16] phy: rockchip: usbdp: Cleanup DP lane selection function Sebastian Reichel
2026-09-15 13:50   ` Sebastian Reichel
2026-09-15 13:50   ` Sebastian Reichel
2026-09-26  4:20   ` Manivannan Sadhasivam
2026-09-26  4:20     ` Manivannan Sadhasivam
2026-09-26  4:20     ` Manivannan Sadhasivam
2026-09-15 13:50 ` [PATCH v15 16/16] phy: rockchip: usbdp: Register DP aux bridge Sebastian Reichel
2026-09-15 13:50   ` Sebastian Reichel
2026-09-15 13:50   ` Sebastian Reichel
2026-09-26  4:28   ` Manivannan Sadhasivam
2026-09-26  4:28     ` Manivannan Sadhasivam
2026-09-26  4:28     ` Manivannan Sadhasivam
2026-10-03  9:36 ` [PATCH v15 00/16] phy: rockchip: usbdp: Clean up the mess (part 1) Vinod Koul
2026-10-03  9:36   ` Vinod Koul
2026-10-03  9:36   ` 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=20260915140337.C31661F000FF@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.