Re: [PATCH v3] PCI: imx6: Update MPLLB bandwidth to improve i.MX95 Gen3 PCIe stability

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
- [Medium] Non-atomic configuration of the PHY address and enable bit in `imx95_pcie_phy_write` creates a potentially unsafe intermediate hardware state.
- [Medium] The unconditional 200µs delay is misplaced at the beginning of the PHY write function, leading to a missing post-write settling delay.
- [Medium] Raw write to `IMX95_PCIE_PHY_MPLLB_OVRD_IN` potentially clobbers other override bits.
--

--- Patch [1]: [PATCH v3] PCI: imx6: Update MPLLB bandwidth to improve i.MX95 Gen3 PCIe stability ---
commit 62a7810800383a4677a34a256947f86390e8e2a1
Author: Richard Zhu <hongxing.zhu@nxp.com>

PCI: imx6: Update MPLLB bandwidth to improve i.MX95 Gen3 PCIe stability

This commit updates the MPLLB bandwidth margin settings for the i.MX95 Gen3
PCIe driver to improve link stability across voltage and temperature
variations. It implements a PHY register write helper function to configure
the override registers.

> diff --git a/drivers/pci/controller/dwc/pci-imx6.c b/drivers/pci/controller/dwc/pci-imx6.c
> index 98e1db751132a..55f8aa47cccfd 100644
> --- a/drivers/pci/controller/dwc/pci-imx6.c
> +++ b/drivers/pci/controller/dwc/pci-imx6.c

[ ... ]

> @@ -269,6 +280,16 @@ static int imx95_pcie_select_ref_clk_src(struct imx_pcie *imx_pcie)
>  	return 0;
>  }
>  
> +static void imx95_pcie_phy_write(struct imx_pcie *imx_pcie, int addr, u16 data)
> +{
> +	udelay(200);

[Severity: Medium]
Is the udelay(200) placed correctly here before the register updates?

If this delay is intended to allow the hardware to process the PHY register
write, placing it unconditionally before the writes means the final write in a
sequence will not have a settling delay before initialization proceeds. Would
it make more sense to place this delay after the regmap_write()?

> +	regmap_update_bits(imx_pcie->iomuxc_gpr, IMX95_PCIE_PHY_REG_ADDR,
> +			   IMX95_PCIE_PHY_REG_EN, IMX95_PCIE_PHY_REG_EN);
> +	regmap_update_bits(imx_pcie->iomuxc_gpr, IMX95_PCIE_PHY_REG_ADDR,
> +			   IMX95_PCIE_PHY_REG_ADDR_MASK, addr);

[Severity: Medium]
Does setting the enable bit in a separate transaction before updating the
address expose a stale address to the PHY interface?

If setting the IMX95_PCIE_PHY_REG_EN bit with a stale address initiates an
access, this sequence might cause a spurious hardware transaction. Could both
the address mask and the enable bit be updated simultaneously in a single
atomic read-modify-write operation?

> +	regmap_write(imx_pcie->iomuxc_gpr, IMX95_PCIE_PHY_REG_DATA, data);
> +}
> +
>  static int imx95_pcie_init_phy(struct imx_pcie *imx_pcie)
>  {

[ ... ]

> @@ -289,6 +310,11 @@ static int imx95_pcie_init_phy(struct imx_pcie *imx_pcie)
>  			IMX95_PCIE_PHY_CR_PARA_SEL,
>  			IMX95_PCIE_PHY_CR_PARA_SEL);
>  
> +	imx95_pcie_phy_write(imx_pcie, IMX95_PCIE_PHY_MPLLB_BW_IN,
> +			     IMX95_PCIE_PHY_MPLLB_BW_VAL);
> +	imx95_pcie_phy_write(imx_pcie, IMX95_PCIE_PHY_MPLLB_OVRD_IN,
> +			     IMX95_PCIE_PHY_MPLLB_OVRD_BW_EN);

[Severity: Medium]
Could this write to IMX95_PCIE_PHY_MPLLB_OVRD_IN unintentionally clobber
other bits in the register?

imx95_pcie_phy_write() calls regmap_write() for the data, which will clear
all unspecified bits in the target register to zero. If there are other
necessary override bits or default settings in this register, they would be
disabled by this raw write. Should this use a read-modify-write sequence
instead?

> +
>  	return 0;
>  }
>

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260714024107.4113926-1-hongxing.zhu@oss.nxp.com?part=1