On 8/8/2025 8:15 PM, Rosen Penev wrote: > In 9d5804662ce1f9bdde0a14c3c40940acbbf09538 , device_get_mac_address was see https://www.kernel.org/doc/html/latest/process/submitting-patches.html#describe-your-changes specifically: If you want to refer to a specific commit, don’t just refer to the SHA-1 ID of the commit. Please also include the oneline summary of the commit, to make it easier for reviewers to know what it is about. So in this case: 9d5804662ce1 ("ath10k: retrieve MAC address from system firmware if provided") > introduced as a generic way to get MAC addresses from anywhere. > Unfortunately since then, the landscape has changed and the OF version when did the landscape change? if using device_get_mac_address() is breaking folks, it would be nice to know which versions of the kernel have the bad behavior so that the patch can be backported to any broken LTS kernels. > is required for NVMEM support. The second problem is that with NVMEM > it's possible that it loads after ath10k. For that reason, check for > deferred errors and exit out of probe in such a case. > > Signed-off-by: Rosen Penev <rosenp@xxxxxxxxx> > --- > drivers/net/wireless/ath/ath10k/core.c | 5 ++++- > 1 file changed, 4 insertions(+), 1 deletion(-) > > diff --git a/drivers/net/wireless/ath/ath10k/core.c b/drivers/net/wireless/ath/ath10k/core.c > index 6f78f1752cd6..76747eb0925b 100644 > --- a/drivers/net/wireless/ath/ath10k/core.c > +++ b/drivers/net/wireless/ath/ath10k/core.c > @@ -11,6 +11,7 @@ > #include <linux/module.h> > #include <linux/firmware.h> > #include <linux/of.h> > +#include <linux/of_net.h> > #include <linux/property.h> > #include <linux/dmi.h> > #include <linux/ctype.h> > @@ -3456,7 +3457,9 @@ static int ath10k_core_probe_fw(struct ath10k *ar) > ath10k_debug_print_board_info(ar); > } > > - device_get_mac_address(ar->dev, ar->mac_addr); > + ret = of_get_mac_address(ar->dev->of_node, ar->mac_addr); > + if (ret == -EPROBE_DEFER) > + goto err_free_firmware_files; Note a similar proposal for ath11k was deferred since it seems to break x86 attachment when there isn't a device tree node: https://msgid.link/ec974dc0-962b-f611-7bbb-c07a3872f70f@xxxxxxxxxxxxxxxx I'd have the same concerns here. (but I didn't dig into how the fwnode items are set if there isn't a DT) > > ret = ath10k_core_init_firmware_features(ar); > if (ret) {
