Received-SPF: pass (google.com: domain of linux-wireless-owner@vger.kernel.org designates 23.128.96.35 as permitted sender) client-ip=23.128.96.35;
Message-ID: <3f2323b2-de9e-4f1d-b302-cc20c15bc105@quicinc.com>
Date:   Wed, 27 Sep 2023 11:03:26 -0700
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] wifi: nl80211: remove set_fils_aad support
Content-Language: en-US
To:     Johannes Berg <johannes@sipsolutions.net>,
        <linux-wireless@vger.kernel.org>
References: <20230926160950.d698c25528e3.If118a835a25c59de20e1728ab71949fdb4172fb2@changeid>
 <9ddcbc2f-5e40-48cd-bdbd-943bd86acb61@quicinc.com>
 <9a544a1b9385a150f779ac35a780dbb50200a962.camel@sipsolutions.net>
From:   Jeff Johnson <quic_jjohnson@quicinc.com>
In-Reply-To: <9a544a1b9385a150f779ac35a780dbb50200a962.camel@sipsolutions.net>
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk

On 9/27/2023 12:00 AM, Johannes Berg wrote:
> 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>
>>>
>>> There's no user for this, so remove the support.
>>>
>>> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
>>
>> if you are going to remove it, why not just revert e306784a8de0
>> ("cfg80211: AP mode driver offload for FILS association crypto") to make
>> sure you get all of the artifacts? for example, I believe your patch
>> will leave behind an unused struct cfg80211_fils_aad and unused
>> 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
>> UAPI definitions would need to be retained (and should be documented as
>> 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
>> this interface upstream. as i've indicated earlier, we are in the
>> process of trying to transition to an "upstream first" mentality, but
>> this is not going to happen overnight, but instead will take years. that
>> said, i'd hate to rip out an interface now just to need to add it back
>> 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...

Based on internal discussion I don't see a path forward to using this 
interface upstream, so please continue with the extraction, 
incorporating my prior comments.

Thanks!
/jeff