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

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:

New issues:
- [Medium] The indirect PHY address and enable bit are updated in two separate, non-atomic read-modify-write operations.

Pre-existing issues:
- [High] The regmap `imx_pcie->iomuxc_gpr` is accessed during the `resume_noirq` phase without a raw spinlock, leading to a sleeping-in-atomic bug on PREEMPT_RT.
--

--- Patch [1]: [PATCH v4] PCI: imx6: Update MPLLB bandwidth to improve i.MX95 Gen3 PCIe stability ---
commit b27e9944369b914b92884bcfe73498504647f095
Author: Richard Zhu <[email protected]>

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

This patch implements a PHY register write helper function and configures
the MPLLB bandwidth override to improve i.MX95 Gen3 PCIe link stability
across voltage and temperature variations.

> diff --git a/drivers/pci/controller/dwc/pci-imx6.c b/drivers/pci/controller/dwc/pci-imx6.c
> --- a/drivers/pci/controller/dwc/pci-imx6.c
> +++ b/drivers/pci/controller/dwc/pci-imx6.c

[ ... ]

> @@ -269,6 +280,15 @@ 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)
> +{
> +	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]
Is it safe to split the enable bit and address into two separate non-atomic
updates to the same register?

Writing the IMX95_PCIE_PHY_REG_EN bit before the actual address could
momentarily expose the EN=1 state with an uninitialized or old address to
the hardware. Could this trigger an unintended register access?

Would it be safer to combine both updates into a single regmap_update_bits()
call using a combined mask?

> +	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 +309,18 @@ static int imx95_pcie_init_phy(struct imx_pcie *imx_pcie)
>  			IMX95_PCIE_PHY_CR_PARA_SEL,
>  			IMX95_PCIE_PHY_CR_PARA_SEL);
>  
> +	/*
> +	 * A delay is required between the assertion of
> +	 * IMX95_PCIE_PHY_CR_PARA_SEL and subsequent PHY register write
> +	 * operation to ensure values are successfully written.
> +	 */
> +	udelay(200);
> +
> +	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: High]
This isn't a bug introduced by this patch, but adding more regmap operations
here extends a pre-existing sleep-in-atomic issue on PREEMPT_RT kernels.

Because imx95_pcie_init_phy() is reachable from the resume_noirq phase with
hardware interrupts disabled:

imx_pcie_resume_noirq()
  dw_pcie_resume_noirq()
    imx_pcie_host_init()
      imx95_pcie_init_phy()
        imx95_pcie_phy_write()
          regmap_write()

Can these regmap calls cause a lockdep splat or deadlock?

MMIO regmaps initialized without use_raw_spinlock = true use sleepable
rt_mutex locks on PREEMPT_RT. Acquiring this lock with local interrupts
disabled leads to a sleeping function called from invalid context bug.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/[email protected]?part=1