Messages in this thread | | | Subject | Re: [PATCH] ethernet: aquantia: Try MAC address from device tree | From | Hector Martin <> | Date | Thu, 2 Dec 2021 14:10:49 +0900 |
| |
On 30/11/2021 11.32, Andrew Lunn wrote: > On Mon, Nov 29, 2021 at 02:08:28AM +0900, Hector Martin wrote: >> On 29/11/2021 01.33, Andrew Lunn wrote: >>> On Sat, Nov 27, 2021 at 08:37:33PM -0600, Tianhao Chai wrote: >>>> Apple M1 Mac minis (2020) with 10GE NICs do not have MAC address in the >>>> card, but instead need to obtain MAC addresses from the device tree. In >>>> this case the hardware will report an invalid MAC. >>>> >>>> Currently atlantic driver does not query the DT for MAC address and will >>>> randomly assign a MAC if the NIC doesn't have a permanent MAC burnt in. >>>> This patch causes the driver to perfer a valid MAC address from OF (if >>>> present) over HW self-reported MAC and only fall back to a random MAC >>>> address when neither of them is valid. >>> >>> This is a change in behaviour, and could cause regressions. It would >>> be better to keep with the current flow. Call >>> aq_fw_ops->get_mac_permanent() first. If that does not give a valid >>> MAC address, then try DT, and lastly use a random MAC address. >> >> 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?
I don't think this is explicitly clarified anywhere, but the DT binding says:
> Specifies the MAC address that was assigned to the network device.
It certainly doesn't say this should be a fallback only to be used if the device doesn't have some idea of its MAC. Usually you'd expect firmware information to override whatever the device's built-in defaults are.
>> I would not expect any other existing platform to have a MAC assigned to the >> device in this way using these cards; if any platforms do, chances are they >> intended it for it to be used and this patch will fix a current bug. If some >> platforms out there really have bogus MACs assigned in this way, that's a >> firmware bug, and we'd have to find out and add explicit, targeted >> workaround code. Are you aware of any such platforms? :) > > I'm not aware of any, because i try to avoid making behaviour changes. > > Anyway, lets go with this, and if stuff breaks we can always change > the order to what i suggested in order to unbreak stuff. I'm assuming > for Apple M1 Mac minis the order does not actually matter?
Correct, on these machines the burned-in MAC is invalid so it doesn't matter.
-- Hector Martin (marcan@marcan.st) Public Key: https://mrcn.st/pub
| |