lists.openwall.net | 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 linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Message-ID: <20190501135417.GB19809@lunn.ch> Date: Wed, 1 May 2019 15:54:17 +0200 From: Andrew Lunn <andrew@...n.ch> To: Petr Štetiar <ynezz@...e.cz> Cc: netdev@...r.kernel.org, devicetree@...r.kernel.org, linux-kernel@...r.kernel.org, Nicolas Ferre <nicolas.ferre@...rochip.com>, "David S. Miller" <davem@...emloft.net>, Florian Fainelli <f.fainelli@...il.com>, Heiner Kallweit <hkallweit1@...il.com>, Rob Herring <robh+dt@...nel.org>, Frank Rowand <frowand.list@...il.com>, Srinivas Kandagatla <srinivas.kandagatla@...aro.org>, Maxime Ripard <maxime.ripard@...tlin.com>, Alban Bedel <albeu@...e.fr> 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 <andrew@...n.ch> [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
Powered by blists - more mailing lists