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 |
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
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.
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.
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/