On Thu, Aug 21, 2025 at 12:44 AM Vasanthakumar Thiagarajan <vasanthakumar.thiagarajan@xxxxxxxxxxxxxxxx> wrote: > > > > 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 I looked further into this. The function ends up being called in _probe as ath11k_core_init , which doesn't seem to pass the return code of of_get_mac_address as it currently stands. Unfortunate.
