linux-kernel - Re: [PATCH] wifi: ath9k: return by 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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <87ldz6q449.fsf@toke.dk>
Date: Wed, 02 Oct 2024 10:51:50 +0200
From: Toke Høiland-Jørgensen <toke@...e.dk>
To: Rosen Penev <rosenp@...il.com>
Cc: linux-wireless@...r.kernel.org, kvalo@...nel.org, nbd@....name,
 yangshiji66@...look.com, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] wifi: ath9k: return by of_get_mac_address

Rosen Penev <rosenp@...il.com> writes:

> On Tue, Oct 1, 2024 at 1:27 AM Toke Høiland-Jørgensen <toke@...e.dk> wrote:
>>
>> Rosen Penev <rosenp@...il.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