mbox series

[0/8] wifi: ath12k: handle change_vif_links() callback

Message ID 20250204-unlink_link_arvif_from_chanctx-v1-0-675bd4cea339@oss.qualcomm.com (mailing list archive)
Headers show
Series wifi: ath12k: handle change_vif_links() callback | expand

Message

Aditya Kumar Singh Feb. 4, 2025, 4:23 a.m. UTC
Currently, links in an interface are allocated during channel assignment
via assign_vif_chanctx(). Conversely, links are deleted during channel
unassignment via unassign_vif_chanctx(). However, deleting links during
channel unassignment does not comply with mac80211 link handling.
Therefore, this process should be managed within change_vif_links().

This series aims to add support to handle links in change_vif_links()
callback.

Patches 1-2 are making debug infra to work without device info.

Patches 3-8 are the ones changing the code to handle as mentioned above.

NOTE:
* A new ath12k-check warning comes which probably needs to be added to
ignore list

drivers/net/wireless/ath/ath12k/debug.c:69: Prefer [subsystem eg: netdev]_dbg([subsystem]dev, ... then dev_dbg(dev, ... then pr_debug(...  to printk(KERN_DEBUG ...

This is because, since device info is not known can not use netdev_ or dev_
dbg family. pr_debug() is an option but that will require DYNAMIC_DEBUG
and then ath12k needs to be probed with dyndbg=+p which we don't want in
ath. Hence, only option left is to use printk() directly.

---
Aditya Kumar Singh (8):
      wifi: ath12k: eliminate redundant debug mask check in ath12k_dbg()
      wifi: ath12k: introduce ath12k_generic_dbg()
      wifi: ath12k: remove redundant vif settings during link interface creation
      wifi: ath12k: remove redundant logic for initializing arvif
      wifi: ath12k: use arvif instead of link_conf in ath12k_mac_set_key()
      wifi: ath12k: relocate a few functions in mac.c
      wifi: ath12k: allocate new links in change_vif_links()
      wifi: ath12k: handle link removal in change_vif_links()

 drivers/net/wireless/ath/ath12k/debug.c |   6 +-
 drivers/net/wireless/ath/ath12k/debug.h |   7 +-
 drivers/net/wireless/ath/ath12k/mac.c   | 288 +++++++++++++++++++-------------
 3 files changed, 182 insertions(+), 119 deletions(-)
---
base-commit: 48a62436540224f57013c27519dd2aa3ddd714c9
change-id: 20241210-unlink_link_arvif_from_chanctx-315159c5ac63

Comments

Nicolas Escande Feb. 4, 2025, 10:02 a.m. UTC | #1
On Tue Feb 4, 2025 at 5:23 AM CET, Aditya Kumar Singh wrote:
> Currently, links in an interface are allocated during channel assignment
> via assign_vif_chanctx(). Conversely, links are deleted during channel
> unassignment via unassign_vif_chanctx(). However, deleting links during
> channel unassignment does not comply with mac80211 link handling.
> Therefore, this process should be managed within change_vif_links().
>
> This series aims to add support to handle links in change_vif_links()
> callback.
>
> Patches 1-2 are making debug infra to work without device info.
>
> Patches 3-8 are the ones changing the code to handle as mentioned above.
>
> NOTE:
> * A new ath12k-check warning comes which probably needs to be added to
> ignore list
>
> drivers/net/wireless/ath/ath12k/debug.c:69: Prefer [subsystem eg: netdev]_dbg([subsystem]dev, ... then dev_dbg(dev, ... then pr_debug(...  to printk(KERN_DEBUG ...
>
> This is because, since device info is not known can not use netdev_ or dev_
> dbg family. pr_debug() is an option but that will require DYNAMIC_DEBUG
> and then ath12k needs to be probed with dyndbg=+p which we don't want in
> ath. Hence, only option left is to use printk() directly.
>
Hello,

When applying this series I am no longer able to start an AP on a DFS channel.
(I don't know specifically which patch though)

After the initial CAC period I get the following kernel message:
	[   45.248441] ath12k_pci 0003:01:00.0: cannot install key for non-existent peer 3a:07:16:d8:00:08
And then hostapd goes in failed state:
	wlan0: interface state UNINITIALIZED->COUNTRY_UPDATE
	ACS: Automatic channel selection started, this may take a bit
	wlan0: interface state COUNTRY_UPDATE->ACS
	wlan0: ACS-STARTED
	wlan0: ACS-COMPLETED freq=5620 channel=124
	wlan0: interface state ACS->DFS
	wlan0: DFS-CAC-START freq=5620 chan=124 sec_chan=1, width=2, seg0=114, seg1=0, cac_time=5s
	wlan0: DFS-CAC-COMPLETED success=1 freq=5620 ht_enabled=0 chan_offset=0 chan_width=5 cf1=5570 cf2=0 radar_detected=0
	wlan0: nl80211: kernel reports: key addition failed
	Interface initialization failed
	wlan0: interface state DFS->DISABLED
	wlan0: AP-DISABLED

Maybe I missed something ? Is there another series this one depends upon that I
should have applied before ?

Thanks
Aditya Kumar Singh Feb. 4, 2025, 10:23 a.m. UTC | #2
On 2/4/25 15:32, Nicolas Escande wrote:
> Hello,
> 
> When applying this series I am no longer able to start an AP on a DFS channel.
> (I don't know specifically which patch though)
> 

Thanks for reporting this. I think non-DFS channel should be working 
fine right?

Anyways, I'm able to repro the issue locally. Let me investigate further 
and come back.

> After the initial CAC period I get the following kernel message:
> 	[   45.248441] ath12k_pci 0003:01:00.0: cannot install key for non-existent peer 3a:07:16:d8:00:08
> And then hostapd goes in failed state:
> 	wlan0: interface state UNINITIALIZED->COUNTRY_UPDATE
> 	ACS: Automatic channel selection started, this may take a bit
> 	wlan0: interface state COUNTRY_UPDATE->ACS
> 	wlan0: ACS-STARTED
> 	wlan0: ACS-COMPLETED freq=5620 channel=124
> 	wlan0: interface state ACS->DFS
> 	wlan0: DFS-CAC-START freq=5620 chan=124 sec_chan=1, width=2, seg0=114, seg1=0, cac_time=5s
> 	wlan0: DFS-CAC-COMPLETED success=1 freq=5620 ht_enabled=0 chan_offset=0 chan_width=5 cf1=5570 cf2=0 radar_detected=0
> 	wlan0: nl80211: kernel reports: key addition failed
> 	Interface initialization failed
> 	wlan0: interface state DFS->DISABLED
> 	wlan0: AP-DISABLED
> 
> Maybe I missed something ? Is there another series this one depends upon that I
> should have applied before ?

No known dependency as such.
Nicolas Escande Feb. 4, 2025, 10:44 a.m. UTC | #3
On Tue Feb 4, 2025 at 11:23 AM CET, Aditya Kumar Singh wrote:
> On 2/4/25 15:32, Nicolas Escande wrote:
>> Hello,
>> 
>> When applying this series I am no longer able to start an AP on a DFS channel.
>> (I don't know specifically which patch though)
>> 
>
> Thanks for reporting this. I think non-DFS channel should be working 
> fine right?
Right non DFS channels are ok, only DFS ones, and not from the get go but after
the initial CAC, when they switch to operational mode.
>
> Anyways, I'm able to repro the issue locally. Let me investigate further 
> and come back.
I'll happily test what you can throw at me.
>
>> After the initial CAC period I get the following kernel message:
>> 	[   45.248441] ath12k_pci 0003:01:00.0: cannot install key for non-existent peer 3a:07:16:d8:00:08
>> And then hostapd goes in failed state:
>> 	wlan0: interface state UNINITIALIZED->COUNTRY_UPDATE
>> 	ACS: Automatic channel selection started, this may take a bit
>> 	wlan0: interface state COUNTRY_UPDATE->ACS
>> 	wlan0: ACS-STARTED
>> 	wlan0: ACS-COMPLETED freq=5620 channel=124
>> 	wlan0: interface state ACS->DFS
>> 	wlan0: DFS-CAC-START freq=5620 chan=124 sec_chan=1, width=2, seg0=114, seg1=0, cac_time=5s
>> 	wlan0: DFS-CAC-COMPLETED success=1 freq=5620 ht_enabled=0 chan_offset=0 chan_width=5 cf1=5570 cf2=0 radar_detected=0
>> 	wlan0: nl80211: kernel reports: key addition failed
>> 	Interface initialization failed
>> 	wlan0: interface state DFS->DISABLED
>> 	wlan0: AP-DISABLED
>> 
>> Maybe I missed something ? Is there another series this one depends upon that I
>> should have applied before ?
>
> No known dependency as such.
Good, as I have a few other series applied in my tree I was affraid it might be
something on my side.
Aditya Kumar Singh Feb. 4, 2025, 5:19 p.m. UTC | #4
On 2/4/25 16:14, Nicolas Escande wrote:
> On Tue Feb 4, 2025 at 11:23 AM CET, Aditya Kumar Singh wrote:
>> On 2/4/25 15:32, Nicolas Escande wrote:
>>> Hello,
>>>
>>> When applying this series I am no longer able to start an AP on a DFS channel.
>>> (I don't know specifically which patch though)
>>>
>>
>> Thanks for reporting this. I think non-DFS channel should be working
>> fine right?
> Right non DFS channels are ok, only DFS ones, and not from the get go but after
> the initial CAC, when they switch to operational mode.
>>
>> Anyways, I'm able to repro the issue locally. Let me investigate further
>> and come back.
> I'll happily test what you can throw at me.

:)

I have posted v2 [1] fixing the reported DFS issue as well. When you 
have time, could you test and confirm? Locally I'm able to see 
DFS/non-DFS working fine now.

[1]: 
https://lore.kernel.org/linux-wireless/20250204-unlink_link_arvif_from_chanctx-v2-0-764fb5973c1a@oss.qualcomm.com/