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

[David Lin]

> From: Johannes Berg <johannes@xxxxxxxxxxxxxxxx>
> Sent: Tuesday, March 26, 2024 12:15 AM
> To: Brian Norris <briannorris@xxxxxxxxxxxx>; David Lin
> <yu-hao.lin@xxxxxxx>
> Cc: 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 Fri, 2024-03-22 at 18:06 -0700, Brian Norris wrote:
> > 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.
> 
> Maybe, maybe not, actually. The auth command _is_ somewhat special in
> that it mostly hands stuff down from userspace via cfg80211, but does
> require sending frames. As long as you don't have full offload, at least.
> 
> The way I see it, the issue here isn't necessarily the fact that this uses the
> auth command (and then requires assoc, of course), but that we see here
> this is "growing" towards a more mac80211-like model, with the code
> duplication (albeit little that it is today) implied by that. To me, it seems like
> the firmware is moving into the "oh we can't do all _that_ in firmware"
> territory, and that brings it closer to mac80211.
> 
> At the same time, as you say, mac80211 is doing more and more offload
> capability, so it seems like apart from "today the firmware requires an assoc
> command rather than assoc frame processing in the host", it's actually not
> _that_ far apart any more!
> 
> Now that may be an issue in the short term, but I wouldn't be surprised at
> all if desiring to implement FILS and other new features in this space would
> make the driver move to assoc frame processing in the host as well, because
> it's getting more and more complex, just like auth.
> 
> At which point - yeah the APIs are still significantly different, but again we'd
> end up implementing something that exists in mac80211 today and taking it
> into mwifiex?
> 

Mwifiex is designed based on a "Thick FW" architecture. 
As security features become more complicated, this patch adds WPA3 support by offloading to wpa_supplicant/hostapd
With this patch, auth, assoc and key handshakes are handled in wpa_supplicant/hostapd. 
Wpa_supplicant communicates peer capability and derived keys to driver/FW via cfg80211 assoc and add_key commands.   
The cfg80211 commands are standard. Implementation between driver and firmware is vendor specific. It shall not break any existing architecture.

> > 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.
> 
> Not sure that makes a difference for mac80211 in itself, obviously changes in
> this space would then affect mwifiex, but that shouldn't be much of an
> issue.
> 

With this patch Mwifiex still a non-mac80211 implementation. 
Driver communicates with wpa_supplicant/hostapd via cfg80211 
I think how driver/FW communicate each other is proprietary, I don't see a dependency with mac80211 here

> I'm less worried about this individual patch than what it says about the
> direction this driver and firmware are taking, and I fear we'll end up in a
> situation where over time this driver actually gets to a point where it should
> be using mac80211, but because it's such a piece-meal affair (auth frames
> now, etc.) and large architectural change, they'd never actually do that.
> 
> To be fair, that might also require firmware API changes in some way. I used
> to think that was something we should never require, but I'm not so sure
> now any more - certainly we've changed our (Intel) FW API in support of
> Linux architecture many times, and overall that's for a better product (on
> Linux at least.)
> 
> Also: David, I'd appreciate if you actually took this discussion seriously; so
> far you've not really contributed any technical arguments.
> 
> Johannes

I think we are using standard cfg80211 commands. How it's handled between driver/FW is proprietary, it's carefully verified and shall not impact other features or break any architecture. 
We do not see a need why driver has to be redesigned based on mac80211. We can keep adding new features using cfg80211.