Re: [PATCH v5 2/2] PCI: mediatek: Add support for EcoNet EN7528 SoC

[Bjorn Helgaas <helgaas@kernel.org>]

On Mon, Apr 13, 2026 at 02:03:39PM +0000, Caleb James DeLisle wrote:
> Add support for the PCIe present on the EcoNet EN7528 (and EN751221) SoCs.
> 
> These SoCs have a mix of Gen1 and Gen2 capable ports, but the Gen2 ports
> require re-training after startup.

> +#include <asm-generic/errno-base.h>

Looks odd; why is this here?  There are basically no other drivers
that do this.

> @@ -1149,6 +1234,46 @@ static int mtk_pcie_probe(struct platform_device *pdev)
>  	if (err)
>  		goto put_resources;
>  
> +	/* EN7528 PCIe initially comes up as Gen1 even if Gen2 is supported.
> +	 * The cannonical way to achieve Gen2 is to re-train the link
> +	 * immediately after setup. However, to save a lot of duplicated code
> +	 * we use pcie_retrain_link() which is usable once we have the pci_dev
> +	 * struct for the bridge, i.e. after pci_host_probe(). */

s/cannonical/canonical/

> +	if (pcie->soc->quirks & MTK_PCIE_RETRAIN) {
> +		int slot = of_get_pci_domain_nr(dev->of_node);

I suppose of_get_pci_domain_nr() is sort of an implicit way to
identify the Gen2 ports?  Worth at least a comment about this DT
connection.  Maybe it could be replaced by using
pcie_get_supported_speeds() or similar?

> +		struct pci_dev *rc = NULL;

s/rc/rp/ to avoid confusing "root port" for "return code" or "root
complex".

> +		int ret = -ENOENT;
> +
> +		if (slot >= 0)
> +			rc = pci_get_slot(host->bus, PCI_DEVFN(slot, 0));

Instead of fiddling with pci_get_slot(), which adds refcount issues
and artificial device/function number dependencies, I think it would
be better to iterate over the devices on host->bus, e.g., with
"for_each_pci_bridge(dev, host->bus)" as in iproc_pcie_setup().

> +		if (rc) {
> +			ret = -EOPNOTSUPP;
> +
> +			/* pcie_retrain_link() is not an exported symbol but
> +			 * this driver supports being built as a loadable
> +			 * module. Someone using this on an EN7528 should make
> +			 * it builtin, or accept Gen1 PCI. */
> +#if IS_BUILTIN(CONFIG_PCIE_MEDIATEK)
> +			ret = pcie_retrain_link(rc, true);
> +#endif

This looks like a confusing user experience if built as a module, with
no hint to the user about why the link is slower than it should be.
I guess "failed to retrain" is a bit of a hint, but it's not really a
clue about how to fix it.

> +		}
> +
> +		if (ret) {
> +			dev_info(dev, "port%d failed to retrain %pe\n", slot,
> +				 ERR_PTR(ret));

This is basically an error path and there's nothing else to do, so if
you return directly here (especially if you factor this to a separate
function), the "normal" path below can be unindented.

> +		} else {
> +			u16 lnksta;
> +			u32 speed;
> +
> +			pcie_capability_read_word(rc, PCI_EXP_LNKSTA, &lnksta);
> +			speed = lnksta & PCI_EXP_LNKSTA_CLS;
> +
> +			dev_info(dev, "port%d link retrained, speed %s\n", slot,
> +				 pci_speed_string(pcie_link_speed[speed]));
> +		}
> +	}

Maybe factor the retrain block into a helper function.

I'm sort of squinting at this whole link retrain thing to begin with.
After the controller is configured correctly, the hardware is supposed
to train the link automatically by itself.

Did something change between mtk_pcie_startup_port_en7528() and now
that means the link will train at Gen2?  Whatever that change is,
could it be done in mtk_pcie_startup_port_en7528()?

What happens when the downstream device is put in D3cold and the link
retrains after power is restored?  Does it train at Gen2 then, without
assistance like this?