Re: [PATCH ath-next] wifi: ath11k: switch to of_get_mac_address

On Thu, Aug 21, 2025 at 12:44 AM Vasanthakumar Thiagarajan
<[email protected]> wrote:
>
>
>
> On 8/21/2025 12:21 PM, Rosen Penev wrote:
> > On Wed, Aug 20, 2025 at 10:55 PM Vasanthakumar Thiagarajan
> > <[email protected]> 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 <[email protected]>
> >>> ---
> >>>    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.