Date: Thu, 21 Mar 2024 04:07:58 +0000
From: David Lin <yu-hao.lin@....com>
To: Brian Norris <briannorris@...omium.org>, Johannes Berg
	<johannes@...solutions.net>
CC: Francesco Dolcini <francesco@...cini.it>, "kvalo@...nel.org"
	<kvalo@...nel.org>, "linux-wireless@...r.kernel.org"
	<linux-wireless@...r.kernel.org>, "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>, Pete Hsieh <tsung-hsien.hsieh@....com>,
	rafael.beims <rafael.beims@...adex.com>, Francesco Dolcini
	<francesco.dolcini@...adex.com>
Subject: RE: [EXT] Re: [PATCH v9 0/2] wifi: mwifiex: add code to support host
 mlme

> From: Brian Norris <briannorris@...omium.org>
> Sent: Thursday, March 21, 2024 5:50 AM
> To: Johannes Berg <johannes@...solutions.net>
> Cc: David Lin <yu-hao.lin@....com>; Francesco Dolcini <francesco@...cini.it>;
> kvalo@...nel.org; linux-wireless@...r.kernel.org;
> linux-kernel@...r.kernel.org; Pete Hsieh <tsung-hsien.hsieh@....com>;
> rafael.beims <rafael.beims@...adex.com>; Francesco Dolcini
> <francesco.dolcini@...adex.com>
> 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

Powered by blists - more mailing lists