On Tue, Apr 30, 2019 at 04:13:35PM +0200, Petr Štetiar wrote:
> Andrew Lunn <andrew@xxxxxxx> [2019-04-29 15:02:48]:
>
> Hi Andrew,
>
> > > My understanding of -PROBE_DEFER is, that it needs to be propagated back from
> > > the driver's probe callback/hook to the upper device/driver subsystem in order
> > > to be moved to the list of pending drivers and considered for probe later
> > > again. This is not going to happen in any of the current drivers, thus it will
> > > probably still always result in random MAC address in case of -EPROBE_DEFER
> > > error from the nvmem subsystem.
> >
> > All current drivers which don't look in NVMEM don't expect
> > EPROBE_DEFER.
>
> once there's NVMEM wired in of_get_mac_address, one can simply use it, nothing
> is going to stop the potential user of doing so and if EPROBE_DEFER isn't
> propagated from the driver back to the upper device driver subsytem, it's
> probably going to end with random MAC address in some (very rare?) cases.
Hi Petr
There is no simple answer here. If we add EPROBE_DEFER support to all
the current drivers using of_get_mac_address(), we are likely to break
something. Regressions are bad. If somebody does add NVMEM properties
to a device which does not currently have them, and it fails, that it
just bad testing, not a regressions.
So i would keep it KISS. Allow of_get_mac_address() to return an
error, but don't modify current drivers to look for it.
Andrew
