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: <9ff00d88-6d12-8ee5-aa25-a5e82879d25c@quicinc.com>
Date:   Thu, 19 Jan 2023 11:40:10 -0800
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101
 Thunderbird/102.4.1
Subject: Re: [PATCH v7 2/3] nl80211: additional processing in
 NL80211_CMD_SET_BEACON
To:     Johannes Berg <johannes@sipsolutions.net>,
        <linux-wireless@vger.kernel.org>
References: <20221109214720.6097-1-quic_alokad@quicinc.com>
 <20221109214720.6097-3-quic_alokad@quicinc.com>
 <0b42cfb9f0effce61b33c41ec9067b3747fade5c.camel@sipsolutions.net>
Content-Language: en-US
From:   Aloka Dixit <quic_alokad@quicinc.com>
In-Reply-To: <0b42cfb9f0effce61b33c41ec9067b3747fade5c.camel@sipsolutions.net>
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk

On 1/18/2023 7:57 AM, Johannes Berg wrote:
> On Wed, 2022-11-09 at 13:47 -0800, Aloka Dixit wrote:
>> FILS discovery and unsolicited broadcast probe response transmissions
>> are configured as part of NL80211_CMD_START_AP, however both stop
>> after userspace uses the NL80211_CMD_SET_BEACON command as these
>> attributes are not processed in that command.
> 
> That seems odd. Why would that *stop*? Nothing in the driver should
> actually update it to _remove_ it during change_beacon()?
> > Are you sure you didn't mean to "just" say "however both cannot be
> updated as these attributes ..."?
> 
> johannes

FILS discovery has primary channel, center frequency in the frame format 
which should be changed depending on why the beacon changed. Hence the 
current design, at least ath11k, assumes that BSS_CHANGED_FILS_DISCOVERY 
and BSS_CHANGED_UNSOL_BCAST_PROBE_RESP "not being set", when beacon is 
changed, means disable these features.
What do you think?

Like you said, we still need this code to update these templates if 
provided by the userspace, e.g. in case of channel switch.

Should I send a follow-up with a different commit log?

Thanks.