Re: [PATCH v11] PCI: mediatek: Add support for EcoNet EN7528 SoC

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
- [High] PCIe link retraining is initiated after endpoint devices are registered, causing a race condition where drivers may probe while the link is down.
- [Medium] Failure to retrain one PCIe root port aborts the retraining loop, preventing subsequent independent ports from being retrained.
- [Medium] Driver degrades functionality when built as a module due to missing EXPORT_SYMBOL for pcie_retrain_link().
--

commit d5f03f20dd1953eb7241e17dbd765b2b467f01c7
Author: Caleb James DeLisle <cjd@cjdns.fr>

PCI: mediatek: Add support for EcoNet EN7528 SoC

This adds support for the PCIe controller present on the EcoNet EN7528 and
EN751221 SoCs. These SoCs contain a mix of Gen1 and Gen2 ports, where Gen2
ports require retraining after startup.

> diff --git a/drivers/pci/controller/pcie-mediatek.c b/drivers/pci/controller/pcie-mediatek.c
> index 8b57c3d75b942..a60d1ae076f80 100644
> --- a/drivers/pci/controller/pcie-mediatek.c
> +++ b/drivers/pci/controller/pcie-mediatek.c

[ ... ]

> @@ -756,6 +767,134 @@ static int mtk_pcie_startup_port_v2(struct mtk_pcie_port *port)
>  	return 0;
>  }
>  
> +static int mtk_pcie_startup_port_en7528(struct mtk_pcie_port *port)
> +{

[ ... ]

> +	if (!IS_BUILTIN(CONFIG_PCIE_MEDIATEK))
> +		dev_info(pcie->dev,
> +			 "module not built-in, Gen2 unavailable even if supported\n");
> +
> +	return 0;
> +}
> +
> +/**
> + * mtk_pcie_retrain - retrain the root bridge link if needed
> + * @dev: The device, for use in logging
> + * @host: The host bridge which contains the link
> + *
> + * Due to what is likely a hardware bug, some devices (notably EcoNet) start up
> + * as Gen1, and must be retrained once after initial configuration in order to
> + * reach Gen2.
> + *
> + * These devices always self-identify as Gen2 capable, but sometimes the PHY is
> + * only capable of Gen1 operation, and sometimes the PCIe card (e.g. wifi) is
> + * only Gen1 capable. Therefore it is most convenient to retrain every port
> + * after startup.
> + */
> +static int mtk_pcie_retrain(struct device *dev, struct pci_host_bridge *host)
> +{
> +	struct pci_dev *rp;
> +	int ret = -ENOENT;
> +	u16 lnksta = 0;
> +	u32 speed;
> +
> +	/* Should already have been warned about during startup_port */
> +	if (!IS_BUILTIN(CONFIG_PCIE_MEDIATEK))
> +		return 0;
> +
> +	guard(rwsem_read)(&pci_bus_sem);
> +
> +	for_each_pci_bridge(rp, host->bus) {
> +		if (pci_pcie_type(rp) != PCI_EXP_TYPE_ROOT_PORT)
> +			continue;
> +
> +#if IS_BUILTIN(CONFIG_PCIE_MEDIATEK)
> +		ret = pcie_retrain_link(rp, true);
> +#endif

[Severity: Medium]
Does skipping the pcie_retrain_link() call for module builds unintentionally
degrade functionality?

If this driver requires pcie_retrain_link() for Gen2 speeds, would it be
more appropriate to export pcie_retrain_link() in the PCI core instead of
guarding the call and silently falling back to Gen1 when compiled as a module?

> +
> +		if (ret)
> +			return dev_err_probe(&rp->dev, ret,
> +					     "failed to retrain port\n");

[Severity: Medium]
If pcie_retrain_link() fails on one root port, this early return will abort
the for_each_pci_bridge() iteration.

Will this prevent subsequent independent root ports from being retrained?

Could this use a continue statement instead to ensure remaining ports are
still processed?

> +
> +		pcie_capability_read_word(rp, PCI_EXP_LNKSTA, &lnksta);
> +		speed = lnksta & PCI_EXP_LNKSTA_CLS;
> +
> +		pci_info(rp, "link retrained, speed %s\n",
> +			 pci_speed_string(pcie_link_speed[speed]));
> +
> +	}
> +
> +	return 0;
> +}

[ ... ]

> @@ -1169,6 +1308,13 @@ static int mtk_pcie_probe(struct platform_device *pdev)
>  	if (err)
>  		goto put_resources;
>  
> +	/*
> +	 * Ignore error because pci_host_probe() was already called, and in any
> +	 * case it is possible that the port will still work as Gen1.
> +	 */
> +	if (pcie->soc->quirks & MTK_PCIE_RETRAIN)
> +		mtk_pcie_retrain(dev, host);

[Severity: High]
Since pci_host_probe() was already called, downstream endpoint devices are
already registered and their drivers might be concurrently executing their
probe routines.

Could mtk_pcie_retrain() drop the physical link while an endpoint driver is
performing MMIO reads or writes?

This concurrent access during link downtime could result in master aborts
(returning 0xFFFFFFFF) and cause driver initialization failures or system
crashes. 

Is it possible to perform link retraining prior to registering the
downstream devices?

> +
>  	return 0;
>  
>  put_resources:

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260702150704.265282-1-cjd@cjdns.fr?part=1