netdev - Re: [PATCH] net: ftgmac100: support getting MAC address from NVMEM

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <6818bc7ffe07c21d415265c00b00cf32c6d2ac6f.camel@redhat.com>
Date: Tue, 18 Jul 2023 09:15:11 +0200
From: Paolo Abeni <pabeni@...hat.com>
To: Paul Fertser <fercerpav@...il.com>, 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>, 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

On Fri, 2023-07-14 at 08:18 +0300, Paul Fertser wrote:
> 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?

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

Paolo