NVMEM core perpetual -EPROBE_DEFER blocks fallback mechanisms, bricking network/PCIe

Description
When an underlying NVMEM provider (e.g., a SPI/NAND flash driver) fails to probe, nvmem_cell_get() perpetually returns -EPROBE_DEFER. This traps consumer drivers—such as Ethernet drivers fetching a MAC address or PHY drivers fetching calibration data—in an endless deferred probe loop.

Because the NVMEM core never returns a definitive error code (like -ENODEV), the consumer drivers are never allowed to trigger their built-in fallback routines (e.g., calling eth_hw_addr_random() for a random MAC). As a result, the devices remain completely non-functional, effectively bricking the network and PCIe interfaces just because the flash driver failed.

Symptoms / Logs
During boot, consumers remain indefinitely in the deferred probe pending list, and the interfaces never come up:

[   18.407677] platform 15100000.ethernet: deferred probe pending: (reason unknown)
[   18.415080] pci 0000:01:00.0: deferred probe pending: (reason unknown)

Start by tracing the nvmem_cell_get() return path when an underlying provider fails, then inspect the Ethernet and PHY consumer paths that fetch MAC or calibration data. Use the deferred-probe logs as the reproduction signal; done means a failed provider no longer leaves consumers indefinitely pending and their documented fallback routines can run.