device_get_mac_address is a generic way to get the MAC address which
lacks NVMEM support, which tends to be used on embedded platforms.

In case device_get_mac_address fails, try of_get_mac_address_nvmem and
handle EPROBE_DEFER to wait for the nvmem driver to initialize.

Signed-off-by: Rosen Penev <rosenp@gmail.com>
---
 v2: keep device_get_mac_address and use of_get_mac_address_nvmem
 added Miquel to CC. Maybe he has insight.
 drivers/net/wireless/ath/ath10k/core.c | 7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/net/wireless/ath/ath10k/core.c b/drivers/net/wireless/ath/ath10k/core.c
index 6f78f1752cd6..8214b0c0ea80 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,11 @@ static int ath10k_core_probe_fw(struct ath10k *ar)
 		ath10k_debug_print_board_info(ar);
 	}
 
-	device_get_mac_address(ar->dev, ar->mac_addr);
+	if (device_get_mac_address(ar->dev, ar->mac_addr)) {
+		ret = of_get_mac_address_nvmem(ar->dev->of_node, ar->mac_addr);
+		if (ret == -EPROBE_DEFER)
+			goto err_free_firmware_files;
+	}
 
 	ret = ath10k_core_init_firmware_features(ar);
 	if (ret) {
-- 
2.50.1

Hi Rosen,

On 11/08/2025 at 13:34:51 -07, Rosen Penev <rosenp@gmail.com> wrote:

> device_get_mac_address is a generic way to get the MAC address which
> lacks NVMEM support, which tends to be used on embedded platforms.
>
> In case device_get_mac_address fails, try of_get_mac_address_nvmem and
> handle EPROBE_DEFER to wait for the nvmem driver to initialize.
>
> Signed-off-by: Rosen Penev <rosenp@gmail.com>
> ---
>  v2: keep device_get_mac_address and use of_get_mac_address_nvmem
>  added Miquel to CC. Maybe he has insight.

LGTM. I guess it is not possible to make this fallback "the default" in
device_get_mac_address()? In this case doing it in your driver seems
fine if it's used on embedded systems with NVMEM cells described to
store MAC addresses.

Cheers,
Miquèl

On Mon, Aug 18, 2025 at 12:59 AM Miquel Raynal
<miquel.raynal@bootlin.com> wrote:
>
> Hi Rosen,
>
> On 11/08/2025 at 13:34:51 -07, Rosen Penev <rosenp@gmail.com> wrote:
>
> > device_get_mac_address is a generic way to get the MAC address which
> > lacks NVMEM support, which tends to be used on embedded platforms.
> >
> > In case device_get_mac_address fails, try of_get_mac_address_nvmem and
> > handle EPROBE_DEFER to wait for the nvmem driver to initialize.
> >
> > Signed-off-by: Rosen Penev <rosenp@gmail.com>
> > ---
> >  v2: keep device_get_mac_address and use of_get_mac_address_nvmem
> >  added Miquel to CC. Maybe he has insight.
>
> LGTM. I guess it is not possible to make this fallback "the default" in
> device_get_mac_address()? In this case doing it in your driver seems
> fine if it's used on embedded systems with NVMEM cells described to
> store MAC addresses.
In retrospect, it probably makes sense to just switch to of_get_mac_address.

The prior assertion that this could break ACPI embedded systems seems
false. ath10k is too new for that.
>
> Cheers,
> Miquèl