> From: Francesco Dolcini <francesco@xxxxxxxxxx> > Sent: Saturday, August 24, 2024 9:49 PM > To: Sascha Hauer <s.hauer@xxxxxxxxxxxxxx>; David Lin <yu-hao.lin@xxxxxxx> > Cc: linux-wireless@xxxxxxxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx; > kvalo@xxxxxxxxxx; johannes@xxxxxxxxxxxxxxxx; briannorris@xxxxxxxxxxxx; > francesco@xxxxxxxxxx; Pete Hsieh <tsung-hsien.hsieh@xxxxxxx>; > kernel@xxxxxxxxxxxxxx > Subject: [EXT] Re: [PATCH v2 00/43] wifi: nxpwifi: create nxpwifi to support > iw61x > > Caution: This is an external email. Please take care when clicking links or > opening attachments. When in doubt, report the message using the 'Report > this email' button > > > 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://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fww > > > w.nxp.com%2Fproducts%2Fwireless-connectivity%2Fwi-fi-plus-bluetooth- > > > > &data=05%7C02%7Cyu-hao.lin%40nxp.com%7C6d7cf356022443738a3d08dcc4 > 437 > > > > 926%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C63860104128552 > 0681% > > > > 7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJB > TiI6 > > > > Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=Z5iuaainSgM%2BVdUBh > AK4RHcv > > > vERhiw3yu0S5kRKsldM%3D&reserved=0 > > > plus-802-15-4/2-4-5-ghz-dual-band-1x1-wi-fi-6-802-11ax-plus-bluetoot > > > h-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 I don't think he can add IW61x to mwifiex without issues if the code for VDLL is missing. Without the code to handle VDLL, command timeout will happen when firmware requests VDLL from driver. This is new API which is not needed for the firmware of legacy devices. After this modification, a full QA cycle should be done to confirm the driver can work without issues. If you try to add these code to Mwifiex, you should also guarantee the code won't affect existed devices of Mwifiex. BTW, adding the support for 11ax is not a trivial job. > > > > [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 Yes. This is also one consideration for us to create Nxpwifi driver to support NXP new chips. David
