From: sashiko-bot@kernel.org
To: "Radhey Shyam Pandey" <radhey.shyam.pandey@amd.com>
Cc: linux-phy@lists.infradead.org, olteanv@gmail.com,
vkoul@kernel.org, neil.armstrong@linaro.org
Subject: Re: [PATCH 3/3] phy: zynqmp: keep SERDES scrambler and 8b/10b enabled for USB
Date: Tue, 12 May 2026 22:31:41 +0000 [thread overview]
Message-ID: <20260512223142.1AFC4C2BCB0@smtp.kernel.org> (raw)
In-Reply-To: <20260511163135.2924642-4-radhey.shyam.pandey@amd.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] This problem wasn't introduced by this patch, but the scrambler and 8b/10b bypass state is not explicitly initialized for DisplayPort (DP) and PCIe, leaving them vulnerable to inheriting an incorrect hardware state.
--
commit bd13b5595b6bf913b77d4b61fb704c7e56fa4847
Author: Nava kishore Manne <nava.kishore.manne@amd.com>
phy: zynqmp: keep SERDES scrambler and 8b/10b enabled for USB
This commit ensures that physical layer scrambling and 8b/10b encoding are
not bypassed for USB operations. It explicitly disables the scrambler bypass
for USB3 while preserving it for SATA and SGMII modes where encoding is
handled by the controller.
> diff --git a/drivers/phy/xilinx/phy-zynqmp.c b/drivers/phy/xilinx/phy-zynqmp.c
> index 6c56c4df8523c..087fe402e4e20 100644
> --- a/drivers/phy/xilinx/phy-zynqmp.c
> +++ b/drivers/phy/xilinx/phy-zynqmp.c
[ ... ]
> @@ -707,6 +722,10 @@ static int xpsgtr_phy_init(struct phy *phy)
> case ICM_PROTOCOL_SGMII:
> xpsgtr_phy_init_sgmii(gtr_phy);
> break;
> +
> + case ICM_PROTOCOL_USB:
> + xpsgtr_bypass_scrambler_8b10b(gtr_phy, false);
> + break;
> }
Does this leave the scrambler and 8b/10b bypass state uninitialized for
DisplayPort (DP) and PCIe?
While this commit resolves the state leak for USB by explicitly clearing the
bypass bits, it appears DP and PCIe might still be vulnerable to similar
issues.
If a lane is repurposed from SATA or SGMII to DP or PCIe (for example, if a
bootloader probes an M.2 slot for SATA, and Linux later configures it for
PCIe NVMe), could the PHY inherit an erroneously bypassed state?
Should the bypass bits also be explicitly cleared for ICM_PROTOCOL_DP and
ICM_PROTOCOL_PCIE to ensure they do not rely on potentially corrupted hardware
defaults?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260511163135.2924642-1-radhey.shyam.pandey@amd.com?part=3
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
prev parent reply other threads:[~2026-05-12 22:31 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-11 16:31 [PATCH 0/3] phy: zynqmp: fix SERDES scrambler register handling and enable for USB Radhey Shyam Pandey
2026-05-11 16:31 ` [PATCH 1/3] phy: zynqmp: fix L0_TM_DISABLE_SCRAMBLE_ENCODER mask Radhey Shyam Pandey
2026-05-12 21:35 ` sashiko-bot
2026-05-11 16:31 ` [PATCH 2/3] phy: zynqmp: use read-modify-write for SERDES scrambler bypass Radhey Shyam Pandey
2026-05-11 16:31 ` [PATCH 3/3] phy: zynqmp: keep SERDES scrambler and 8b/10b enabled for USB Radhey Shyam Pandey
2026-05-12 22:31 ` sashiko-bot [this message]
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=20260512223142.1AFC4C2BCB0@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=linux-phy@lists.infradead.org \
--cc=neil.armstrong@linaro.org \
--cc=olteanv@gmail.com \
--cc=radhey.shyam.pandey@amd.com \
--cc=sashiko@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