[PATCH v6 0/4] wifi: ath12k: store and send country code to firmware after recovery

[Kang Yang]

On 12/2/2024 4:47 PM, Mihai Moldovan wrote:
> * On 12/2/24 02:53, Kang Yang wrote:
>> On 11/29/2024 8:18 PM, Mihai Moldovan wrote:
>>> Have you tested this in AP mode or was testing limited to STA mode?
>>
>> Not yet.
> 
> Okay, so a useful heads-up, I guess!
> 
> 
>>> Even with this patch set, hostapd fails to start on a channel that is
>>> disabled in the default regdomain, even if 11d is enabled and a CC
>>> specified, even after a CC update is requested and CHANEL_LIST_UPDATE is
>>> being received.
>>>
>>
>> What is the probability of failure?
> 
> In my tests, 100 % reproducible, but I admit I haven't stress-tested it.
> 
> It always fails the first time hostapd is started if the default rules 
> define NO_IR on the channel you want to use (even if CC rules disagree) 
> and can also easily be reproduced by, e.g., using channel 100 with 
> hostapd and setting CC for instance to DE or US in the hostapd config file:
> 

root at NUC8:/home/yk/Desktop/sigma-script# wls1: interface state 
UNINITIALIZED->COUNTRY_UPDATE
Frequency 5500 (primary) not allowed for AP mode, flags: 0x100959 RADAR
Primary frequency not allowed
wls1: IEEE 802.11 Configured channel (100) or frequency (5500) 
(secondary_channel=0) not found from the channel list of the current 
mode (2) IEEE 802.11a

Don't know how you test with channel 100, it's a DFS channel.
Can you show me your whole hostapd.conf?


> # Chinese regulatory does not allow operation on channels 96 to 128.
> iw reg set CN; hostapd ... => fails
> iw reg set DE; hostapd ... => works
> 
my steps:
rmmod ath12k
insmod ath12k
iw reg set CN
hostapd...

> Luckily it's really easy to reproduce.
> 
> 
> hostapd is special in the sense that it's using netlink directly and 
> this is probably very fast.
> 
> I was never able to reproduce the issue with iw reg set CN; iw reg set 
> DE; iw list, but I don't find that surprising due to all the overhead 
> and highly different code path.
> 
> 
>>> You recently re-submitted a patch set for ath11k by Wen Gong[0] that is
>>> supposed to fix a race condition during reg updates and this smells like
>>> the same issue. I'll try to port it to ath12k on top of this patch set
>>> to see if it fixes this issue.
>>>
>>>
>>
>> Thanks for trying, currently, i'm occupied by other tasks...
> 
> All good.
> 
> If and when you try, another heads-up: ath12k is currently running into 
> an rtln deadlock quite often (but not always) when hostapd is stopped 
> (or fails) because that's also bringing the interface down.
> 
> Fortunately, Baochen Qiang ported the fix for this issue from ath11k to 
> ath12k[0], but it wasn't applied to ath-next or main yet, so you will 
> likely see a very irritating deadlock requiring a hard machine reset if 
> you don't also use his patch when testing.
> 
> His patch, apart from fixing the deadlock, also ports some parts of the 
> ath11k patch set I mentioned in my previous mail, but unfortunately 
> doesn't fix the chan list update race I'm seeing.
> 
> I'll dig further into it and hope to come up with something usable in 
> the next few days.
> 
> 
> 
> Mihai
> 
> 
> [0] https://lore.kernel.org/ath12k/20240830023901.204746-1- 
> quic_bqiang at quicinc.com/