Received-SPF: pass (google.com: domain of linux-wireless-owner@vger.kernel.org designates 2620:137:e000::3:4 as permitted sender) client-ip=2620:137:e000::3:4;
Message-ID: <9a544a1b9385a150f779ac35a780dbb50200a962.camel@sipsolutions.net>
Subject: Re: [PATCH] wifi: nl80211: remove set_fils_aad support
From:   Johannes Berg <johannes@sipsolutions.net>
To:     Jeff Johnson <quic_jjohnson@quicinc.com>,
        linux-wireless@vger.kernel.org
Date:   Wed, 27 Sep 2023 09:00:35 +0200
In-Reply-To: <9ddcbc2f-5e40-48cd-bdbd-943bd86acb61@quicinc.com>
References: <20230926160950.d698c25528e3.If118a835a25c59de20e1728ab71949fdb4172fb2@changeid>
         <9ddcbc2f-5e40-48cd-bdbd-943bd86acb61@quicinc.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
User-Agent: Evolution 3.48.4 (3.48.4-1.fc38) 
MIME-Version: 1.0
Precedence: bulk

On Tue, 2023-09-26 at 13:35 -0700, Jeff Johnson wrote:
> On 9/26/2023 7:09 AM, Johannes Berg wrote:
> > From: Johannes Berg <johannes.berg@intel.com>
> >=20
> > There's no user for this, so remove the support.
> >=20
> > Signed-off-by: Johannes Berg <johannes.berg@intel.com>
>=20
> if you are going to remove it, why not just revert e306784a8de0=20
> ("cfg80211: AP mode driver offload for FILS association crypto") to make=
=20
> sure you get all of the artifacts? for example, I believe your patch=20
> will leave behind an unused struct cfg80211_fils_aad and unused=20
> FILS_AAD_ASSIGN() trace helper macro.

Hah, good point, I didn't do this well.

> the caveat to reverting is that it should only be a partial revert; the=
=20
> UAPI definitions would need to be retained (and should be documented as=
=20
> obsolete).

Yeah, that's why I didn't do it as a revert.

> however, let me check to make sure there is no plan to actually utilize=
=20
> this interface upstream. as i've indicated earlier, we are in the=20
> process of trying to transition to an "upstream first" mentality, but=20
> this is not going to happen overnight, but instead will take years. that=
=20
> said, i'd hate to rip out an interface now just to need to add it back=
=20
> in the future.

Sure. I don't mind keeping something around that really _has_ a future,
but it's been two years and nobody showed up ... but yeah, I also think
that "has a future" means upstream.

And clearly the old "other people can use it" argument doesn't work any
more either, the only other vendors who are doing something in AP mode
are Mediatek and maybe to some extent Realtek, and they all work on top
of mac80211 with thinner firmware. Broadcom has disappeared as far as I
can tell, with the occasional patch like recently that I'm also
suspecting serves pure out-of-tree driver purposes...

johannes