phy: marvell: phy-mvebu-cp110-comphy: link failure and lockup built as module (=M)
Andrew Lunn
andrew at lunn.ch
Sun Oct 26 19:06:39 PDT 2025
On Sat, Oct 25, 2025 at 12:45:52PM +0000, Josua Mayer wrote:
> Dear Maintainers,
>
> I came across a bug srelating to cp110 comphy driver.
>
> On a board with CN9130 SoC + 2 external CPs Debian 13 freezes during boot,
> at some point after initramfs and kernel module loading has started.
>
> This occurs only when a pci card is present and had link-up from u-boot, e.g.:
>
> PCIE-0: Link up (Gen3-x4, Bus0)
> PCIE-12: Link up (Gen3-x1, Bus12)
>
> The issue is reproducible with a generic rootfs, kernel built with arm64 defconfig,
> no initramfs, but a single kernel configuration change:
>
> CONFIG_PHY_MVEBU_CP110_COMPHY=y -> m
>
> i.e. building the comphy driver as a module.
>
> The problem shows up usually by the console freezing during boot,
> before eventually the system watchdog hard resets SoC.
Do you know at what point the comphy driver module is loaded?
Do you get the same behaviour if the comphy module is not built/not
available?
I _guess_ that there is some missing EPROBE_DEFER code. It could be
when the PCIE code tries to get the PHY and fails, it just keeps
going, when in fact it needs to return EPROBE_DEFER, so that the core
will try again later, once the module has been loaded.
Actually
static int armada8k_pcie_setup_phys(struct armada8k_pcie *pcie)
{
struct dw_pcie *pci = pcie->pci;
struct device *dev = pci->dev;
struct device_node *node = dev->of_node;
int ret = 0;
int i;
for (i = 0; i < ARMADA8K_PCIE_MAX_LANES; i++) {
pcie->phy[i] = devm_of_phy_get_by_index(dev, node, i);
if (IS_ERR(pcie->phy[i])) {
if (PTR_ERR(pcie->phy[i]) != -ENODEV)
return PTR_ERR(pcie->phy[i]);
pcie->phy[i] = NULL;
continue;
}
pcie->phy_count++;
}
Do you see devm_of_phy_get_by_index() return -ENODEV? If i'm reading
this code correctly, it will just continue without the PHY.
Andrew
More information about the linux-phy
mailing list