Re: [PATCH] phy: qualcomm: qmp-combo: update DP PHY PLL programming on Glymur

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] Missing DP PHY ready check due to copy-paste error in status register polling.
- [High] Unconditional overwrite of QSERDES_DP_PHY_AUX_CFG2 clobbers the intended patch fix.
--

--- Patch [1]: [PATCH] phy: qualcomm: qmp-combo: update DP PHY PLL programming on Glymur ---
(Note: Due to system recitation restrictions, this review uses a free-form
summary format instead of inline quoting of the patch diff.)

commit f0c7819a29d1aef3384c1acb434959f322baf8bd
Author: Ritesh Kumar <ritesh.kumar@oss.qualcomm.com>

phy: qualcomm: qmp-combo: update DP PHY PLL programming on Glymur

The existing DP PHY PLL and AUX configuration for the Glymur platform
does not fully follow the Hardware Programming Guide requirements for
DP over Type-C, which results in DP link bring-up failures.
Update the DP PHY programming sequence and PLL-related register
settings to align with the latest recommendations.

Link: https://lore.kernel.org/all/20260419-glymur_dp-v1-1-ad1067a8e8ae@oss.qualcomm.com/

[Severity: High]
Looking at the updated status polling in qmp_v8_configure_dp_phy() in
drivers/phy/qualcomm/phy-qcom-qmp-combo.c, the code now polls
QPHY_DP_PHY_STATUS for BIT(0), and then polls QPHY_COM_CMN_STATUS twice
(first for BIT(0), then for BIT(1)).

Previously, this section waited for the DP PHY to become ready by polling
QPHY_DP_PHY_STATUS for BIT(1) after writing to QSERDES_DP_PHY_CFG. Since
QPHY_COM_CMN_STATUS was already polled earlier in the sequence, will these
new checks succeed immediately and bypass the required synchronization for
the DP PHY state machine? Could this result in race conditions and
DisplayPort link training failures?

[Severity: High]
In the newly introduced qmp_v8_helper_configure_dp_phy() function in the
same file, there is an unconditional write of 0xa4 to
QSERDES_DP_PHY_AUX_CFG2.

However, qmp_v8_dp_aux_init() is designed to write the newly recommended
0x06 value to QSERDES_DP_PHY_AUX_CFG2. Because the helper function
qmp_v8_helper_configure_dp_phy() is called later during link training via
configure_dp_phy(), will this hardcoded write of 0xa4 clobber the 0x06 value
programmed earlier? Does this inadvertently undo the intended AUX
configuration fix for the Glymur platform?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260721-glymur-phy-conf-v1-1-7c8909552c5e@oss.qualcomm.com?part=1

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