> From: Brian Norris <briannorris@xxxxxxxxxxxx> > Sent: Thursday, March 21, 2024 5:50 AM > To: Johannes Berg <johannes@xxxxxxxxxxxxxxxx> > Cc: David Lin <yu-hao.lin@xxxxxxx>; Francesco Dolcini <francesco@xxxxxxxxxx>; > kvalo@xxxxxxxxxx; linux-wireless@xxxxxxxxxxxxxxx; > linux-kernel@xxxxxxxxxxxxxxx; Pete Hsieh <tsung-hsien.hsieh@xxxxxxx>; > rafael.beims <rafael.beims@xxxxxxxxxxx>; Francesco Dolcini > <francesco.dolcini@xxxxxxxxxxx> > Subject: Re: [EXT] Re: [PATCH v9 0/2] wifi: mwifiex: add code to support host > mlme > > 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 Wed, Mar 20, 2024 at 10:12:45AM +0100, Johannes Berg wrote: > > On Wed, 2024-03-20 at 01:10 +0000, David Lin wrote: > > > > > > > > > > Also decl.h should probably _shrink_ rather than grow, a number > > > > > of things just replicate ieee80211.h (such as > > > > > MWIFIEX_MGMT_HEADER_LEN really is just > > > > > sizeof(ieee80211_mgmt) or so? Not quite correctly.) > > > > > > > > > > > > > This can be done for feature patches. > > > > But this is a feature patch :-) > > I'm going to hazard a guess David may have meant "future"? > > But yeah, I get overwhelemed at how similar-but-not-quite-the-same > definitions in this driver sometimes. It definitely could use some spring > cleaning. > Sorry. Typo. I will modify it in patch v10 instead of future patch. > > > > > So yeah, agree with Brian, not only would this be the first, but > > > > > it's also something we don't really _want_. All other drivers > > > > > that want stuff like this are stuck in staging ... > > > > > > > > > > So why is this needed for a supposedly "firmware does it all" > > > > > driver, and why can it not be integrated with mac80211 if it's > > > > > no longer "firmware > > > > does it all"? > > > > > > > > > > Johannes > > > > > > > > Our proprietary driver is cfg80211 driver, it is very hard to > > > > create a brand new > > > > mac80211 driver and still can port all tested stuffs from our proprietary > driver. > > > > That basically doesn't matter for upstream at all. > > +1 > Yes. Sorry. Please check my explanations below. > > > BTW, vendor should have the choice to use cfg80211 or mac80211 for their > chips, right? > > > > No, that's not how it works. The choice should be what makes sense > > architecturally. > > And to put some specifics on it, that's what's described here: > > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwireless. > wiki.kernel.org%2Fen%2Fdevelopers%2Fdocumentation%2Fmac80211&data=0 > 5%7C02%7Cyu-hao.lin%40nxp.com%7C26588fdd1b6e4898479808dc4927c350 > %7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C63846568232661160 > 6%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLC > JBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=i3RTFqEZN3djd9L > RsgxgdgXfiuCln%2BBy6%2B0akWYLvT8%3D&reserved=0 > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwireless. > wiki.kernel.org%2Fen%2Fdevelopers%2Fdocumentation%2Fcfg80211&data=05 > %7C02%7Cyu-hao.lin%40nxp.com%7C26588fdd1b6e4898479808dc4927c350% > 7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C638465682326623950 > %7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJ > BTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=5erX1KaKcB5j6GzN > u2bb0wt0j7DgUckO5hsazc1z%2FlM%3D&reserved=0 > > (I don't consider myself an authority on this stuff, for the record. > But:) > > I've often felt like the SoftMAC designation has a very fuzzy definition. Or, that > definition is very much subject to the whims of the hardware/firmware vendor, > and can change from day to day. For instance, it feels like there are plenty of > "fat firmware" features in mac80211 drivers today, where pretty much > anything and everything *might* be handled in some kind of firmware-offload > feature, in addition or instead of on the host CPU. > > But a key point that *is* a pretty hard designation, from the mac80211 > page: > > "SoftMAC devices allow for a finer control of the hardware, allowing for > 802.11 frame management to be done in software for them, for both parsing > and generation of 802.11 wireless frames" > > AFAICT, mwifiex firmware still isn't allowing "parsing and generation of > 802.11 wireless frames" in any general form -- everything I see is still wrapped > in custom firmware command protocols. I do see that the AUTH frame looks > like it's essentially duplicating the standard mgmt format, and uses the driver's > TX path for it, but there isn't a corresponding ASSOC management frame that I > can see... > ...so I really can't tell how much control this firmware *does* give the host > regarding arbitrary 802.11 frame management. > > But that's pretty much business as usual for anybody but the vendor in > priorietary firmware land; I can't answer pretty much any question, other than > what I can glean from a driver. > > Brian Yes. This change is to offload wpa3 features to host. It's well tested and doesn't impact existing features. David
