Linux-PHY Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Esteban Urrutia" <esteuwu@proton.me>
Cc: olteanv@gmail.com, vkoul@kernel.org, conor+dt@kernel.org,
	devicetree@vger.kernel.org, linux-phy@lists.infradead.org,
	neil.armstrong@linaro.org, robh@kernel.org
Subject: Re: [PATCH RESEND v3 2/2] phy: qcom: qmp-combo: Add SM8475 support
Date: Tue, 04 Aug 2026 18:20:22 +0000	[thread overview]
Message-ID: <20260804182023.4AE951F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260804-sm8475-bup-usbss-v3-2-9a5b9ebf62de@proton.me>

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

New issues:
- [High] Missing `.calibrate_dp_phy` callback assignment in the newly added `sm8475_usb3dpphy_cfg` struct.

Pre-existing issues:
- [High] SAR2130P configuration is not updated to use the new v1 DP PLL tables despite being explicitly identified as a v1 SoC.
--

--- Patch [2]: [PATCH RESEND v3 2/2] phy: qcom: qmp-combo: Add SM8475 support ---
commit 1b30757e50e17e9f7e360c8987c9aafc76411e20
Author: Esteban Urrutia <esteuwu@proton.me>

phy: qcom: qmp-combo: Add SM8475 support

This patch adds USB3 and DP combo PHY support for the Qualcomm SM8475 SoC.
It introduces new RX and PCS USB tables, reuses others from existing SoCs,
and adds specific v1 PLL structures for 4nm-v1 SoCs to fix link training
failures caused by reference clock differences.

> Some SoCs such as SAR2130P, SM7550, SM7635 and SM8475 use 4nm-v1 PLLs.
> For SM8475, trying to use qmp_v6_dp_serdes_tbl structs (which are for
> 4nm-v1.1 PLLs) causes link training to fail because of ref clock
> differences, which in turn makes these structs differ.

[Severity: High]
This is a pre-existing issue, but since this patch introduces the v1 DP PLL
tables to fix link training for 4nm-v1 PLLs, shouldn't
sar2130p_usb3dpphy_cfg also be updated to use them?

Currently sar2130p_usb3dpphy_cfg still references the incompatible v1.1
tables (qmp_v6_dp_serdes_tbl), which according to this commit message
causes link training to fail on these SoCs.

> diff --git a/drivers/phy/qualcomm/phy-qcom-qmp-combo.c b/drivers/phy/qualcomm/phy-qcom-qmp-combo.c
> index cdcfad2e86b1d..52b07de2c52b5 100644
> --- a/drivers/phy/qualcomm/phy-qcom-qmp-combo.c
> +++ b/drivers/phy/qualcomm/phy-qcom-qmp-combo.c

[ ... ]

> @@ -2845,6 +2965,51 @@ static const struct qmp_phy_cfg sm8350_usb3dpphy_cfg = {
>  	.has_pwrdn_delay	= true,
>  };
>  
> +static const struct qmp_phy_cfg sm8475_usb3dpphy_cfg = {
> +	.offsets		= &qmp_combo_offsets_v3,

[ ... ]

> +	.dp_aux_init		= qmp_v4_dp_aux_init,
> +	.configure_dp_tx	= qmp_v4_configure_dp_tx,
> +	.configure_dp_clocks	= qmp_v3_configure_dp_clocks,
> +	.configure_dp_phy	= qmp_v4_configure_dp_phy,

[Severity: High]
Is the .calibrate_dp_phy callback intentionally omitted here?

Without the calibration loop being assigned (e.g., to
qmp_v4_calibrate_dp_phy), DP link training will not iterate through
different voltage swing and pre-emphasis settings upon a failure. This
could cause link training failures with certain cables or external displays.

> +
> +	.regs			= qmp_v6_usb3phy_regs_layout,
> +	.reset_list		= msm8996_usb3phy_reset_l,
> +	.num_resets		= ARRAY_SIZE(msm8996_usb3phy_reset_l),
> +	.vreg_list		= qmp_phy_vreg_l,
> +	.num_vregs		= ARRAY_SIZE(qmp_phy_vreg_l),
> +};

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260804-sm8475-bup-usbss-v3-0-9a5b9ebf62de@proton.me?part=2

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

  reply	other threads:[~2026-08-04 18:20 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-04 18:06 [PATCH RESEND v3 0/2] Initial QMP USB PHY support for SM8475 Esteban Urrutia via B4 Relay
2026-08-04 18:06 ` [PATCH RESEND v3 1/2] dt-bindings: phy: qcom,sc8280xp-qmp-usb43dp-phy: Add SM8475 QMP PHY Esteban Urrutia via B4 Relay
2026-08-04 18:06 ` [PATCH RESEND v3 2/2] phy: qcom: qmp-combo: Add SM8475 support Esteban Urrutia via B4 Relay
2026-08-04 18:20   ` sashiko-bot [this message]
2026-08-04 23:38   ` Dmitry Baryshkov
2026-08-06 16:26 ` [PATCH RESEND v3 0/2] Initial QMP USB PHY support for SM8475 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=20260804182023.4AE951F000E9@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=esteuwu@proton.me \
    --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=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