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

[<Manikandan.M@microchip.com>]

Both deferral paths are real, but neither is specific to this patch and
neither is reachable on the hardware this DT targets:

- The layout-driver-missing case (-EPROBE_DEFER from
   nvmem_layout_module_get_optional()) is the standard "DT references a
   provider that isn't built" behaviour. Patch 7/7 enables the layout in
   sama5_defconfig precisely so the provider is present.

- The cell-absent case (nvmem->layout ? -EPROBE_DEFER : -ENOENT in
   of_nvmem_cell_get()), On the sama5d27_wlsom1 SoM the qspi1 flash node
   is only enabled on boards carrying the factory-programmed
   SST26VF064BEUI, where the EUI-48 marker is
   always present and the mac-address cell is always added, so macb0 does
   not defer.

I'll add a note to the commit message clarifying that the SoM ships the
EUI-programmed part

On 7/30/26 10:02, sashiko-bot@kernel.org wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
> 
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> - [High] Indefinite probe deferral for `macb0` network interface if the EUI-48 marker is unprogrammed or the nvmem layout driver is missing.
> --
> 
> --- Patch [6]: [PATCH v6 6/7] ARM: dts: microchip: sama5d27_wlsom1: read MAC address from QSPI SFDP ---
> commit 8eba2f7e81780da2083cb3da12b2567024175fa6
> Author: Manikandan Muralidharan <manikandan.m@microchip.com>
> 
> ARM: dts: microchip: sama5d27_wlsom1: read MAC address from QSPI SFDP
> 
> This commit exposes the factory-programmed EUI-48 as a mac-address cell
> via the QSPI flash SFDP NVMEM provider. It points macb0 at this cell
> to provide a stable MAC address on boards where U-Boot does not set one.
> 
>> 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 cause an indefinite probe deferral for the macb0 interface if the
> EUI-48 marker is unprogrammed or the nvmem layout driver is missing?
> 
> When the device tree statically links the macb0 interface to the
> mac_address_eui48 nvmem cell, macb_probe() calls of_get_ethdev_address()
> which internally calls of_nvmem_cell_get().
> 
> If the kernel is missing the microchip,sst26vf-sfdp-eui layout driver, the
> nvmem core via nvmem_layout_module_get_optional() returns -EPROBE_DEFER
> indefinitely.
> 
> Alternatively, if the layout driver is loaded but the board's flash chip
> lacks an EUI-48, the layout driver gracefully returns 0 without adding the
> cell. However, of_nvmem_cell_get() unconditionally returns -EPROBE_DEFER if
> a cell is missing but an nvmem-layout node exists in the device tree:
> 
> ret = nvmem->layout ? -EPROBE_DEFER : -ENOENT;
> 
> In both scenarios, macb_probe() receives -EPROBE_DEFER and indefinitely
> defers, breaking the intended fallback to a random MAC address and resulting
> in a complete loss of network connectivity.
> 
>>   };
> 
> --
> Sashiko AI review · https://sashiko.dev/#/patchset/20260729043026.1811147-1-manikandan.m@microchip.com?part=6


-- 
Thanks and Regards,
Manikandan M.