Re: [EXT] Re: [PATCH v9 0/2] wifi: mwifiex: add code to support host mlme

[Brian Norris <briannorris@chromium.org>]

On Thu, Mar 21, 2024 at 04:07:58AM +0000, David Lin wrote:
> > From: Brian Norris <briannorris@chromium.org>
> > 
> > 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:

> > > > 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:

[strip mangled URLs]

> > "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.
> 
> Yes. This change is to offload wpa3 features to host. It's well tested
> and doesn't impact existing features.

We appreciate it's well tested, but testing is still orthogonal to the
architectural questions. Architectural questions are important because
they affect the future maintainability of the mainline Linux wireless
stack. If the assumption is that *either* a driver is a cfg80211 driver
(with firmware-MLME, etc.) or a mac80211 driver (with host MLME), then
your series is breaking those assumptions. It may be harder to add
future additions to the mac80211 stack [*], if we have to add new
concerns of a non-mac80211 implementation in the mix.

Is it not possible to implement these features via CONNECT? Does your
firmware not provide any kind of NL80211_EXT_FEATURE_SAE_OFFLOAD
support, or otherwise handle WPA3 MLME?

Or, *does* your firmware also provide low-level 802.11 framing support?
If so, then maybe Johannes is suggesting you'd need a (new)
mac80211-based driver to go down this path... although I'm sure that's a
lot of work on its own.

Anyway, I definitely want Johannes's thoughts, although some additional
info from David might help too.

Brian

[*] We definitely need Johannes to weigh in here.