Re: [PATCH 3/3] phy: zynqmp: keep SERDES scrambler and 8b/10b enabled for USB

["Pandey, Radhey Shyam" <radheys@amd.com>]

On 5/13/2026 4:01 AM, sashiko-bot@kernel.org wrote:
> 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.

Since this series specifically targets USB fixes will send out separate
series addressing comment on DP/PCIe default state.

Vinod: Please let me know if you are fine /or have any objections.

> --
> 
> 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?
> 


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