[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZLDas0gsLNkzuUWR@home.paul.comp>
Date: Fri, 14 Jul 2023 08:18:43 +0300
From: Paul Fertser <fercerpav@...il.com>
To: Pavan Chebbi <pavan.chebbi@...adcom.com>
Cc: netdev@...r.kernel.org, "David S. Miller" <davem@...emloft.net>,
Eric Dumazet <edumazet@...gle.com>,
Jakub Kicinski <kuba@...nel.org>,
Paolo Abeni <pabeni@...hat.com>, Andrew Lunn <andrew@...n.ch>,
Liang He <windhl@....com>, Geoff Levand <geoff@...radead.org>,
Leon Romanovsky <leon@...nel.org>,
Tao Ren <rentao.bupt@...il.com>,
Wolfram Sang <wsa+renesas@...g-engineering.com>,
openbmc@...ts.ozlabs.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] net: ftgmac100: support getting MAC address from NVMEM
Hello Pavan,
On Fri, Jul 14, 2023 at 10:14:02AM +0530, Pavan Chebbi wrote:
> On Thu, Jul 13, 2023 at 3:28 PM Paul Fertser <fercerpav@...il.com> wrote:
> > Make use of of_get_ethdev_address() to support reading MAC address not
> > only from the usual DT nodes but also from an NVMEM provider (e.g. using
> > a dedicated area in an FRU EEPROM).
>
> 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?
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?
--
Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software!
mailto:fercerpav@...il.com
Powered by blists - more mailing lists