linux-kernel - Re: [PATCH ath-next] wifi: ath11k: switch to of_get_mac

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CAKxU2N_=mqneTUSxaaeN=i_DpQB_ejCb37588bUqagj9_TmdMg@mail.gmail.com>
Date: Thu, 21 Aug 2025 15:19:12 -0700
From: Rosen Penev <rosenp@...il.com>
To: Vasanthakumar Thiagarajan <vasanthakumar.thiagarajan@....qualcomm.com>
Cc: linux-wireless@...r.kernel.org, Jeff Johnson <jjohnson@...nel.org>, 
	"open list:QUALCOMM ATHEROS ATH11K WIRELESS DRIVER" <ath11k@...ts.infradead.org>, open list <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH ath-next] wifi: ath11k: switch to of_get_mac_address

On Thu, Aug 21, 2025 at 12:44 AM Vasanthakumar Thiagarajan
<vasanthakumar.thiagarajan@....qualcomm.com> wrote:
>
>
>
> On 8/21/2025 12:21 PM, Rosen Penev wrote:
> > On Wed, Aug 20, 2025 at 10:55 PM Vasanthakumar Thiagarajan
> > <vasanthakumar.thiagarajan@....qualcomm.com> 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@...il.com>
> >>> ---
> >>>    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.