Re: [PATCH v9 7/8] ARM: dts: microchip: sama5d27_wlsom1: read MAC address from QSPI SFDP

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] nvmem: sst26vf-sfdp-eui: infinite probe deferral on missing EUI-48
--

commit 2233a3452b4615481340768cbd46d9b4bfaf12ac
Author: Manikandan Muralidharan <manikandan.m@microchip.com>

ARM: dts: microchip: sama5d27_wlsom1: read MAC address from QSPI SFDP

This commit configures the QSPI flash SFDP as an NVMEM provider on the
sama5d27_wlsom1_ek board to read the factory-programmed MAC address. It
adds the nvmem-cells property to the macb0 node so it can retrieve the
EUI-48 identifier.

> diff --git a/arch/arm/boot/dts/microchip/at91-sama5d27_wlsom1_ek.dts b/arch/arm/boot/dts/microchip/at91-sama5d27_wlsom1_ek.dts
> index 35a933eec5738..5e87bf04bc47c 100644
> --- a/arch/arm/boot/dts/microchip/at91-sama5d27_wlsom1_ek.dts
> +++ b/arch/arm/boot/dts/microchip/at91-sama5d27_wlsom1_ek.dts
> @@ -97,6 +97,8 @@ uart6: serial@200 {
>  
>  &macb0 {
>  	status = "okay";
> +	nvmem-cells = <&mac_address_eui48>;
> +	nvmem-cell-names = "mac-address";
>  };

[Severity: High]
Will this lead to an infinite probe deferral loop if the QSPI flash EUI-48
marker is unprogrammed, missing, or corrupted?

The commit message notes that boards without an EUI-programmed part simply
do not reference the cell. However, if the flash part is present but the
marker is missing or corrupted, it appears the macb0 interface will fail to
initialize entirely instead of falling back to a random MAC address.

Looking at the nvmem layout driver:

drivers/nvmem/layouts/sst26vf-sfdp-eui.c:sfdp_eui_add_cells() {
        if (marker != SFDP_MCHP_EUI48_MARKER) {
                dev_dbg(dev, "EUI-48 not programmed (marker 0x%02x)\n", marker);
                return 0;
        }
}

This silently returns 0 without adding the cell, which leaves the layout
bound.

When macb_probe() requests the cell, the nvmem core sees the bound layout
but missing cell:

drivers/nvmem/core.c:of_nvmem_cell_get() {
        ret = nvmem->layout ? -EPROBE_DEFER : -ENOENT;
}

This causes of_nvmem_cell_get() to return -EPROBE_DEFER indefinitely.

Then in the ethernet driver:

drivers/net/ethernet/cadence/macb_main.c:macb_probe() {
        err = of_get_ethdev_address(np, bp->netdev);
        if (err == -EPROBE_DEFER)
                goto err_out_free_netdev;
}

Because macb_probe() treats -EPROBE_DEFER as a fatal error that requires
deferring, it skips the fallback path and never brings up macb0.

Could the layout driver return -ENOENT instead when the marker is missing,
or is there another way to ensure the ethernet interface can fall back to a
random MAC address in this scenario?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/cover.1792145382.git.manikandan.m@microchip.com?part=7

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/