From: sashiko-bot@kernel.org
To: "Sebastian Reichel" <sebastian.reichel@collabora.com>
Cc: linux-phy@lists.infradead.org, devicetree@vger.kernel.org,
neil.armstrong@linaro.org, vkoul@kernel.org, olteanv@gmail.com,
robh@kernel.org, conor+dt@kernel.org
Subject: Re: [PATCH v9 18/38] phy: rockchip: usbdp: Drop DP HPD handling
Date: Thu, 02 Jul 2026 00:00:24 +0000 [thread overview]
Message-ID: <20260702000025.31AA81F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260702-rockchip-usbdp-cleanup-v9-18-e31efbb62d2e@collabora.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues:
- [High] Incomplete cleanup of DP HPD logic leaves a dangerous register write in the probe path, violating power domain constraints and risking a bus hang (SError).
--
Note: The format of this report has been altered to a free-form summary due
to restrictions on quoting the original patch code.
Commit: 985925db83ee1c14865f1eaca6f60b9245941678
Author: Sebastian Reichel <sebastian.reichel@collabora.com>
Subject: phy: rockchip: usbdp: Drop DP HPD handling
This commit drops the HPD handling logic from the USBDP PHY driver. The
commit message notes that the registers involved require the display
controller power domain to be enabled, and that HPD should be handled
by the displayport controller itself.
[Severity: High]
This is a pre-existing issue, but it appears the cleanup of the DP HPD logic
might be incomplete, leaving a potentially dangerous register write in the
probe path.
In rk_udphy_get_initial_status() in drivers/phy/rockchip/phy-rockchip-usbdp.c,
there is a check to see if the DP PHY was pre-enabled by the bootloader. If
it was, the driver writes false to the hpd_trigger register via
rk_udphy_grfreg_write() and then sleeps for 100ms.
Since the commit message explicitly acknowledges that these registers require
the display controller (VOP) power domain to be enabled, does this write
violate those power domain constraints?
If the kernel disables the VOP power domain before this driver probes (for
example, due to asynchronous probing and the display driver suspending or
resetting its PM domain), could this write to hpd_trigger cause an
asynchronous abort (SError) and a subsequent kernel panic during boot?
Would it make sense to remove this remaining HPD trigger write in the initial
status check as well, to fully decouple the PHY driver from the display
controller power domain?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260702-rockchip-usbdp-cleanup-v9-0-e31efbb62d2e@collabora.com?part=18
next prev parent reply other threads:[~2026-07-02 0:00 UTC|newest]
Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-01 23:35 [PATCH v9 00/38] phy: rockchip: usbdp: Clean up the mess Sebastian Reichel
2026-07-01 23:35 ` [PATCH v9 01/38] dt-bindings: phy: rockchip-usbdp: add improved ports scheme Sebastian Reichel
2026-07-01 23:54 ` sashiko-bot
2026-07-01 23:35 ` [PATCH v9 02/38] phy: rockchip: usbdp: Update mode_change after error handling Sebastian Reichel
2026-07-01 23:35 ` [PATCH v9 03/38] phy: rockchip: usbdp: Do not lose USB3 PHY status Sebastian Reichel
2026-07-01 23:35 ` [PATCH v9 04/38] phy: rockchip: usbdp: Fix devm_clk_bulk_get_all check Sebastian Reichel
2026-07-01 23:35 ` [PATCH v9 05/38] phy: rockchip: usbdp: Handle missing clock-names DT property gracefully Sebastian Reichel
2026-07-01 23:35 ` [PATCH v9 06/38] phy: rockchip: usbdp: Drop seamless DP takeover Sebastian Reichel
2026-07-01 23:59 ` sashiko-bot
2026-07-01 23:35 ` [PATCH v9 07/38] phy: rockchip: usbdp: Handle rk_udphy_reset_deassert_all errors in init check Sebastian Reichel
2026-07-01 23:35 ` [PATCH v9 08/38] phy: rockchip: usbdp: Keep clocks running on PHY re-init Sebastian Reichel
2026-07-01 23:57 ` sashiko-bot
2026-07-01 23:35 ` [PATCH v9 09/38] phy: rockchip: usbdp: Amend SSC modulation deviation Sebastian Reichel
2026-07-01 23:35 ` [PATCH v9 10/38] phy: rockchip: usbdp: Fix LFPS detect threshold control Sebastian Reichel
2026-07-01 23:35 ` [PATCH v9 11/38] phy: rockchip: usbdp: Add missing mode_change update Sebastian Reichel
2026-07-01 23:35 ` [PATCH v9 12/38] phy: rockchip: usbdp: Support single-lane DP Sebastian Reichel
2026-07-01 23:35 ` [PATCH v9 13/38] phy: rockchip: usbdp: Limit DP lane count to muxed lanes Sebastian Reichel
2026-07-01 23:59 ` sashiko-bot
2026-07-01 23:35 ` [PATCH v9 14/38] phy: rockchip: usbdp: Rename DP lane functions Sebastian Reichel
2026-07-01 23:35 ` [PATCH v9 15/38] phy: rockchip: usbdp: Use FIELD_PREP_WM16_CONST Sebastian Reichel
2026-07-01 23:35 ` [PATCH v9 16/38] phy: rockchip: usbdp: Cleanup DP lane selection function Sebastian Reichel
2026-07-01 23:35 ` [PATCH v9 17/38] phy: rockchip: usbdp: Register DP aux bridge Sebastian Reichel
2026-07-01 23:35 ` [PATCH v9 18/38] phy: rockchip: usbdp: Drop DP HPD handling Sebastian Reichel
2026-07-02 0:00 ` sashiko-bot [this message]
2026-07-01 23:35 ` [PATCH v9 19/38] phy: rockchip: usbdp: Rename mode_change to phy_needs_reinit Sebastian Reichel
2026-07-01 23:35 ` [PATCH v9 20/38] phy: rockchip: usbdp: Re-init the PHY on orientation change Sebastian Reichel
2026-07-01 23:35 ` [PATCH v9 21/38] phy: rockchip: usbdp: Factor out lane_mux_sel setup Sebastian Reichel
2026-07-01 23:36 ` [PATCH v9 22/38] phy: rockchip: usbdp: Properly handle TYPEC_STATE_SAFE and TYPEC_STATE_USB Sebastian Reichel
2026-07-01 23:36 ` [PATCH v9 23/38] phy: rockchip: usbdp: Use guard functions for mutex Sebastian Reichel
2026-07-01 23:36 ` [PATCH v9 24/38] phy: rockchip: usbdp: Clear USB status on PHY exit Sebastian Reichel
2026-07-01 23:36 ` [PATCH v9 25/38] phy: rockchip: usbdp: Hold mutex in DP PHY configure Sebastian Reichel
2026-07-01 23:36 ` [PATCH v9 26/38] phy: rockchip: usbdp: Add some extra debug messages Sebastian Reichel
2026-07-01 23:36 ` [PATCH v9 27/38] phy: rockchip: usbdp: Avoid xHCI SErrors Sebastian Reichel
2026-07-01 23:36 ` [PATCH v9 28/38] phy: rockchip: usbdp: Disable USB3 on probe Sebastian Reichel
2026-07-01 23:36 ` [PATCH v9 29/38] phy: rockchip: usbdp: Handle rk_udphy_reset_deassert errors Sebastian Reichel
2026-07-01 23:36 ` [PATCH v9 30/38] phy: rockchip: usbdp: Only enable USB3 when not in high-speed mode Sebastian Reichel
2026-07-01 23:36 ` [PATCH v9 31/38] phy: core: add notifier infrastructure Sebastian Reichel
2026-07-02 0:06 ` sashiko-bot
2026-07-01 23:36 ` [PATCH v9 32/38] usb: dwc3: core: support PHY reset notifications Sebastian Reichel
2026-07-02 0:08 ` sashiko-bot
2026-07-01 23:36 ` [PATCH v9 33/38] phy: rockchip: usbdp: Add phy reset notification support Sebastian Reichel
2026-07-01 23:36 ` [PATCH v9 34/38] phy: rockchip: usbdp: Rename mode to hw_mode Sebastian Reichel
2026-07-01 23:36 ` [PATCH v9 35/38] phy: rockchip: usbdp: Simplify power state handling Sebastian Reichel
2026-07-02 0:12 ` sashiko-bot
2026-07-01 23:36 ` [PATCH v9 36/38] phy: rockchip: usbdp: Rename phy_needs_reinit to orientation_changed Sebastian Reichel
2026-07-02 0:08 ` sashiko-bot
2026-07-01 23:36 ` [PATCH v9 37/38] phy: rockchip: usbdp: Re-init PHY on mux change Sebastian Reichel
2026-07-02 0:12 ` sashiko-bot
2026-07-01 23:36 ` [PATCH v9 38/38] phy: rockchip: usbdp: Power optimizations Sebastian Reichel
2026-07-02 0: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=20260702000025.31AA81F000E9@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