On 8/21/2025 12:21 PM, Rosen Penev wrote:
On Wed, Aug 20, 2025 at 10:55 PM Vasanthakumar Thiagarajan
<vasanthakumar.thiagarajan@xxxxxxxxxxxxxxxx> wrote:
On 8/21/2025 8:57 AM, Rosen Penev wrote:
This is needed to support nvmem defined MAC addresses in DTS.
In addition, check if the probe should be deferred as nvmem can load
after ath11k.
For brevity, ACPI is not a factor here. ath11k is too new for that.
This may not be accurate, pcie devices are widely used on x86 where
ACPI is not certainly new.
No way ACPI is used to define MAC addresses.
Signed-off-by: Rosen Penev <rosenp@xxxxxxxxx>
---
drivers/net/wireless/ath/ath11k/mac.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/ath11k/mac.c b/drivers/net/wireless/ath/ath11k/mac.c
index 1fadf5faafb8..801db15ca78b 100644
--- a/drivers/net/wireless/ath/ath11k/mac.c
+++ b/drivers/net/wireless/ath/ath11k/mac.c
@@ -9,6 +9,7 @@
#include <linux/etherdevice.h>
#include <linux/bitfield.h>
#include <linux/inetdevice.h>
+#include <linux/of_net.h>
#include <net/if_inet6.h>
#include <net/ipv6.h>
@@ -10434,7 +10435,9 @@ int ath11k_mac_register(struct ath11k_base *ab)
if (ret)
return ret;
- device_get_mac_address(ab->dev, mac_addr);
+ ret = of_get_mac_address(ab->dev->of_node, mac_addr);
I still think it is better to keep the generic API and add the the one specific
to nvmem when the generic one fails.
I don't. ath10k and ath11k are the only modern drivers using
device_get_mac_address
+ if (ret == -EPROBE_DEFER)
+ return ret;
Please note that this error does not impact the device probe as this is
being done in the event path after probe returns withis complete.
Also, this will result in device registration failure even when
the device is not really looking for mac_addr from nvmem (or it is not
there) as firmware can also provide the mac_addr from the hardware.
Does probe not handle EPROBE_DEFER?
right
