Re: [PATCH net-next] net: mvpp2: Defer probe if MAC address source is not yet ready

[Miquel Raynal <miquel.raynal@bootlin.com>]

Hi Paolo,

pabeni@redhat.com wrote on Thu, 09 Mar 2023 11:12:18 +0100:

> On Tue, 2023-03-07 at 20:29 +0100, Miquel Raynal wrote:
> > NVMEM layouts are no longer registered early, and thus may not yet be
> > available when Ethernet drivers (or any other consumer) probe, leading
> > to possible probe deferrals errors. Forward the error code if this
> > happens. All other errors being discarded, the driver will eventually
> > use a random MAC address if no other source was considered valid (no
> > functional change on this regard).
> > 
> > Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>  
> 
> The patch LGTM, but if feels like a fix more than a new feature re-
> factor. Any special reason to target the net-next tree?

That's a good question, right now nvmem support can only be built-in,
there is no EPROBE_DEFER situation that can arise when reading from an
nvmem device. The introduction of nvmem layouts has been reported due
to their lack of "modularization". Support is being upstreamed right
now in the nvmem tree and this brings two subtleties in one: nvmem cell
reads can now return -EPROBE_DEFER when coming from layouts because 
they are no longer populated very early in the boot process.

Hence IMHO this patch does not "fix" anything as there is currently
nothing broken in 6.3. But as layouts and modules get in the Linux
kernel (6.4-final), users of these layouts (like this driver) should
also handle this new case. Having this patch be merged into linux-next
after the introduction of the nvmem changes has almost no impact. It
just slightly delays the moment in time when MAC addresses can be
retrieved from specific nvmem layouts.

IOW, I believe targeting the net-next tree is fine, but feel free to
take it into net if you prefer.

Thanks,
Miquèl