linux-kernel - Re: [RFC PATCH v2 0/2] wifi: Nordic nRF70 series

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <4854f6a248fdc501d4157339fdb21f9a3ca3097d.camel@sipsolutions.net>
Date: Fri, 25 Apr 2025 20:11:22 +0200
From: Johannes Berg <johannes@...solutions.net>
To: Artur Rojek <artur@...clusive.pl>, Rob Herring <robh@...nel.org>, 
 Krzysztof Kozlowski
	 <krzk+dt@...nel.org>, Conor Dooley <conor+dt@...nel.org>, Liam Girdwood
	 <lgirdwood@...il.com>, Mark Brown <broonie@...nel.org>, Sascha Hauer
	 <s.hauer@...gutronix.de>
Cc: linux-wireless@...r.kernel.org, devicetree@...r.kernel.org, 
	linux-kernel@...r.kernel.org, Jakub Klama <jakub@...clusive.pl>, Wojciech
 Kloska	 <wojciech@...clusive.pl>, Ulf Axelsson <ulf.axelsson@...dicsemi.no>
Subject: Re: [RFC PATCH v2 0/2] wifi: Nordic nRF70 series

On Tue, 2025-04-22 at 19:59 +0200, Artur Rojek wrote:
> 1) Nordic gave us permission to upstream the firmware blob [1] required
>    to use this driver. As that needs to go through separate
>    linux-firmware repository and is subject to different licensing,
>    should I try to upstream it in parallel with this series, or does it
>    need to wait until the kernel driver gets in?

I have no idea. Chicken and egg, I guess.

> 2) In AP mode, for each connected peer I maintain a pending queue for TX
>    skbs that can't be transmitted while the peer is in power save mode.
>    I then use a wiphy_work (nrf70_pending_worker) to move the collected
>    skbs into a single hw queue once the peer is able to receive again.
>    This means there can be multiple workers putting skbs onto the hw
>    queue at any given time. As this scheme relies on the wiphy_work
>    workqueue, can I assume that multiple workers will be able to run in
>    parallel, even on a system with a single CPU? If not, what would be
>    a better solution to the above problem?

wiphy_work() is fully serialized regardless of the number of CPUs, it's
guaranteed that the wiphy mutex is held for the work execution, after
all.

johannes