[PATCH ath-next] wifi: ath12k: wmi: Complete regulatory update for dropped events

[PATCH ath-next] wifi: ath12k: wmi: Complete regulatory update for dropped events

[Konrad Dybcio]

From: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>

If ath12k_reg_validate_reg_info() returns STATUS_FALLBACK/DROP (which
are not fatal), the code then jumps to mem_free with pdev_idx still set
to 255, making the following completion never take place.

That then results in repeating "Timeout while waiting for regulatory
update" messages, as observed e.g. on a Glymur-based ASUS Zenbook A16.

Fix that by updating the pdev_idx right after the actually-fatal case
of not being able to extract the reg info data is ruled out.

Fixes: 906619a00967 ("wifi: ath12k: handle regulatory hints during mac registration")
Suggested-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com>
Signed-off-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
---
 drivers/net/wireless/ath/ath12k/wmi.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/net/wireless/ath/ath12k/wmi.c b/drivers/net/wireless/ath/ath12k/wmi.c
index d5160af60e00..4ac78ba6c790 100644
--- a/drivers/net/wireless/ath/ath12k/wmi.c
+++ b/drivers/net/wireless/ath/ath12k/wmi.c
@@ -6975,6 +6975,8 @@ static int ath12k_reg_chan_list_event(struct ath12k_base *ab, struct sk_buff *sk
 		goto mem_free;
 	}
 
+	pdev_idx = reg_info->phy_id;
+
 	ret = ath12k_reg_validate_reg_info(ab, reg_info);
 	if (ret == ATH12K_REG_STATUS_FALLBACK) {
 		ath12k_warn(ab, "failed to validate reg info %d\n", ret);
@@ -6991,7 +6993,6 @@ static int ath12k_reg_chan_list_event(struct ath12k_base *ab, struct sk_buff *sk
 	}
 
 	/* free old reg_info if it exist */
-	pdev_idx = reg_info->phy_id;
 	if (ab->reg_info[pdev_idx]) {
 		ath12k_reg_reset_reg_info(ab->reg_info[pdev_idx]);
 		kfree(ab->reg_info[pdev_idx]);

---
base-commit: e6664f2b33db9b6811eb4cec109f06cb2b4f458d
change-id: 20260818-topic-wifi_reg_fix-a20c9256c5fd

Best regards,
--  
Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>

Re: [PATCH ath-next] wifi: ath12k: wmi: Complete regulatory update for dropped events

[Baochen Qiang]

On 8/18/2026 10:57 PM, Konrad Dybcio wrote:
> From: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
> 
> If ath12k_reg_validate_reg_info() returns STATUS_FALLBACK/DROP (which
> are not fatal), the code then jumps to mem_free with pdev_idx still set
> to 255, making the following completion never take place.
> 
> That then results in repeating "Timeout while waiting for regulatory
> update" messages, as observed e.g. on a Glymur-based ASUS Zenbook A16.
> 
> Fix that by updating the pdev_idx right after the actually-fatal case
> of not being able to extract the reg info data is ruled out.
> 
> Fixes: 906619a00967 ("wifi: ath12k: handle regulatory hints during mac registration")
> Suggested-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com>
> Signed-off-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
> ---
>  drivers/net/wireless/ath/ath12k/wmi.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/net/wireless/ath/ath12k/wmi.c b/drivers/net/wireless/ath/ath12k/wmi.c
> index d5160af60e00..4ac78ba6c790 100644
> --- a/drivers/net/wireless/ath/ath12k/wmi.c
> +++ b/drivers/net/wireless/ath/ath12k/wmi.c
> @@ -6975,6 +6975,8 @@ static int ath12k_reg_chan_list_event(struct ath12k_base *ab, struct sk_buff *sk
>  		goto mem_free;
>  	}
>  
> +	pdev_idx = reg_info->phy_id;
> +
>  	ret = ath12k_reg_validate_reg_info(ab, reg_info);
>  	if (ret == ATH12K_REG_STATUS_FALLBACK) {
>  		ath12k_warn(ab, "failed to validate reg info %d\n", ret);
> @@ -6991,7 +6993,6 @@ static int ath12k_reg_chan_list_event(struct ath12k_base *ab, struct sk_buff *sk
>  	}
>  
>  	/* free old reg_info if it exist */
> -	pdev_idx = reg_info->phy_id;
>  	if (ab->reg_info[pdev_idx]) {
>  		ath12k_reg_reset_reg_info(ab->reg_info[pdev_idx]);
>  		kfree(ab->reg_info[pdev_idx]);
> 
> ---
> base-commit: e6664f2b33db9b6811eb4cec109f06cb2b4f458d
> change-id: 20260818-topic-wifi_reg_fix-a20c9256c5fd
> 
> Best regards,
> --  
> Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
> 

there is a similar patch [1] as part of a series [2]:

[1]
https://lore.kernel.org/all/20260729-ath12k-regd-wait-timeout-v1-1-504aa6e7e93c@oss.qualcomm.com/
[2]
https://lore.kernel.org/all/20260729-ath12k-regd-wait-timeout-v1-0-504aa6e7e93c@oss.qualcomm.com/

Re: [PATCH ath-next] wifi: ath12k: wmi: Complete regulatory update for dropped events

[Konrad Dybcio]

On 8/19/26 3:50 AM, Baochen Qiang wrote:
> 
> 
> On 8/18/2026 10:57 PM, Konrad Dybcio wrote:
>> From: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
>>
>> If ath12k_reg_validate_reg_info() returns STATUS_FALLBACK/DROP (which
>> are not fatal), the code then jumps to mem_free with pdev_idx still set
>> to 255, making the following completion never take place.

[...]

> there is a similar patch [1] as part of a series [2]:
> 
> [1]
> https://lore.kernel.org/all/20260729-ath12k-regd-wait-timeout-v1-1-504aa6e7e93c@oss.qualcomm.com/
> [2]
> https://lore.kernel.org/all/20260729-ath12k-regd-wait-timeout-v1-0-504aa6e7e93c@oss.qualcomm.com/

Ah, sorry.. I tried searching for whether you guys handled it but
I didn't find that series. Let's go with your patches.

Konrad

Re: [PATCH ath-next] wifi: ath12k: wmi: Complete regulatory update for dropped events

[Baochen Qiang]

On 8/19/2026 3:43 PM, Konrad Dybcio wrote:
> On 8/19/26 3:50 AM, Baochen Qiang wrote:
>>
>>
>> On 8/18/2026 10:57 PM, Konrad Dybcio wrote:
>>> From: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
>>>
>>> If ath12k_reg_validate_reg_info() returns STATUS_FALLBACK/DROP (which
>>> are not fatal), the code then jumps to mem_free with pdev_idx still set
>>> to 255, making the following completion never take place.
> 
> [...]
> 
>> there is a similar patch [1] as part of a series [2]:
>>
>> [1]
>> https://lore.kernel.org/all/20260729-ath12k-regd-wait-timeout-v1-1-504aa6e7e93c@oss.qualcomm.com/
>> [2]
>> https://lore.kernel.org/all/20260729-ath12k-regd-wait-timeout-v1-0-504aa6e7e93c@oss.qualcomm.com/
> 
> Ah, sorry.. I tried searching for whether you guys handled it but
> I didn't find that series. Let's go with your patches.

I should have put you in the cc list or reply in the internal thread ... :)

> 
> Konrad