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.
Signed-off-by: Petr Štetiar <[email protected]>
---
drivers/staging/octeon/ethernet.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/octeon/ethernet.c b/drivers/staging/octeon/ethernet.c
index 986db76..8847a11c2 100644
--- a/drivers/staging/octeon/ethernet.c
+++ b/drivers/staging/octeon/ethernet.c
@@ -421,7 +421,7 @@ int cvm_oct_common_init(struct net_device *dev)
if (priv->of_node)
mac = of_get_mac_address(priv->of_node);
- if (mac)
+ if (!IS_ERR_OR_NULL(mac))
ether_addr_copy(dev->dev_addr, mac);
else
eth_hw_addr_random(dev);
--
1.9.1
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
Dan Carpenter <[email protected]> [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
On Fri, May 03, 2019 at 09:07:30PM +0200, Petr Štetiar wrote:
> Dan Carpenter <[email protected]> [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.
Basically all the patches need to be folded together otherwise you're
breaking git bisectibility. Imagine that we just apply patch #1 right?
Then all the callers will be broken. It's not allowed.
regards,
dan carpenter