1. Patchew
  2. linux
  3. View series

[PATCH ath-next] wifi: ath11k: switch to of_get_mac_address

Rosen Penev posted 1 patch 1 month, 1 week ago
There is a newer version of this series
drivers/net/wireless/ath/ath11k/mac.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
[PATCH ath-next] wifi: ath11k: switch to of_get_mac_address
Posted by Rosen Penev 1 month, 1 week ago 
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.

Signed-off-by: Rosen Penev <rosenp@gmail.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);
+	if (ret == -EPROBE_DEFER)
+		return ret;
 
 	for (i = 0; i < ab->num_radios; i++) {
 		pdev = &ab->pdevs[i];
-- 
2.50.1
Re: [PATCH ath-next] wifi: ath11k: switch to of_get_mac_address
Posted by Vasanthakumar Thiagarajan 1 month, 1 week ago 

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@gmail.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
Re: [PATCH ath-next] wifi: ath11k: switch to of_get_mac_address
Posted by Rosen Penev 1 month, 1 week ago 
On Wed, Aug 20, 2025 at 10:55 PM Vasanthakumar Thiagarajan
<vasanthakumar.thiagarajan@oss.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@gmail.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
Re: [PATCH ath-next] wifi: ath11k: switch to of_get_mac_address
Posted by Vasanthakumar Thiagarajan 1 month, 1 week ago 

On 8/21/2025 12:21 PM, Rosen Penev wrote:
> On Wed, Aug 20, 2025 at 10:55 PM Vasanthakumar Thiagarajan
> <vasanthakumar.thiagarajan@oss.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@gmail.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
Re: [PATCH ath-next] wifi: ath11k: switch to of_get_mac_address
Posted by Rosen Penev 1 month, 1 week ago 
On Thu, Aug 21, 2025 at 12:44 AM Vasanthakumar Thiagarajan
<vasanthakumar.thiagarajan@oss.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@oss.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@gmail.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.

Patchew 2.1-devel-b67e4c2

© 2016 - 2025 Red Hat, Inc.