Linux-PHY Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Sebastian Reichel" <sebastian.reichel@collabora.com>
Cc: conor+dt@kernel.org, robh@kernel.org, devicetree@vger.kernel.org,
	vkoul@kernel.org, neil.armstrong@linaro.org,
	linux-phy@lists.infradead.org, olteanv@gmail.com
Subject: Re: [PATCH v5 12/18] phy: rockchip: usbdp: Drop DP HPD handling
Date: Fri, 12 Jun 2026 16:53:56 +0000	[thread overview]
Message-ID: <20260612165356.CCE691F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260612-rockchip-usbdp-cleanup-v5-12-efc83069869f@collabora.com>

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

Pre-existing issues:
- [High] Lockless access to shared Type-C lane mappings in `rk_udphy_dp_phy_configure` causes data race
--

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

phy: rockchip: usbdp: Drop DP HPD handling

This commit drops the HPD handling logic from the USBDP PHY. The registers
involved require the display controller power domain being enabled, so the HPD
signal should be handled by the displayport controller itself.

> diff --git a/drivers/phy/rockchip/phy-rockchip-usbdp.c b/drivers/phy/rockchip/phy-rockchip-usbdp.c
> --- a/drivers/phy/rockchip/phy-rockchip-usbdp.c
> +++ b/drivers/phy/rockchip/phy-rockchip-usbdp.c

[ ... ]

> static int rk_udphy_dp_phy_configure(struct phy *phy,
> 				     union phy_configure_opts *opts)
> {

[ ... ]

> 	if (dp->set_voltages) {
> 		for (i = 0; i < udphy->lanes; i++) {
> 			lane = udphy->dp_lane_sel[i];
> 			switch (udphy->link_rate) {
> 			case 1620:
> 			case 2700:

[Severity: High]
This isn't a bug introduced by this patch, but I noticed a potential data
race here. Does this loop access udphy->dp_lane_sel and
udphy->lane_mux_sel safely?

These arrays define the active Type-C DP lane mapping and are updated by
asynchronous Type-C subsystem events in rk_udphy_orien_sw_set() and
rk_udphy_typec_mux_set() under the protection of udphy->mutex.

Since rk_udphy_dp_phy_configure() does not hold udphy->mutex (only the
framework-level phy->mutex), could a concurrent Type-C cable orientation
or mode switch cause this code to read a partially updated lane mapping?

This might lead to incorrect DP PHY register programming, configuring the
wrong hardware lanes and causing link training or display failures.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260612-rockchip-usbdp-cleanup-v5-0-efc83069869f@collabora.com?part=12

-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

  reply	other threads:[~2026-06-12 16:53 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-06-12 16:21 [PATCH v5 00/18] phy: rockchip: usbdp: Fixes, DP 1-lane support and cleanups Sebastian Reichel
2026-06-12 16:21 ` [PATCH v5 01/18] dt-bindings: phy: rockchip-usbdp: add improved ports scheme Sebastian Reichel
2026-06-12 16:21 ` [PATCH v5 02/18] phy: rockchip: usbdp: Do not lose USB3 PHY status Sebastian Reichel
2026-06-12 16:38   ` sashiko-bot
2026-06-12 16:21 ` [PATCH v5 03/18] phy: rockchip: usbdp: Keep clocks running on PHY re-init Sebastian Reichel
2026-06-12 16:41   ` sashiko-bot
2026-06-12 16:21 ` [PATCH v5 04/18] phy: rockchip: usbdp: Amend SSC modulation deviation Sebastian Reichel
2026-06-12 16:21 ` [PATCH v5 05/18] phy: rockchip: usbdp: Fix LFPS detect threshold control Sebastian Reichel
2026-06-12 16:21 ` [PATCH v5 06/18] phy: rockchip: usbdp: Add missing mode_change update Sebastian Reichel
2026-06-12 16:46   ` sashiko-bot
2026-06-12 16:21 ` [PATCH v5 07/18] phy: rockchip: usbdp: Support single-lane DP Sebastian Reichel
2026-06-12 16:55   ` sashiko-bot
2026-06-12 16:21 ` [PATCH v5 08/18] phy: rockchip: usbdp: Rename DP lane functions Sebastian Reichel
2026-06-12 16:21 ` [PATCH v5 09/18] phy: rockchip: usbdp: Use FIELD_PREP_WM16_CONST Sebastian Reichel
2026-06-12 16:21 ` [PATCH v5 10/18] phy: rockchip: usbdp: Cleanup DP lane selection function Sebastian Reichel
2026-06-12 16:21 ` [PATCH v5 11/18] phy: rockchip: usbdp: Register DP aux bridge Sebastian Reichel
2026-06-12 16:21 ` [PATCH v5 12/18] phy: rockchip: usbdp: Drop DP HPD handling Sebastian Reichel
2026-06-12 16:53   ` sashiko-bot [this message]
2026-06-12 16:21 ` [PATCH v5 13/18] phy: rockchip: usbdp: Rename mode_change to phy_needs_reinit Sebastian Reichel
2026-06-12 16:52   ` sashiko-bot
2026-06-12 16:21 ` [PATCH v5 14/18] phy: rockchip: usbdp: Re-init the PHY on orientation change Sebastian Reichel
2026-06-12 17:03   ` sashiko-bot
2026-06-12 16:21 ` [PATCH v5 15/18] phy: rockchip: usbdp: Factor out lane_mux_sel setup Sebastian Reichel
2026-06-12 16:21 ` [PATCH v5 16/18] phy: rockchip: usbdp: Use guard functions for mutex Sebastian Reichel
2026-06-12 16:21 ` [PATCH v5 17/18] phy: rockchip: usbdp: Support going from DP-only mode to USB mode Sebastian Reichel
2026-06-12 17:08   ` sashiko-bot
2026-06-12 16:21 ` [PATCH v5 18/18] phy: rockchip: usbdp: Add some extra debug messages Sebastian Reichel
2026-06-12 17:06   ` 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=20260612165356.CCE691F000E9@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