lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Wed, 1 May 2019 15:54:17 +0200
From:   Andrew Lunn <>
To:     Petr Štetiar <>
        Nicolas Ferre <>,
        "David S. Miller" <>,
        Florian Fainelli <>,
        Heiner Kallweit <>,
        Rob Herring <>,
        Frank Rowand <>,
        Srinivas Kandagatla <>,
        Maxime Ripard <>,
        Alban Bedel <>
Subject: Re: Handling of EPROBE_DEFER in of_get_mac_address [Was: Re: [PATCH
 v2 3/4] net: macb: Drop nvmem_get_mac_address usage]

On Tue, Apr 30, 2019 at 04:13:35PM +0200, Petr Štetiar wrote:
> Andrew Lunn <> [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
> 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.


Powered by blists - more mailing lists