[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190503190730.GH71477@meh.true.cz>
Date: Fri, 3 May 2019 21:07:30 +0200
From: Petr Štetiar <ynezz@...e.cz>
To: Dan Carpenter <dan.carpenter@...cle.com>
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
Dan Carpenter <dan.carpenter@...cle.com> [2019-05-03 13:34:56]:
Hi,
> 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.
this patch is a part of the patch series[1], where the 1st patch[2] adds this
NVMEM support to of_get_mac_address and follow-up patches are adjusting
current of_get_mac_address users to the new ERR_PTR return value.
> Why would of_get_mac_address() return a mix of NULL and error pointers?
I've introduced this misleading API in v3, but corrected it in v4, so it now
returns only valid pointer or ERR_PTR encoded error value.
Just FYI, changes for staging/octeon are currently at v5[3].
1. https://patchwork.ozlabs.org/project/netdev/list/?series=105972
2. https://patchwork.ozlabs.org/patch/1094916/
3. https://patchwork.ozlabs.org/patch/1094942/
-- ynezz
Powered by blists - more mailing lists