[PATCH net-next v2 0/4] of_get_mac_address ERR_PTR fixes

[PATCH net-next v2 0/4] of_get_mac_address ERR_PTR fixes

[Petr Štetiar]

Hi,

this patch series is an attempt to fix the mess, I've somehow managed to
introduce.

First patch in this series is defacto v5 of the previous 05/10 patch in the
series, but since the v4 of this 05/10 patch wasn't picked up by the
patchwork for some unknown reason, this patch wasn't applied with the other
9 patches in the series, so I'm resending it as a separate patch of this
fixup series again.

Second patch is a result of this rebase against net-next tree, where I was
checking again all current users of of_get_mac_address and found out, that
there's new one in DSA, so I've converted this user to the new ERR_PTR
encoded error value as well.

Third patch which was sent as v5 wasn't considered for merge, but I still
think, that we need to check for possible NULL value, thus current IS_ERR
check isn't sufficient and we need to use IS_ERR_OR_NULL instead.

Fourth patch fixes warning reported by kbuild test robot.

Cheers,

Petr

Petr Štetiar (4):
  net: ethernet: support of_get_mac_address new ERR_PTR error
  net: dsa: support of_get_mac_address new ERR_PTR error
  staging: octeon-ethernet: Fix of_get_mac_address ERR_PTR check
  net: usb: smsc: fix warning reported by kbuild test robot

 drivers/net/ethernet/aeroflex/greth.c                 | 2 +-
 drivers/net/ethernet/allwinner/sun4i-emac.c           | 2 +-
 drivers/net/ethernet/altera/altera_tse_main.c         | 2 +-
 drivers/net/ethernet/arc/emac_main.c                  | 2 +-
 drivers/net/ethernet/aurora/nb8800.c                  | 2 +-
 drivers/net/ethernet/broadcom/bcmsysport.c            | 2 +-
 drivers/net/ethernet/broadcom/bgmac-bcma.c            | 2 +-
 drivers/net/ethernet/broadcom/bgmac-platform.c        | 2 +-
 drivers/net/ethernet/broadcom/genet/bcmgenet.c        | 2 +-
 drivers/net/ethernet/cavium/octeon/octeon_mgmt.c      | 2 +-
 drivers/net/ethernet/cavium/thunder/thunder_bgx.c     | 2 +-
 drivers/net/ethernet/davicom/dm9000.c                 | 2 +-
 drivers/net/ethernet/ethoc.c                          | 2 +-
 drivers/net/ethernet/ezchip/nps_enet.c                | 2 +-
 drivers/net/ethernet/freescale/fec_main.c             | 2 +-
 drivers/net/ethernet/freescale/fec_mpc52xx.c          | 2 +-
 drivers/net/ethernet/freescale/fman/mac.c             | 2 +-
 drivers/net/ethernet/freescale/fs_enet/fs_enet-main.c | 2 +-
 drivers/net/ethernet/freescale/gianfar.c              | 2 +-
 drivers/net/ethernet/freescale/ucc_geth.c             | 2 +-
 drivers/net/ethernet/hisilicon/hisi_femac.c           | 2 +-
 drivers/net/ethernet/hisilicon/hix5hd2_gmac.c         | 2 +-
 drivers/net/ethernet/lantiq_xrx200.c                  | 2 +-
 drivers/net/ethernet/marvell/mv643xx_eth.c            | 2 +-
 drivers/net/ethernet/marvell/mvneta.c                 | 2 +-
 drivers/net/ethernet/marvell/pxa168_eth.c             | 2 +-
 drivers/net/ethernet/marvell/sky2.c                   | 2 +-
 drivers/net/ethernet/mediatek/mtk_eth_soc.c           | 2 +-
 drivers/net/ethernet/micrel/ks8851.c                  | 2 +-
 drivers/net/ethernet/micrel/ks8851_mll.c              | 2 +-
 drivers/net/ethernet/nxp/lpc_eth.c                    | 2 +-
 drivers/net/ethernet/qualcomm/qca_spi.c               | 2 +-
 drivers/net/ethernet/qualcomm/qca_uart.c              | 2 +-
 drivers/net/ethernet/renesas/ravb_main.c              | 2 +-
 drivers/net/ethernet/renesas/sh_eth.c                 | 2 +-
 drivers/net/ethernet/samsung/sxgbe/sxgbe_platform.c   | 2 +-
 drivers/net/ethernet/socionext/sni_ave.c              | 2 +-
 drivers/net/ethernet/stmicro/stmmac/stmmac_main.c     | 2 +-
 drivers/net/ethernet/ti/cpsw.c                        | 2 +-
 drivers/net/ethernet/ti/netcp_core.c                  | 2 +-
 drivers/net/ethernet/wiznet/w5100.c                   | 2 +-
 drivers/net/ethernet/xilinx/ll_temac_main.c           | 2 +-
 drivers/net/ethernet/xilinx/xilinx_axienet_main.c     | 2 +-
 drivers/net/ethernet/xilinx/xilinx_emaclite.c         | 2 +-
 drivers/net/usb/smsc75xx.c                            | 2 +-
 drivers/net/usb/smsc95xx.c                            | 2 +-
 drivers/staging/octeon/ethernet.c                     | 2 +-
 net/dsa/slave.c                                       | 2 +-
 net/ethernet/eth.c                                    | 2 +-
 49 files changed, 49 insertions(+), 49 deletions(-)

