Hi,
On 7/8/22 20:27, Arend Van Spriel wrote:
> On 7/8/2022 3:37 PM, Hans de Goede wrote:
>> On some boards there is no eeprom to hold the nvram, in this case instead
>> a board specific nvram is loaded from /lib/firmware. On most boards the
>> macaddr=... setting in the /lib/firmware nvram file is ignored because
>> the wifi/bt chip has a unique MAC programmed into the chip itself.
>>
>> But in some cases the actual MAC from the /lib/firmware nvram file gets
>> used, leading to MAC conflicts.
>>
>> The MAC addresses in the troublesome nvram files seem to all come from
>> the same nvram file template, so we can detect this by checking for
>> the template nvram file MAC.
>>
>> Detect that the default MAC address is being used and replace it
>> with a random MAC address to avoid MAC address conflicts.
>>
>> Note that udev will detect this is a random MAC based on
>> /sys/class/net/wlan0/addr_assign_type and then replace this with
>> a MAC based on hashing the netdev-name + the machine-id. So that
>> the MAC address is both guaranteed to be unique per machine while
>> it is still the same/persistent at each boot (assuming the
>> default Link.MACAddressPolicy=persistent udev setting).
>
> Reviewed-by: Arend van Spriel <arend.vanspriel@xxxxxxxxxxxx>
>> Signed-off-by: Hans de Goede <hdegoede@xxxxxxxxxx>
>> ---
>> .../broadcom/brcm80211/brcmfmac/common.c | 23 +++++++++++++++++++
>> 1 file changed, 23 insertions(+)
>>
>> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c
>> index dccd8f4ca1d0..7485e784be2a 100644
>> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c
>> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c
>
> [...]
>
>> @@ -226,6 +240,15 @@ int brcmf_c_preinit_dcmds(struct brcmf_if *ifp)
>> bphy_err(drvr, "Retrieving cur_etheraddr failed, %d\n", err);
>> goto done;
>> }
>> +
>> + if (ether_addr_equal_unaligned(ifp->mac_addr, brcmf_default_mac_address)) {
>
> Is it necessary to use the unaligned variant?
The type is: u8 mac_addr[ETH_ALEN] so there is no guarantee it will
be aligned. Even if it is aligned today, if someone inserts
a struct member in front of it it will end up unaligned.
Regards,
Hans
