Larry Finger <Larry.Finger@xxxxxxxxxxxx> writes: > On 2/17/24 23:13, Brent Roman wrote: >> Larry, >> Radxa confirmed that they do not program the eFUSE on these boards. >> We do not get a sensible MAC from the chip, so I derive a one from >> the CPU's unique serial number. >> It's a hack, but it works well and is standard's compliant. >> The RockPI-S a *very* inexpensive board, so I can understand Radxa >> wanting to minimize the time spent configuring each one. >> https://shop.allnetchina.cn/products/rock-pi-s >> The vendor driver seems to deal with this by applying typical gain >> parameters when the eFUSE is invalid. >> With that driver, this board's WiFi performs beautifully, despite >> the unprogrammed eFUSE. >> Would you accept a patch to add this logic to RTW88? > > Of course a patch would be accepted. Ultimately, the changes should be > made to the wireless-next code base, and sent to this mailing list. To > make things easier, you can send me a patch file for the rtw88 repo, > and I can reformat it for wireless-next and send it to the mailing > list under your signed-off-by. Either one would work. > > Thanks for sorting this out. I like the idea of deriving the MAC > address from the CPU serial number. That is unique and reproducible. But make sure that the CPU serial number is really unique. If it's not that can cause MAC address collisions which is not good. Usually wireless drivers create a random address if a stored MAC address is not available. -- https://patchwork.kernel.org/project/linux-wireless/list/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
