Received-SPF: pass (google.com: domain of linux-wireless+bounces-7764-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) client-ip=2604:1380:45d1:ec00::1;
Message-ID: <f433f7d4-a9c5-4077-a7d8-c858efebaa85@leemhuis.info>
Date: Fri, 17 May 2024 07:58:36 +0200
Precedence: bulk
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2] wifi: ath11k: move power type check to ASSOC stage
 when connecting to 6 GHz AP
To: Baochen Qiang <quic_bqiang@quicinc.com>, Kalle Valo <kvalo@kernel.org>
Cc: ath11k@lists.infradead.org, linux-wireless@vger.kernel.org,
 regressions@lists.linux.dev
References: <20240424064019.4847-1-quic_bqiang@quicinc.com>
 <87wmo0k71i.fsf@kernel.org>
 <3dc28f34-45cc-4e14-b9ea-1f7b78a6a591@quicinc.com>
From: "Linux regression tracking (Thorsten Leemhuis)"
 <regressions@leemhuis.info>
Content-Language: en-US, de-DE
Reply-To: Linux regressions mailing list <regressions@lists.linux.dev>
In-Reply-To: <3dc28f34-45cc-4e14-b9ea-1f7b78a6a591@quicinc.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 17.05.24 04:14, Baochen Qiang wrote:
> On 5/11/2024 5:54 PM, Kalle Valo wrote:
>> Baochen Qiang <quic_bqiang@quicinc.com> writes:
>>
>>> With commit bc8a0fac8677 ("wifi: mac80211: don't set bss_conf in parsing")
>>> ath11k fails to connect to 6 GHz AP.
>>>
>>> This is because currently ath11k checks AP's power type in
>>> ath11k_mac_op_assign_vif_chanctx() which would be called in AUTH stage.
>>> However with above commit power type is not available until ASSOC stage.
>>> As a result power type check fails and therefore connection fails.
>>>
>>> Fix this by moving power type check to ASSOC stage, also move regulatory
>>> rules update there because it depends on power type.
>>>
>>> Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.30
>>>
>>> Fixes: bc8a0fac8677 ("wifi: mac80211: don't set bss_conf in parsing")
>>> Signed-off-by: Baochen Qiang <quic_bqiang@quicinc.com>

Quick question: how does the error actually look like? I noticed a bug
report where someone complained problems connecting "to my Wifi 7 AP on
6GHz band using my Lenovo P14s Gen 4 laptop" and wonder if it's the same
or a different problem: https://bugzilla.kernel.org/show_bug.cgi?id=218838

To quote part of it:

"""
Sometimes when the connection fails the following appears on the logs

invalid HE MCS: bw:6, ru:6
WARNING: CPU: 13 PID: 1242 at net/wireless/util.c:1551
cfg80211_calculate_bitrate_he+0x1b7/0x3c0 [cfg80211]
CPU: 13 PID: 1242 Comm: NetworkManager Not tainted
6.9.0-0.rc7.20240510git448b3fe5a0ea.62.fc41.x86_64 #1
Hardware name: LENOVO 21K5000DMX/21K5000DMX, BIOS R2FET56W (1.36 )
03/13/2024
RIP: 0010:cfg80211_calculate_bitrate_he+0x1b7/0x3c0 [cfg80211]
Code: 00 40 80 fe 06 0f 84 a1 00 00 00 40 80 fe 03 0f 84 d6 00 00 00 40
84 f6 0f 84 0b 01 00 00 48 c7 c7 41 33 96 c1 e8 59 cd 8d e8 <0f> 0b 31
c0 eb 53 44 0f b6 e8 3c 02 0f 87 62 01 00 00 42 8b 44 ac
RSP: 0018:ffffa5f2c6df7320 EFLAGS: 00010286
RAX: 0000000000000000 RBX: ffffa5f2c6df7518 RCX: 0000000000000027
RDX: ffff9166df0a18c8 RSI: 0000000000000001 RDI: ffff9166df0a18c0
RBP: 0000000000000002 R08: 0000000000000000 R09: 0000000000000000
R10: ffffffffc196335e R11: 0000000000000001 R12: 0000000000000009
R13: ffff91580eae0000 R14: ffff915b0ed33ef0 R15: ffff915a8b051b00
FS:  00007f7d396cd580(0000) GS:ffff9166df080000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00003d7c6e07d000 CR3: 0000000137282000 CR4: 0000000000f50ef0
PKRU: 55555554
Call Trace:
 <TASK>
 ? cfg80211_calculate_bitrate_he+0x1b7/0x3c0 [cfg80211]
 ? __warn.cold+0x8e/0xe8
 ? cfg80211_calculate_bitrate_he+0x1b7/0x3c0 [cfg80211]
 ? report_bug+0xff/0x140
 ? handle_bug+0x3c/0x80
 ? exc_invalid_op+0x17/0x70
 ? asm_exc_invalid_op+0x1a/0x20
 ? cfg80211_calculate_bitrate_he+0x1b7/0x3c0 [cfg80211]
 nl80211_put_sta_rate+0x5b/0x4f0 [cfg80211]
 nl80211_send_station+0x9f0/0x1060 [cfg80211]
 nl80211_dump_station+0xef/0x280 [cfg80211]
 genl_dumpit+0x33/0x90
 netlink_dump+0x151/0x3b0
[...]
"""

>> Oh, this fell through the cracks. Commit bc8a0fac8677 was introduced in
>> v6.9-rc1 so I should have sent this to v6.9 but it's too late now. I'll
>> need to queue this for v6.10 via wireless tree.
>>
>> Adding the regression also to regzbot:
>>
>> #regzbot introduced: bc8a0fac8677
>> #regzbot title: ath11k: connection to 6 GHz AP fails
>
> Hi Kalle, with an upcoming patch this regression is expected to be fixed:
> 
> https://lore.kernel.org/all/20240506214536.310434f55f76.I6aca291ee06265e3f63e0f9024ba19a850b53a33@changeid/#t
>
> So here the ath11k fix would not be needed any more once above patch got merged.
> 
> But I don't have time to test this, so suggest keeping it pending. We could drop it once above analysis got verified.

Thx for the update. If that's the way forward I wonder if that change
should have Fixes: and Stable: tags to ensure it ends up in 6.9.y --
ideally rather sooner than later if this is a regression users run into.

Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)
--
Everything you wanna know about Linux kernel regression tracking:
https://linux-regtracking.leemhuis.info/about/#tldr
If I did something stupid, please tell me, as explained on that page.