Received-SPF: pass (google.com: domain of linux-wireless-owner@vger.kernel.org designates 23.128.96.33 as permitted sender) client-ip=23.128.96.33;
Message-ID: <cabb874c-7518-4565-a007-f466f1b69165@quicinc.com>
Date:   Mon, 16 Oct 2023 09:41:18 -0700
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 2/2] ath10k: mac: enable
 WIPHY_FLAG_CHANNEL_CHANGE_ON_BEACON on ath10k
Content-Language: en-US
To:     Kalle Valo <kvalo@kernel.org>, Abhishek Kumar <kuabhs@chromium.org>
CC:     <johannes.berg@intel.com>, <linux-kernel@vger.kernel.org>,
        <netdev@vger.kernel.org>, <ath10k@lists.infradead.org>,
        <linux-wireless@vger.kernel.org>
References: <20230629035254.2.I23c5e51afcc6173299bb2806c8c38364ad15dd63@changeid>
 <169634426707.121370.9448850980134728319.kvalo@kernel.org>
 <87il793hmi.fsf@kernel.org>
From:   Jeff Johnson <quic_jjohnson@quicinc.com>
In-Reply-To: <87il793hmi.fsf@kernel.org>
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk

On 10/13/2023 10:20 PM, Kalle Valo wrote:
> Kalle Valo <kvalo@kernel.org> writes:
> 
>> Abhishek Kumar <kuabhs@chromium.org> wrote:
>>
>>> Enabling this flag, ensures that reg_call_notifier is called
>>> on beacon hints from handle_reg_beacon in cfg80211. This call
>>> propagates the channel property changes to ath10k driver, thus
>>> changing the channel property from passive scan to active scan
>>> based on beacon hints.
>>> Once the channels are rightly changed from passive to active,the
>>> connection to hidden SSID does not fail.
>>>
>>> Signed-off-by: Abhishek Kumar <kuabhs@chromium.org>
>>
>> There's no Tested-on tag, on which hardware/firmware did you test this?
>>
>> This flag is now enabled on ALL ath10k supported hardware: SNOC, PCI, SDIO and
>> maybe soon USB. I'm just wondering can we trust that this doesn't break
>> anything.
> 
> Jeff, what are your thoughts on this? I'm worried how different ath10k
> firmwares can be and if this breaks something.
> 

Since the 1/2 patch is already in pull-request: wireless-next-2023-10-06 
I went through the logic of that again. It would have been nice if that 
actually described how it fixes the problem. What actually causes a 
channel to change from passive to active?

Note the existing logic prior to the 1/2 patch already updates the wiphy 
and userspace with the updated channel flags, so it seems reasonable to 
also update the driver

However, this led me down the rabbit hole of trying to figure out what 
happens if a beacon hint causes us to change a channel from passive to 
active, but then that AP goes away. What, if anything, causes the 
channel to revert back to passive? I'm not immediately seeing that logic 
anywhere.

My concern is that we have an AP with a hidden SSID on a DFS channel, 
and as a result of a beacon hint we switch that channel to active scan. 
But then later that AP detects radar and vacates the channel. Then we 
potentially have stations doing active scan on a DFS channel with an 
active radar.

Hopefully this is all handled, and it just isn't obvious in my 
admittedly very quick 10 minute scan of the code.

And as far as the 2/2 patch, note this logic is all dependent upon 
reg_is_world_roaming(wiphy) returning true, so ath10k impact would 
really depend upon the board regulatory settings, whether configured for 
a fixed regulatory domain/country code or configured for world roaming.

/jeff