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