[PATCH] wifi: ath9k: return by of_get_mac_address

[PATCH] wifi: ath9k: return by of_get_mac_address

[Rosen Penev]

It can return -EPROBE_DEFER when using NVMEM. return it so that it gets
forwarded to _init.

Signed-off-by: Rosen Penev <rosenp@gmail.com>
---
 drivers/net/wireless/ath/ath9k/init.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/net/wireless/ath/ath9k/init.c b/drivers/net/wireless/ath/ath9k/init.c
index f9e77c4624d9..8924d49fd8b5 100644
--- a/drivers/net/wireless/ath/ath9k/init.c
+++ b/drivers/net/wireless/ath/ath9k/init.c
@@ -647,9 +647,7 @@ static int ath9k_of_init(struct ath_softc *sc)
 		ah->ah_flags |= AH_NO_EEP_SWAP;
 	}
 
-	of_get_mac_address(np, common->macaddr);
-
-	return 0;
+	return of_get_mac_address(np, common->macaddr);
 }
 
 static int ath9k_init_softc(u16 devid, struct ath_softc *sc,
-- 
2.46.2

Re: [PATCH] wifi: ath9k: return by of_get_mac_address

[Toke Høiland-Jørgensen]

Rosen Penev <rosenp@gmail.com> writes:

> It can return -EPROBE_DEFER when using NVMEM. return it so that it gets
> forwarded to _init.

What bug, if any, does this fix?

-Toke

Re: [PATCH] wifi: ath9k: return by of_get_mac_address

[Rosen Penev]

On Tue, Oct 1, 2024 at 1:27 AM Toke Høiland-Jørgensen <toke@toke.dk> wrote:
>
> Rosen Penev <rosenp@gmail.com> writes:
>
> > It can return -EPROBE_DEFER when using NVMEM. return it so that it gets
> > forwarded to _init.
>
> What bug, if any, does this fix?
None that I've seen. But the goal is: if ath9k probes before NVMEM,
defer so that it can get an NVMEM mac address properly.

I think in OpenWrt there are hacks that force ath9k to probe later, I
think because of the GPIO driver situation there.
>
> -Toke

Re: [PATCH] wifi: ath9k: return by of_get_mac_address

[Toke Høiland-Jørgensen]

Rosen Penev <rosenp@gmail.com> writes:

> On Tue, Oct 1, 2024 at 1:27 AM Toke Høiland-Jørgensen <toke@toke.dk> wrote:
>>
>> Rosen Penev <rosenp@gmail.com> writes:
>>
>> > It can return -EPROBE_DEFER when using NVMEM. return it so that it gets
>> > forwarded to _init.
>>
>> What bug, if any, does this fix?
> None that I've seen. But the goal is: if ath9k probes before NVMEM,
> defer so that it can get an NVMEM mac address properly.
>
> I think in OpenWrt there are hacks that force ath9k to probe later, I
> think because of the GPIO driver situation there.

Right. Please include this rationale in the patch description :)

-Toke