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] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAKxU2N-0Q2uxw=-v-XP8g=Y=yBb2ufv+T0yk7dmaszwUy8Z6tg@mail.gmail.com>
Date: Wed, 20 Aug 2025 23:51:43 -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 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?
>
> Vasanth