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: <b711072b-11fa-ea33-3a47-d16ad5a9cc62@oss.qualcomm.com>
Date: Thu, 21 Aug 2025 13:14:39 +0530
From: Vasanthakumar Thiagarajan <vasanthakumar.thiagarajan@....qualcomm.com>
To: Rosen Penev <rosenp@...il.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 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