linux-kernel - Re: [PATCH v3 01/10] of_net: add NVMEM support to of_get_mac

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20190503093629.2cby4jwtgkzqaru6@flea>
Date:   Fri, 3 May 2019 11:36:29 +0200
From:   Maxime Ripard <maxime.ripard@...tlin.com>
To:     Petr Štetiar <ynezz@...e.cz>
Cc:     Sergei Shtylyov <sergei.shtylyov@...entembedded.com>,
        netdev@...r.kernel.org, devicetree@...r.kernel.org,
        Andrew Lunn <andrew@...n.ch>,
        Florian Fainelli <f.fainelli@...il.com>,
        Rob Herring <robh+dt@...nel.org>,
        Frank Rowand <frowand.list@...il.com>,
        Heiner Kallweit <hkallweit1@...il.com>,
        Srinivas Kandagatla <srinivas.kandagatla@...aro.org>,
        Alban Bedel <albeu@...e.fr>, Felix Fietkau <nbd@....name>,
        John Crispin <john@...ozen.org>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3 01/10] of_net: add NVMEM support to of_get_mac_address

On Fri, May 03, 2019 at 11:15:42AM +0200, Petr Štetiar wrote:
> Sergei Shtylyov <sergei.shtylyov@...entembedded.com> [2019-05-03 11:44:54]:
>
> Hi Sergei,
>
> > > diff --git a/drivers/of/of_net.c b/drivers/of/of_net.c
> > > index d820f3e..258ceb8 100644
> > > --- a/drivers/of/of_net.c
> > > +++ b/drivers/of/of_net.c
> > [...]
> > > @@ -64,6 +113,9 @@ static const void *of_get_mac_addr(struct device_node *np, const char *name)
> > >    * addresses.  Some older U-Boots only initialized 'local-mac-address'.  In
> > >    * this case, the real MAC is in 'local-mac-address', and 'mac-address' exists
> > >    * but is all zeros.
> > > + *
> > > + * Return: Will be a valid pointer on success, NULL in case there wasn't
> > > + *         'mac-address' nvmem cell node found, and ERR_PTR in case of error.
> >
> >    Returning both NULL and error codes on failure is usually a sign of a
> > misdesigned API.
>
> well, then there's a lot of misdesigned APIs in the tree already, as I've just
> grepped for IS_ERR_OR_NULL usage and found this pointer/NULL/ERR_PTR usage
> pretty legit.

That's not really an argument though.

> > Why not always return an error code?
>
> I've received following comment[1] from Andrew:
>
>  "What you have to be careful of, is the return value from your new code
>   looking in NVMEM. It should only return EPROBE_DEFER, or another error
>   if there really is expected to be a value in NVMEM, or getting it from
>   NVMEM resulted in an error."
>
> So in order to fullfil this remark, I can't simply use ENOENT instead of
> current NULL, as the caller couldn't distinguish between ENOENT from
> of_get_mac_address or ENOENT from NVMEM subsystem.

Does it matter? You're trying to put some specific code (nvmem lookup)
behind a generic API, so the fact that you get some nvmem related
errors is more an abstraction leakage than anything else.

And if you don't really like ENOENT, ENODEV is an option as well.

Maxime

--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

Download attachment "signature.asc" of type "application/pgp-signature" (229 bytes)