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: <98a39edef048fef625cdec32030d62699f89d9e8.camel@sipsolutions.net>
Subject: Re: [PATCH] mac80211: adjust the replace_state of
 ieee80211_find_chanctx()
From:   Johannes Berg <johannes@sipsolutions.net>
To:     Ryder Lee <ryder.lee@mediatek.com>
Cc:     linux-wireless@vger.kernel.org, linux-mediatek@lists.infradead.org
Date:   Wed, 23 Mar 2022 14:10:28 +0100
In-Reply-To: <40aabb3e10302f1d7da92b7a4eb46577d5ed8e05.1647641256.git.ryder.lee@mediatek.com>
References: <40aabb3e10302f1d7da92b7a4eb46577d5ed8e05.1647641256.git.ryder.lee@mediatek.com>
Content-Type: text/plain; charset="UTF-8"
User-Agent: Evolution 3.42.4 (3.42.4-1.fc35) 
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Precedence: bulk

On Sat, 2022-03-19 at 06:18 +0800, Ryder Lee wrote:
> We observe that the condition of chanctx could not be back to
> IEEE80211_CHANCTX_REPLACE_NONE occasionally while STA connection.

Not sure I parse this correctly, can you elaborate?

> In this case the state could be IEEE80211_CHANCTX_REPLACE_OTHER, which
> fails the check and then creates another chanctx that leads to the next
> round of chan_switch failure in cfg80211_check_combinations().

But if it's REPLACES_OTHER (note your typo), then it's not yet
registered properly or anything.

> So, modify state to just rule out IEEE80211_CHANCTX_WILL_BE_REPLACED.

Therefore, that really doesn't seem right.

A chanctx with IEEE80211_CHANCTX_REPLACES_OTHER needs to get used via
ieee80211_vif_use_reserved_switch().

johannes