-- 
1.9.1

[PATCH net-next v2 2/4] net: dsa: support of_get_mac_address new ERR_PTR error

[Petr Štetiar]

There was NVMEM support added to of_get_mac_address, so it could now
return ERR_PTR encoded error values, so we need to adjust all current
users of of_get_mac_address to this new fact.

While at it, remove superfluous is_valid_ether_addr as the MAC address
returned from of_get_mac_address is always valid and checked by
is_valid_ether_addr anyway.

Fixes: d01f449c008a ("of_net: add NVMEM support to of_get_mac_address")
Signed-off-by: Petr Štetiar <ynezz@true.cz>
---
 net/dsa/slave.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/dsa/slave.c b/net/dsa/slave.c
index 316bce9..fe7b6a6 100644
--- a/net/dsa/slave.c
+++ b/net/dsa/slave.c
@@ -1418,7 +1418,7 @@ int dsa_slave_create(struct dsa_port *port)
 				NETIF_F_HW_VLAN_CTAG_FILTER;
 	slave_dev->hw_features |= NETIF_F_HW_TC;
 	slave_dev->ethtool_ops = &dsa_slave_ethtool_ops;
-	if (port->mac && is_valid_ether_addr(port->mac))
+	if (!IS_ERR_OR_NULL(port->mac))
 		ether_addr_copy(slave_dev->dev_addr, port->mac);
 	else
 		eth_hw_addr_inherit(slave_dev, master);
-- 
1.9.1

[PATCH net-next v2 3/4] staging: octeon-ethernet: Fix of_get_mac_address ERR_PTR check

[Petr Štetiar]

