All of lore.kernel.org
 help / color / mirror / Atom feed
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

WARNING: multiple messages have this Message-ID (diff)
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

  reply	other threads:[~2026-07-14  6:53 UTC|newest]

Thread overview: 31+ 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 ` Esteban Urrutia
2026-07-14  6:36 ` 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:36   ` Esteban Urrutia
2026-07-14  6:36   ` Esteban Urrutia via B4 Relay
2026-07-14  6:43   ` sashiko-bot
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:36   ` Esteban Urrutia
2026-07-14  6:36   ` Esteban Urrutia via B4 Relay
2026-07-14  6:53   ` sashiko-bot [this message]
2026-07-14  6:53     ` sashiko-bot
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   ` Esteban Urrutia
2026-07-14  6:36   ` 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:36   ` Esteban Urrutia
2026-07-14  6:36   ` Esteban Urrutia via B4 Relay
2026-07-14  6:47   ` sashiko-bot
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:36   ` Esteban Urrutia
2026-07-14  6:36   ` Esteban Urrutia via B4 Relay
2026-07-14  6:49   ` sashiko-bot
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:36   ` Esteban Urrutia
2026-07-14  6:36   ` Esteban Urrutia via B4 Relay
2026-07-14  6:47   ` sashiko-bot
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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.