From: sashiko-bot@kernel.org
To: "Esteban Urrutia" <esteuwu@proton.me>
Cc: robh@kernel.org, linux-phy@lists.infradead.org, vkoul@kernel.org,
conor+dt@kernel.org, neil.armstrong@linaro.org,
olteanv@gmail.com, devicetree@vger.kernel.org
Subject: Re: [PATCH 2/6] phy: qcom: qmp-pcie: Add pcs_lane1 offset to V5 offsets
Date: Tue, 14 Jul 2026 06:53:13 +0000 [thread overview]
Message-ID: <20260714065313.AA56D1F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260714-sm8475-bup-v1-2-b2871be2b4ec@proton.me>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues:
- [High] Missing `.pcs_lane1` offset in `qmp_pcie_offsets_v6_20` causes silent out-of-bounds register overwrite of the `tx` block.
--
--- Patch [2]: [PATCH 2/6] phy: qcom: qmp-pcie: Add pcs_lane1 offset to V5 offsets ---
commit 796aa959cc0a08be913f9eb871fe4312d98e16fc
Author: Esteban Urrutia <esteuwu@proton.me>
phy: qcom: qmp-pcie: Add pcs_lane1 offset to V5 offsets
Some SoCs such as SM8475 write data to registers using this offset,
specifically SW_CTRL2 and MX_CTRL2. Add pcs_lane1 offset to V5 offsets using
the proper offset, otherwise these registers would be part of RX and would not
be defined.
> diff --git a/drivers/phy/qualcomm/phy-qcom-qmp-pcie.c b/drivers/phy/qualcomm/phy-qcom-qmp-pcie.c
> index d3effad7a074b..3618812e84d5f 100644
> --- a/drivers/phy/qualcomm/phy-qcom-qmp-pcie.c
> +++ b/drivers/phy/qualcomm/phy-qcom-qmp-pcie.c
> @@ -3554,6 +3554,7 @@ static const struct qmp_pcie_offsets qmp_pcie_offsets_v5 = {
> .pcs_misc = 0x0600,
> .tx = 0x0e00,
> .rx = 0x1000,
> + .pcs_lane1 = 0x1400,
> .tx2 = 0x1600,
> .rx2 = 0x1800,
> };
[Severity: High]
This is a pre-existing issue and wasn't introduced by this patch, but while
you are adding the pcs_lane1 offset here, is it also missing from
qmp_pcie_offsets_v6_20?
Looking at drivers/phy/qualcomm/phy-qcom-qmp-pcie.c, qmp_pcie_offsets_v6_20
omits the .pcs_lane1 mapping:
static const struct qmp_pcie_offsets qmp_pcie_offsets_v6_20 = {
.serdes = 0x1000,
.pcs = 0x1200,
.pcs_misc = 0x1400,
.tx = 0x0000,
.rx = 0x0200,
.tx2 = 0x0800,
.rx2 = 0x0a00,
.ln_shrd = 0x0e00,
};
This omission causes .pcs_lane1 to implicitly default to 0x0000, which is the
same offset as the .tx block.
However, sdx65_qmp_pciephy_cfg pairs this offset structure with a valid
pcs_lane1 table:
static const struct qmp_phy_cfg sdx65_qmp_pciephy_cfg = {
.lanes = 2,
.offsets = &qmp_pcie_offsets_v6_20,
.tbls = {
// ...
.pcs_lane1 = sdx65_qmp_pcie_pcs_lane1_tbl,
.pcs_lane1_num = ARRAY_SIZE(sdx65_qmp_pcie_pcs_lane1_tbl),
},
Will this cause the pcs_lane1 table to blindly overwrite the PHY transmitter
registers in the tx block during initialization?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260714-sm8475-bup-v1-0-b2871be2b4ec@proton.me?part=2
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
next prev parent reply other threads:[~2026-07-14 6:53 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-14 6:36 [PATCH 0/6] Initial PCIe0 and QMP USB PHYs support for SM8475 Esteban Urrutia via B4 Relay
2026-07-14 6:36 ` [PATCH 1/6] dt-bindings: phy: qcom,sc8280xp-qmp-pcie-phy: Add SM8475 QMP PHY Esteban Urrutia via B4 Relay
2026-07-14 6:43 ` sashiko-bot
2026-07-14 6:36 ` [PATCH 2/6] phy: qcom: qmp-pcie: Add pcs_lane1 offset to V5 offsets Esteban Urrutia via B4 Relay
2026-07-14 6:53 ` sashiko-bot [this message]
2026-07-14 6:36 ` [PATCH 3/6] phy: qcom: qmp-pcie: Add support for SM8475 Gen3x1 PCIe0 port Esteban Urrutia via B4 Relay
2026-07-14 6:36 ` [PATCH 4/6] dt-bindings: phy: qcom,sc8280xp-qmp-usb43dp-phy: Add SM8475 QMP PHY Esteban Urrutia via B4 Relay
2026-07-14 6:47 ` sashiko-bot
2026-07-14 6:36 ` [PATCH 5/6] phy: qcom: qmp-combo: Add serdes and RBR/HBR/HBR2/HBR3 tables for v1 DP PLLs Esteban Urrutia via B4 Relay
2026-07-14 6:49 ` sashiko-bot
2026-07-14 6:36 ` [PATCH 6/6] phy: qcom: qmp-combo: Add SM8475 support Esteban Urrutia via B4 Relay
2026-07-14 6:47 ` 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=20260714065313.AA56D1F000E9@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