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