Received-SPF: pass (google.com: domain of linux-kernel+bounces-117442-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) client-ip=147.75.80.249;
Message-ID: <4e5f3741819e457c5c79d825c6520cb9ee531b95.camel@sipsolutions.net>
Subject: Re: [EXT] Re: [PATCH v9 0/2] wifi: mwifiex: add code to support
 host mlme
From: Johannes Berg <johannes@sipsolutions.net>
To: Brian Norris <briannorris@chromium.org>, David Lin <yu-hao.lin@nxp.com>
Cc: Francesco Dolcini <francesco@dolcini.it>, "kvalo@kernel.org"
 <kvalo@kernel.org>, "linux-wireless@vger.kernel.org"
 <linux-wireless@vger.kernel.org>, "linux-kernel@vger.kernel.org"
 <linux-kernel@vger.kernel.org>, Pete Hsieh <tsung-hsien.hsieh@nxp.com>, 
 "rafael.beims" <rafael.beims@toradex.com>, Francesco Dolcini
 <francesco.dolcini@toradex.com>
Date: Mon, 25 Mar 2024 17:15:11 +0100
In-Reply-To: <Zf4rDifM6bLuqpX2@google.com>
References: <20240306020053.18054-1-yu-hao.lin@nxp.com>
	 <20240315094927.GA6624@francesco-nb> <ZfTspRKFgrO9xCTH@google.com>
	 <969e95ccc4a1d35b45212b7fcb536ee90995e3b5.camel@sipsolutions.net>
	 <PA4PR04MB9638D253189D6DD330B198B2D1332@PA4PR04MB9638.eurprd04.prod.outlook.com>
	 <PA4PR04MB9638BE73DDBCE1CE8AA32BA8D1332@PA4PR04MB9638.eurprd04.prod.outlook.com>
	 <b2d9a7ef53c5ab4212617e8edf202bbafe52e2f8.camel@sipsolutions.net>
	 <ZftaJEIeNfV7YrVo@google.com>
	 <PA4PR04MB9638F5037D1AB9BCF51CC9D9D1322@PA4PR04MB9638.eurprd04.prod.outlook.com>
	 <Zf4rDifM6bLuqpX2@google.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
User-Agent: Evolution 3.50.4 (3.50.4-1.fc39) 
Precedence: bulk
MIME-Version: 1.0

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?

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

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