On Thu, Aug 22, 2024 at 02:56:25PM +0200, Sascha Hauer wrote: > On Fri, Aug 09, 2024 at 05:44:50PM +0800, David Lin wrote: > > This series adds support for IW61x which is a new family of 2.4/5 GHz > > dual-band 1x1 Wi-Fi 6, Bluetooth/Bluetooth Low Energy 5.2 and 15.4 > > tri-radio single chip by NXP. These devices support 20/40/80MHz > > single spatial stream in both STA and AP mode. Communication to the > > IW61x is done via SDIO interface > > > > This driver is a derivative of existing Mwifiex [1] and based on similar > > full-MAC architecture [2]. It has been tested with i.MX8M Mini evaluation > > kits in both AP and STA mode. > > > > All code passes sparse and checkpatch > > > > Data sheet (require registration): > > https://www.nxp.com/products/wireless-connectivity/wi-fi-plus-bluetooth- > > plus-802-15-4/2-4-5-ghz-dual-band-1x1-wi-fi-6-802-11ax-plus-bluetooth-5- > > 4-plus-802-15-4-tri-radio-solution:IW612 > > > > Known gaps to be addressed in the following patches, > > - Enable 11ax capabilities. This initial patch support up to 11ac. > > - Support DFS channel. This initial patch doesn't support DFS channel in > > both AP/STA mode. > > > > This patch is presented as a request for comment with the intention of being > > made into a patch after initial feedbacks are addressed > > > > [1] We had considered adding IW61x to mwifiex driver, however due to > > FW architecture, host command interface and supported features are > > significantly different, we have to create the new nxpwifi driver. > > Subsequent NXP chipsets will be added and sustained in this new driver. > > I added IW61x support to the mwifiex driver and besides the VDLL > handling which must be added I didn't notice any differences. There > might be other differences, but I doubt that these can't be integrated > into the mwifiex driver. Maybe you can share an RFC patch with what you currently have available to support IW61x within the current mwifiex driver? Given what David @NXP wrote here > > [1] We had considered adding IW61x to mwifiex driver, however due to > > FW architecture, host command interface and supported features are > > significantly different, we have to create the new nxpwifi driver. David, given the code, he should be able to highlight the limitation of such approach and hopefully we can find a good path forward? One of the challenges with the current mwifiex driver is that it supports quite a few wireless devices, and any new addition must be done in such a way to not break the old stuff. Not to mention the "Odd Fixes" maintenance status of the driver, quoting Brian: "My only interest in mwifiex is in making sure existing hardware (especially those used on Chromebooks) doesn't get significantly worse.". Francesco
