Received-SPF: pass (google.com: domain of linux-wireless-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <b398d76c19c83fe0a2a175547eccd399cd4bc7aa.camel@sipsolutions.net>
Subject: Re: [PATCH v7 3/3] mac80211: additional processing in
 ieee80211_change_beacon
From:   Johannes Berg <johannes@sipsolutions.net>
To:     Aloka Dixit <quic_alokad@quicinc.com>,
        linux-wireless@vger.kernel.org
Date:   Wed, 18 Jan 2023 16:58:58 +0100
In-Reply-To: <20221109214720.6097-4-quic_alokad@quicinc.com>
References: <20221109214720.6097-1-quic_alokad@quicinc.com>
         <20221109214720.6097-4-quic_alokad@quicinc.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
User-Agent: Evolution 3.46.3 (3.46.3-1.fc37) 
MIME-Version: 1.0
Precedence: bulk

On Wed, 2022-11-09 at 13:47 -0800, Aloka Dixit wrote:
> Process FILS discovery and unsolicited broadcast probe response
> transmission configurations in ieee80211_change_beacon().
>=20
> Signed-off-by: Aloka Dixit <quic_alokad@quicinc.com>
> ---
>  net/mac80211/cfg.c | 25 +++++++++++++++++++++++--
>  1 file changed, 23 insertions(+), 2 deletions(-)
>=20
> diff --git a/net/mac80211/cfg.c b/net/mac80211/cfg.c
> index feb54b5e6ebd..3e8e74d01dc9 100644
> --- a/net/mac80211/cfg.c
> +++ b/net/mac80211/cfg.c
> @@ -1405,6 +1405,7 @@ static int ieee80211_change_beacon(struct wiphy *wi=
phy, struct net_device *dev,
>  	struct cfg80211_beacon_data *beacon =3D &params->beacon;
>  	struct beacon_data *old;
>  	int err;
> +	u32 changed;
>  	struct ieee80211_bss_conf *link_conf;
> =20
>  	sdata_assert_lock(sdata);
> @@ -1429,13 +1430,33 @@ static int ieee80211_change_beacon(struct wiphy *=
wiphy, struct net_device *dev,
>  	if (err < 0)
>  		return err;
> =20
> +	changed =3D err;
> +
> +	if (params->fils_discovery.max_interval) {
> +		err =3D ieee80211_set_fils_discovery(sdata,
> +						   &params->fils_discovery,
> +						   link, link_conf);
> +		if (err < 0)
> +			return err;
> +		changed |=3D BSS_CHANGED_FILS_DISCOVERY;


This (and the similar change for unsolicited probe responses) basically
let you turn it _on_ or _modify_ it, but should there be a way to
explicitly turn it *off* too?

That goes together with my previous comment - since before we didn't
even process this data, why would it suddenly get turned off? Nothing
would ever send BSS_CHANGED_FILS_DISCOVERY or
BSS_CHANGED_UNSOL_BCAST_PROBE_RESP to the driver to turn it off, no?

johannes