Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <6818bc7ffe07c21d415265c00b00cf32c6d2ac6f.camel@redhat.com>
Subject: Re: [PATCH] net: ftgmac100: support getting MAC address from NVMEM
From:   Paolo Abeni <pabeni@redhat.com>
To:     Paul Fertser <fercerpav@gmail.com>,
        Pavan Chebbi <pavan.chebbi@broadcom.com>
Cc:     netdev@vger.kernel.org, "David S. Miller" <davem@davemloft.net>,
        Eric Dumazet <edumazet@google.com>,
        Jakub Kicinski <kuba@kernel.org>, Andrew Lunn <andrew@lunn.ch>,
        Liang He <windhl@126.com>, Geoff Levand <geoff@infradead.org>,
        Leon Romanovsky <leon@kernel.org>,
        Tao Ren <rentao.bupt@gmail.com>,
        Wolfram Sang <wsa+renesas@sang-engineering.com>,
        openbmc@lists.ozlabs.org, linux-kernel@vger.kernel.org
Date:   Tue, 18 Jul 2023 09:15:11 +0200
In-Reply-To: <ZLDas0gsLNkzuUWR@home.paul.comp>
References: <20230713095743.30517-1-fercerpav@gmail.com>
         <CALs4sv08GJXexShzkrhhW5CDSgJC0z3om5YJzy_qYRqEtvyMtg@mail.gmail.com>
         <ZLDas0gsLNkzuUWR@home.paul.comp>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
User-Agent: Evolution 3.46.4 (3.46.4-1.fc37) 
MIME-Version: 1.0
Precedence: bulk

On Fri, 2023-07-14 at 08:18 +0300, Paul Fertser wrote:
> Hello Pavan,
>=20
> On Fri, Jul 14, 2023 at 10:14:02AM +0530, Pavan Chebbi wrote:
> > On Thu, Jul 13, 2023 at 3:28=E2=80=AFPM Paul Fertser <fercerpav@gmail.c=
om> wrote:
> > > Make use of of_get_ethdev_address() to support reading MAC address no=
t
> > > only from the usual DT nodes but also from an NVMEM provider (e.g. us=
ing
> > > a dedicated area in an FRU EEPROM).
> >=20
> > Looks like earlier ftgmac100_probe() would move on with self generated
> > (random) MAC addr if getting it from the device failed.
> > Now you will fail the probe in a failure case. Is that OK?
>=20
> I think the previous behaviour is preserved with this patch in all the
> cases other than of_get_ethdev_address returning -EPROBE_DEFER. Can
> you please explain what failure case you have in mind and how the
> probe is going to be failed in that case?

FTR, I agree with the above: it looks like the old behavior is
preserved. The patch LGTM, thanks!

Paolo