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
