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: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20211130044346.GB1416412@cth-desktop-dorm.mad.wi.cth451.me>
Date:   Mon, 29 Nov 2021 22:43:46 -0600
From:   Tianhao Chai <cth451@...il.com>
To:     Andrew Lunn <andrew@...n.ch>
Cc:     Hector Martin <marcan@...can.st>,
        Igor Russkikh <irusskikh@...vell.com>,
        "David S. Miller" <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>, netdev@...r.kernel.org,
        linux-kernel@...r.kernel.org, Sven Peter <sven@...npeter.dev>,
        Alyssa Rosenzweig <alyssa@...enzweig.io>
Subject: Re: [PATCH] ethernet: aquantia: Try MAC address from device tree

On Tue, Nov 30, 2021 at 03:32:10AM +0100, Andrew Lunn wrote:
> On Mon, Nov 29, 2021 at 02:08:28AM +0900, Hector Martin wrote:
> > On DT platforms, it is expected that the device tree MAC will override
> > whatever the device thinks is its MAC address.
> 
> Can you point to any documentation of that expectation?

Since other drivers will prefer DT provided MAC as well, I'd assume
this to be the case, though I'm not sure where this behavior is documented.
I'm new to embedded systems and maybe Hector knows better than I do.

I don't think this will cause regression on platforms that don't even use
DT, say amd64, but could be a change of behavior where DT and NIC both
report valid MACs on OF platforms.

> I'm assuming for Apple M1 Mac minis the order does not actually matter?

The order does not matter in this case. On my M1 mini the hardware
reports an all-zero MAC address. The MAC from DT matches the one printed
on the box, and we should use this one instead.

~cth451

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