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: <86ddae9a-4931-b160-51a2-f89d45d4038d@oss.qualcomm.com>
Date: Thu, 21 Aug 2025 11:25:44 +0530
From: Vasanthakumar Thiagarajan <vasanthakumar.thiagarajan@....qualcomm.com>
To: Rosen Penev <rosenp@...il.com>, linux-wireless@...r.kernel.org
Cc: 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 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.

> 
> 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.

> +	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.

Vasanth