[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190503103456.GF2269@kadam>
Date: Fri, 3 May 2019 13:34:56 +0300
From: Dan Carpenter <dan.carpenter@...cle.com>
To: Petr Štetiar <ynezz@...e.cz>
Cc: netdev@...r.kernel.org, devicetree@...r.kernel.org,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
devel@...verdev.osuosl.org, Andrew Lunn <andrew@...n.ch>,
Florian Fainelli <f.fainelli@...il.com>,
Maxime Ripard <maxime.ripard@...tlin.com>,
linux-kernel@...r.kernel.org,
Srinivas Kandagatla <srinivas.kandagatla@...aro.org>,
Frank Rowand <frowand.list@...il.com>,
Heiner Kallweit <hkallweit1@...il.com>
Subject: Re: [PATCH v3 08/10] staging: octeon-ethernet: support
of_get_mac_address new ERR_PTR error
On Fri, May 03, 2019 at 09:56:05AM +0200, Petr Štetiar wrote:
> There was NVMEM support added to of_get_mac_address, so it could now
> return NULL and ERR_PTR encoded error values, so we need to adjust all
> current users of of_get_mac_address to this new fact.
Which commit added NVMEM support? It hasn't hit net-next or linux-next
yet... Very strange.
Why would of_get_mac_address() return a mix of NULL and error pointers?
In that situation, then NULL is a special kind of success like when you
request feature and the feature works but it's disabled by the user. We
don't want to treat it as an error but we still can't return a pointer
to a feature we don't have... It's hard for me to imagine how that
makes sense for getting a mac address.
At the very least, this patch needs a Fixes tag.
regards,
dan carpenter
Powered by blists - more mailing lists