Hi all, this is v2 of the Nordic nRF70 series. The order of patches has been swapped to reflect the Device Tree submission rules (bindings before implementation). I also replaced the 'net: wireless:' prefix with 'wifi:' for the series, so hopefully this time it correctly shows up in Patchwork. Patch [1/2] now resolves all issues uncovered by dt_binding_check. All gpio based properties have also been replaced with *-supply and interrupts properties, where appropriate, and their usage clarified in respective description fields. Patch [2/2] addresses the same gpio usage concerns, now utilizing the regulator API. Another major change is migration of nrf7002_qfn_rf_params from being an array into a struct, in order to better access its individual fields. All the remaining concerns from v1 have been addressed as well. As this is RFC, and none of my questions from v1 have been answered, I will feature them again, while also adding a new one: 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? 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? 3) nRF70 hardware communicates using byte packed, little-endian payloads (documented in nrf70_cmds.h). As these can get very large and complicated, I decided against writing some sort of endianness conversion scheme, and simply dropped big endian support by this driver. Is that acceptable? 4) Please put particular attention to the wiphy configuration. I am not 100% confident I got all the flags/features/band caps right. 5) Should I add myself to the MAINTAINERS file regarding this driver, or is that not mandatory? Cheers, Artur [1] https://github.com/nrfconnect/sdk-nrfxlib/raw/refs/heads/main/nrf_wifi/bin/ncs/default/nrf70.bin Artur Rojek (2): dt-bindings: wifi: Add support for Nordic nRF70 wifi: Add Nordic nRF70 series Wi-Fi driver .../bindings/net/wireless/nordic,nrf70.yaml | 71 + drivers/net/wireless/Kconfig | 1 + drivers/net/wireless/Makefile | 1 + drivers/net/wireless/nordic/Kconfig | 26 + drivers/net/wireless/nordic/Makefile | 3 + drivers/net/wireless/nordic/nrf70.c | 4703 +++++++++++++++++ drivers/net/wireless/nordic/nrf70_cmds.h | 1137 ++++ drivers/net/wireless/nordic/nrf70_rf_params.h | 65 + 8 files changed, 6007 insertions(+) create mode 100644 Documentation/devicetree/bindings/net/wireless/nordic,nrf70.yaml create mode 100644 drivers/net/wireless/nordic/Kconfig create mode 100644 drivers/net/wireless/nordic/Makefile create mode 100644 drivers/net/wireless/nordic/nrf70.c create mode 100644 drivers/net/wireless/nordic/nrf70_cmds.h create mode 100644 drivers/net/wireless/nordic/nrf70_rf_params.h -- 2.49.0