Commit 284eb160681c ("staging: octeon-ethernet: support
of_get_mac_address new ERR_PTR error") has introduced checking for
ERR_PTR encoded error value from of_get_mac_address with IS_ERR macro,
which is not sufficient in this case, as the mac variable is set to NULL
initialy and if the kernel is compiled without DT support this NULL
would get passed to IS_ERR, which would lead to the wrong decision and
would pass that NULL pointer and invalid MAC address further.

Fixes: 284eb160681c ("staging: octeon-ethernet: support of_get_mac_address new ERR_PTR error")
Signed-off-by: Petr Štetiar <ynezz@true.cz>
---
 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 2b03018..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 (!IS_ERR(mac))
+	if (!IS_ERR_OR_NULL(mac))
 		ether_addr_copy(dev->dev_addr, mac);
 	else
 		eth_hw_addr_random(dev);
-- 
1.9.1

[PATCH net-next v2 4/4] net: usb: smsc: fix warning reported by kbuild test robot

[Petr Štetiar]

This patch fixes following warning reported by kbuild test robot:

 In function ‘memcpy’,
     inlined from ‘smsc75xx_init_mac_address’ at drivers/net/usb/smsc75xx.c:778:3,
     inlined from ‘smsc75xx_bind’ at drivers/net/usb/smsc75xx.c:1501:2:
 ./include/linux/string.h:355:9: warning: argument 2 null where non-null expected [-Wnonnull]
   return __builtin_memcpy(p, q, size);
          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
 drivers/net/usb/smsc75xx.c: In function ‘smsc75xx_bind’:
 ./include/linux/string.h:355:9: note: in a call to built-in function ‘__builtin_memcpy’

I've replaced the offending memcpy with ether_addr_copy, because I'm
100% sure, that of_get_mac_address can't return NULL as it returns valid
pointer or ERR_PTR encoded value, nothing else.

I'm hesitant to just change IS_ERR into IS_ERR_OR_NULL check, as this
would make the warning disappear also, but it would be confusing to
check for impossible return value just to make a compiler happy.

Fixes: adfb3cb2c52e ("net: usb: support of_get_mac_address new ERR_PTR error")
Reported-by: kbuild test robot <lkp@intel.com>
Signed-off-by: Petr Štetiar <ynezz@true.cz>
---
 drivers/net/usb/smsc75xx.c | 2 +-
 drivers/net/usb/smsc95xx.c | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/net/usb/smsc75xx.c b/drivers/net/usb/smsc75xx.c
index d27b627..e4c2f3a 100644
--- a/drivers/net/usb/smsc75xx.c
+++ b/drivers/net/usb/smsc75xx.c
@@ -775,7 +775,7 @@ static void smsc75xx_init_mac_address(struct usbnet *dev)
 	/* maybe the boot loader passed the MAC address in devicetree */
 	mac_addr = of_get_mac_address(dev->udev->dev.of_node);
 	if (!IS_ERR(mac_addr)) {
-		memcpy(dev->net->dev_addr, mac_addr, ETH_ALEN);
+		ether_addr_copy(dev->net->dev_addr, mac_addr);
 		return;
 	}
 
diff --git a/drivers/net/usb/smsc95xx.c b/drivers/net/usb/smsc95xx.c
index ab23911..a0e1199 100644
--- a/drivers/net/usb/smsc95xx.c
+++ b/drivers/net/usb/smsc95xx.c
@@ -918,7 +918,7 @@ static void smsc95xx_init_mac_address(struct usbnet *dev)
 	/* maybe the boot loader passed the MAC address in devicetree */
 	mac_addr = of_get_mac_address(dev->udev->dev.of_node);
 	if (!IS_ERR(mac_addr)) {
-		memcpy(dev->net->dev_addr, mac_addr, ETH_ALEN);
+		ether_addr_copy(dev->net->dev_addr, mac_addr);
 		return;
 	}
 
-- 
1.9.1

RE: [PATCH net-next v2 4/4] net: usb: smsc: fix warning reported by kbuild test robot

[Woojung.Huh]

> This patch fixes following warning reported by kbuild test robot:
> 
>  In function ‘memcpy’,
>      inlined from ‘smsc75xx_init_mac_address’ at drivers/net/usb/smsc75xx.c:778:3,
>      inlined from ‘smsc75xx_bind’ at drivers/net/usb/smsc75xx.c:1501:2:
>  ./include/linux/string.h:355:9: warning: argument 2 null where non-null expected [-Wnonnull]
>    return __builtin_memcpy(p, q, size);
>           ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
>  drivers/net/usb/smsc75xx.c: In function ‘smsc75xx_bind’:
>  ./include/linux/string.h:355:9: note: in a call to built-in function ‘__builtin_memcpy’
> 
> I've replaced the offending memcpy with ether_addr_copy, because I'm
> 100% sure, that of_get_mac_address can't return NULL as it returns valid
> pointer or ERR_PTR encoded value, nothing else.
> 
> I'm hesitant to just change IS_ERR into IS_ERR_OR_NULL check, as this
> would make the warning disappear also, but it would be confusing to
> check for impossible return value just to make a compiler happy.
> 
> Fixes: adfb3cb2c52e ("net: usb: support of_get_mac_address new ERR_PTR error")
> Reported-by: kbuild test robot <lkp@intel.com>
> Signed-off-by: Petr Štetiar <ynezz@true.cz>
> ---

Reviewed-by: Woojung Huh <woojung.huh@microchip.com>

Re: [PATCH net-next v2 0/4] of_get_mac_address ERR_PTR fixes

[Dan Carpenter]

On Mon, May 06, 2019 at 11:24:43PM +0200, Petr Štetiar wrote:
> Hi,
> 
> this patch series is an attempt to fix the mess, I've somehow managed to
> introduce.
> 
> First patch in this series is defacto v5 of the previous 05/10 patch in the
> series, but since the v4 of this 05/10 patch wasn't picked up by the
> patchwork for some unknown reason, this patch wasn't applied with the other
> 9 patches in the series, so I'm resending it as a separate patch of this
> fixup series again.

I feel sort of ridiculous asking this over and over...  Maybe your spam
filter is eating my emails?

This bug was introduced in https://patchwork.ozlabs.org/patch/1094916/
"[v4,01/10] of_net: add NVMEM support to of_get_mac_address" but it
looks like no one applied it.

You're acting as if it *was* applied but you refuse to answer my
question who applied it and which to which tree so I can figure out what
went wrong.

I only see comments from last Friday that it shouldn't be applied...  I
also told you on Friday in a different thread that that patch shouldn't
be applied.  Breaking git bisect is a bug, and we never do that.  I'm
just very confused right now...  What I'm trying to do is figure out in
my head how this process failed so we can do better next time.

regards,
dan carpenter

Re: [PATCH net-next v2 0/4] of_get_mac_address ERR_PTR fixes

[Greg Kroah-Hartman]

On Tue, May 07, 2019 at 10:19:14AM +0300, Dan Carpenter wrote:
> On Mon, May 06, 2019 at 11:24:43PM +0200, Petr Štetiar wrote:
> > Hi,
> > 
> > this patch series is an attempt to fix the mess, I've somehow managed to
> > introduce.
> > 
> > First patch in this series is defacto v5 of the previous 05/10 patch in the
> > series, but since the v4 of this 05/10 patch wasn't picked up by the
> > patchwork for some unknown reason, this patch wasn't applied with the other
> > 9 patches in the series, so I'm resending it as a separate patch of this
> > fixup series again.
> 
> I feel sort of ridiculous asking this over and over...  Maybe your spam
> filter is eating my emails?
> 
> This bug was introduced in https://patchwork.ozlabs.org/patch/1094916/
> "[v4,01/10] of_net: add NVMEM support to of_get_mac_address" but it
> looks like no one applied it.
> 
> You're acting as if it *was* applied but you refuse to answer my
> question who applied it and which to which tree so I can figure out what
> went wrong.
> 
> I only see comments from last Friday that it shouldn't be applied...  I
> also told you on Friday in a different thread that that patch shouldn't
> be applied.  Breaking git bisect is a bug, and we never do that.  I'm
> just very confused right now...  What I'm trying to do is figure out in
> my head how this process failed so we can do better next time.

Just to resend this, so that it hopefully does _not_ get stuck in a spam
filter.

Petr, please address Dan's comments, do not ignore them.

greg k-h

Re: [PATCH net-next v2 0/4] of_get_mac_address ERR_PTR fixes

[Petr Štetiar]

Dan Carpenter <dan.carpenter@oracle.com> [2019-05-07 10:19:14]:

Hi,

> On Mon, May 06, 2019 at 11:24:43PM +0200, Petr Štetiar wrote:
> > 
> > this patch series is an attempt to fix the mess, I've somehow managed to
> > introduce.
> > 
> > First patch in this series is defacto v5 of the previous 05/10 patch in the
> > series, but since the v4 of this 05/10 patch wasn't picked up by the
> > patchwork for some unknown reason, this patch wasn't applied with the other
> > 9 patches in the series, so I'm resending it as a separate patch of this
> > fixup series again.
> 
> I feel sort of ridiculous asking this over and over...  Maybe your spam
> filter is eating my emails?

nope, I've read your email, that's the only reason I've sent out this v2 which
added Fixes: tag you've suggested in your email.

> This bug was introduced in https://patchwork.ozlabs.org/patch/1094916/
> "[v4,01/10] of_net: add NVMEM support to of_get_mac_address" but it
> looks like no one applied it.

this patch series is against net-next, and I've added Fixes: tag as you've
requested in this v2 series[1] (which expands to commit[2] in net-next):

 Fixes: d01f449c008a ("of_net: add NVMEM support to of_get_mac_address")

> You're acting as if it *was* applied but you refuse to answer my
> question who applied it and which to which tree so I can figure out what
> went wrong.

it was applied[2] to David's net-next tree, but unfortunately partialy, just 9
patches out of 10, as the patch 05/10 in that series (which is patch 1/4 in
this series) never reached netdev mailing list and patchwork, probably because
of some netdev mailing list software and/or patchwork hiccup, very likely due
to the long list of recipients in that patch and as I'm not subscribed to the
netdev (due to the high traffic) I'm probably treaten somehow differently.

So to sum it up, I've simply thought, that it was enough to send out v2 with
that Fixes: tag and considered it done.

> I only see comments from last Friday that it shouldn't be applied...

I'm sorry, but which comments do you mean exactly? Those about the
`nvmem-mac-address` DT (sysfs) entry? If that is the case, from my point of
view, I've provided reasonable arguments and nobody told me, that I'm wrong
with my reasoning or NACKed this explicitly, so David probably considered my
arguments good enough and merged it as it is? I don't have any other
explanation.

> I also told you on Friday in a different thread that that patch shouldn't be
> applied.  Breaking git bisect is a bug, and we never do that. 

Yes, and I agree with you, but I've simply thought, that if any of the
maintainers who previously reviewed the series didn't objected about this,
that they're possibly going to squash those patches by themselves during the
merging process or that they're going to tell me to do so and I would address
this in the latest interation of the patchset before merge.

Anyway, is there any possibility how to fix that now?

> I'm just very confused right now.  What I'm trying to do is figure out in
> my head how this process failed so we can do better next time.

I'm just occasional contributor, so I'm sorry, but I can hardly provide any
input.

1. https://patchwork.ozlabs.org/patch/1096054/
2. https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git/commit/?id=d01f449c008a3f41fa44c603e28a7452ab8f8e68

Cheers,

Petr

netdev patchwork issues [Was: Re: [PATCH net-next v2 0/4] of_get_mac_address ERR_PTR fixes]

[Petr Štetiar]

Petr Štetiar <ynezz@true.cz> [2019-05-07 10:39:18]:

[adding Jeremy to the Cc: loop]

> it was applied[2] to David's net-next tree, but unfortunately partialy, just 9
> patches out of 10, as the patch 05/10 in that series (which is patch 1/4 in
> this series) never reached netdev mailing list and patchwork, probably because
> of some netdev mailing list software and/or patchwork hiccup, very likely due
> to the long list of recipients in that patch and as I'm not subscribed to the
> netdev (due to the high traffic) I'm probably treaten somehow differently.

For the record, I've following in my ~/.gitconfig:

 [sendemail.linux]
    tocmd ="`pwd`/scripts/get_maintainer.pl --nogit --nogit-fallback --norolestats --nol"
    cccmd ="`pwd`/scripts/get_maintainer.pl --nogit --nogit-fallback --norolestats --nom"

and I've sent the patches with the following command:

 git send-email \
	--to netdev@vger.kernel.org \
	--to 'David S. Miller <davem@davemloft.net>' \
	--cc 'Andrew Lunn <andrew@lunn.ch>' \
	--cc 'Florian Fainelli <f.fainelli@gmail.com>' \
	--cc 'Heiner Kallweit <hkallweit1@gmail.com>' \
	--cc 'Frank Rowand <frowand.list@gmail.com>' \
	--cc 'devel@driverdev.osuosl.org' \
	--cc 'linux-kernel@vger.kernel.org' \
	--cc 'Greg Kroah-Hartman <gregkh@linuxfoundation.org>' \
	--cc 'Maxime Ripard <maxime.ripard@bootlin.com>' \
	--identity linux tmp/nvmem-fix-v2/000*

which resulted just in the following 4 bounces:

 * nbd@openwrt.org (no such recipient)
 * ks.giri@samsung.com (no such recipient)
 * vipul.pandya@samsung.com (no such recipient)

 Your mail to 'linux-arm-kernel' with the subject

    [PATCH net-next v2 1/4] net: ethernet: support of_get_mac_address new ERR_PTR error

 Is being held until the list moderator can review it for approval.  The reason
 it is being held:

    Too many recipients to the message

So maybe netdev have similar moderation stuff enabled, but doesn't send out
this notices back? I've "fixed" the issue with the following workaround:

 git send-email \
 	--to netdev@vger.kernel.org \
	--in-reply-to '<1557177887-30446-1-git-send-email-ynezz@true.cz>' \
	tmp/nvmem-fix-v2/0001-net-ethernet-support-of_get_mac_address-new-ERR_PTR-.patch

That is, just using netdev as the sole recipient and then the patch has
appeared in the patchwork and in the mailing list archive as well.

-- ynezz

Re: [PATCH net-next v2 0/4] of_get_mac_address ERR_PTR fixes

[Geert Uytterhoeven]

Hi Petr,

On Mon, May 6, 2019 at 11:25 PM Petr Štetiar <ynezz@true.cz> wrote:
> this patch series is an attempt to fix the mess, I've somehow managed to
> introduce.
>
> First patch in this series is defacto v5 of the previous 05/10 patch in the
> series, but since the v4 of this 05/10 patch wasn't picked up by the
> patchwork for some unknown reason, this patch wasn't applied with the other
> 9 patches in the series, so I'm resending it as a separate patch of this
> fixup series again.
>
> Second patch is a result of this rebase against net-next tree, where I was
> checking again all current users of of_get_mac_address and found out, that
> there's new one in DSA, so I've converted this user to the new ERR_PTR
> encoded error value as well.
>
> Third patch which was sent as v5 wasn't considered for merge, but I still
> think, that we need to check for possible NULL value, thus current IS_ERR
> check isn't sufficient and we need to use IS_ERR_OR_NULL instead.
>
> Fourth patch fixes warning reported by kbuild test robot.
>
> Cheers,
>
> Petr
>
> Petr Štetiar (4):
>   net: ethernet: support of_get_mac_address new ERR_PTR error

I didn't receive the patch through email, but patchwork does have it:
https://patchwork.ozlabs.org/patch/1096054/

This fixes the crash ("Unable to handle kernel paging request atvirtual
address fffffffe") I'm seeing with sh_eth on r8a7791/koelsch, so

Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH net-next v2 0/4] of_get_mac_address ERR_PTR fixes

[Dan Carpenter]

Oh crap.  You did add a Fixes tag.  My bad.

I should have been more clear/pro-active on Friday and we could have
avoided this...  Next time.

regards,
dan carpenter

Re: [PATCH net-next v2 0/4] of_get_mac_address ERR_PTR fixes

[Leonard Crestez]

On 07.05.2019 00:25, Petr Štetiar wrote:
> Hi,
> 
> this patch series is an attempt to fix the mess, I've somehow managed to
> introduce.
> 
> First patch in this series is defacto v5 of the previous 05/10 patch in the
> series, but since the v4 of this 05/10 patch wasn't picked up by the
> patchwork for some unknown reason, this patch wasn't applied with the other
> 9 patches in the series, so I'm resending it as a separate patch of this
> fixup series again.
> 
> Second patch is a result of this rebase against net-next tree, where I was
> checking again all current users of of_get_mac_address and found out, that
> there's new one in DSA, so I've converted this user to the new ERR_PTR
> encoded error value as well.
> 
> Third patch which was sent as v5 wasn't considered for merge, but I still
> think, that we need to check for possible NULL value, thus current IS_ERR
> check isn't sufficient and we need to use IS_ERR_OR_NULL instead.
> 
> Fourth patch fixes warning reported by kbuild test robot.
> 
> Cheers,
> 
> Petr
> 
> Petr Štetiar (4):
>    net: ethernet: support of_get_mac_address new ERR_PTR error
>    net: dsa: support of_get_mac_address new ERR_PTR error
>    staging: octeon-ethernet: Fix of_get_mac_address ERR_PTR check
>    net: usb: smsc: fix warning reported by kbuild test robot

>   drivers/net/ethernet/freescale/fec_main.c             | 2 +-

This fixes netboot on imx (probably all of them).

Tested-by: Leonard Crestez <leonard.crestez@nxp.com>

But shouldn't "support of_get_mac_address new ERR_PTR error" somehow be 
reordered so that it's done before allowing non-null errors from 
of_get_mac_address?

Otherwise it will break bisect for many people.

--
Regards,
Leonard

Re: [PATCH net-next v2 2/4] net: dsa: support of_get_mac_address new ERR_PTR error

[Vladimir Oltean]

On Tue, 7 May 2019 at 00:26, Petr Štetiar <ynezz@true.cz> wrote:
>
> There was NVMEM support added to of_get_mac_address, so it could now
> return ERR_PTR encoded error values, so we need to adjust all current
> users of of_get_mac_address to this new fact.
>
> While at it, remove superfluous is_valid_ether_addr as the MAC address
> returned from of_get_mac_address is always valid and checked by
> is_valid_ether_addr anyway.
>
> Fixes: d01f449c008a ("of_net: add NVMEM support to of_get_mac_address")
> Signed-off-by: Petr Štetiar <ynezz@true.cz>
> ---
>  net/dsa/slave.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/net/dsa/slave.c b/net/dsa/slave.c
> index 316bce9..fe7b6a6 100644
> --- a/net/dsa/slave.c
> +++ b/net/dsa/slave.c
> @@ -1418,7 +1418,7 @@ int dsa_slave_create(struct dsa_port *port)
>                                 NETIF_F_HW_VLAN_CTAG_FILTER;
>         slave_dev->hw_features |= NETIF_F_HW_TC;
>         slave_dev->ethtool_ops = &dsa_slave_ethtool_ops;
> -       if (port->mac && is_valid_ether_addr(port->mac))
> +       if (!IS_ERR_OR_NULL(port->mac))
>                 ether_addr_copy(slave_dev->dev_addr, port->mac);
>         else
>                 eth_hw_addr_inherit(slave_dev, master);
> --
> 1.9.1
>

Tested-by: Vladimir Oltean <olteanv@gmail.com>

Re: [PATCH net-next v2 0/4] of_get_mac_address ERR_PTR fixes

[David Miller]

From: Petr Štetiar <ynezz@true.cz>
Date: Mon,  6 May 2019 23:24:43 +0200

> this patch series is an attempt to fix the mess, I've somehow managed to
> introduce.
> 
> First patch in this series is defacto v5 of the previous 05/10 patch in the
> series, but since the v4 of this 05/10 patch wasn't picked up by the
> patchwork for some unknown reason, this patch wasn't applied with the other
> 9 patches in the series, so I'm resending it as a separate patch of this
> fixup series again.
> 
> Second patch is a result of this rebase against net-next tree, where I was
> checking again all current users of of_get_mac_address and found out, that
> there's new one in DSA, so I've converted this user to the new ERR_PTR
> encoded error value as well.
> 
> Third patch which was sent as v5 wasn't considered for merge, but I still
> think, that we need to check for possible NULL value, thus current IS_ERR
> check isn't sufficient and we need to use IS_ERR_OR_NULL instead.
> 
> Fourth patch fixes warning reported by kbuild test robot.

Series applied, thanks.