Message ID | 1556893635-18549-1-git-send-email-ynezz@true.cz (mailing list archive) |
---|---|
Headers | show |
Series | of_net: Add NVMEM support to of_get_mac_address | expand |
From: Petr Štetiar <ynezz@true.cz> Date: Fri, 3 May 2019 16:27:05 +0200 > this patch series is a continuation of my previous attempt[1], where I've > tried to wire MTD layer into of_get_mac_address, so it would be possible to > load MAC addresses from various NVMEMs as EEPROMs etc. ... Series applied, thank you.
David Miller <davem@davemloft.net> [2019-05-05 21:47:27]:
Hi David,
> Series applied, thank you.
I did probably something terribly wrong, but patch "[PATCH v4 05/10] net:
ethernet: support of_get_mac_address new ERR_PTR error" has not reached the
patchwork, but I'm sure, that it was sent out as Hauke Mehrtens (maintainer
for ethernet/lantiq_xrx200.c) has confirmed to me on IRC, that he has received
it.
I've as well noticed, that you've not considered "[PATCH v5] staging:
octeon-ethernet: support of_get_mac_address new ERR_PTR error"[1] which
contained a fix for possible NULL value of mac variable:
const u8 *mac = NULL;
if (priv->of_node)
mac = of_get_mac_address(priv->of_node);
if (!IS_ERR(mac))
I'll send those two patches again against net-next in a few moments. Sorry for
this mess.
1. https://patchwork.ozlabs.org/patch/1094942/
-- ynezz
Hi Petr, On Mon, 6 May 2019 10:32:07 +0200 Petr Štetiar <ynezz@true.cz> wrote: >David Miller <davem@davemloft.net> [2019-05-05 21:47:27]: > >Hi David, > >> Series applied, thank you. > >I did probably something terribly wrong, but patch "[PATCH v4 05/10] net: >ethernet: support of_get_mac_address new ERR_PTR error" has not reached the >patchwork, but I'm sure, that it was sent out as Hauke Mehrtens (maintainer >for ethernet/lantiq_xrx200.c) has confirmed to me on IRC, that he has received >it. It seems indeed that the 5th patch hasn't beed applied, which effectively breaks mvneta on net-next, and I guess a lot of other drivers that rely on handling the new return values. I saw you sent a followup series fixing that, but only patch 2/3 shows-up on netdev, so you might be facing a similar issue here. Maxime
Maxime Chevallier <maxime.chevallier@bootlin.com> [2019-05-06 16:41:32]: Hi Maxime, > On Mon, 6 May 2019 10:32:07 +0200 > Petr Štetiar <ynezz@true.cz> wrote: > > >David Miller <davem@davemloft.net> [2019-05-05 21:47:27]: > > > >Hi David, > > > >> Series applied, thank you. > > > >I did probably something terribly wrong, but patch "[PATCH v4 05/10] net: > >ethernet: support of_get_mac_address new ERR_PTR error" has not reached the > >patchwork, but I'm sure, that it was sent out as Hauke Mehrtens (maintainer > >for ethernet/lantiq_xrx200.c) has confirmed to me on IRC, that he has received > >it. > > It seems indeed that the 5th patch hasn't beed applied, which effectively > breaks mvneta on net-next, and I guess a lot of other drivers that rely > on handling the new return values. Yep, sorry for that. > I saw you sent a followup series fixing that, but only patch 2/3 > shows-up on netdev, so you might be facing a similar issue here. Indeed, seems like patchwork hiccup with a long list of recepients in the To/Cc headers, so I've just resend it again with only netdev@vger.kernel.org in the To: header and it was happily picked up[1]. 1. https://patchwork.ozlabs.org/project/netdev/list/?series=106369 -- ynezz
On Sun, May 5, 2019 at 11:47 PM David Miller <davem@davemloft.net> wrote: > > From: Petr Štetiar <ynezz@true.cz> > Date: Fri, 3 May 2019 16:27:05 +0200 > > > this patch series is a continuation of my previous attempt[1], where I've > > tried to wire MTD layer into of_get_mac_address, so it would be possible to > > load MAC addresses from various NVMEMs as EEPROMs etc. > ... > > Series applied, thank you. Patch 1 at least is still be discussed. What was implemented based on my comments on v2 is really broken. Now the allocated buffer is tracked by both devm and DT refcounting. Whoever's ref count drops first will free the buffer. Rob