Arend Van Spriel <aspriel@xxxxxxxxx> writes: > 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> This is nitpicking but as you are the maintainer could you use Acked-by instead? That way I can immediately see in my patchwork script that a maintainer has acked these and I can take them. Just trying to optimise my workflow :) -- https://patchwork.kernel.org/project/linux-wireless/list/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
