linux.git/drivers/net/wireless/ath, branch v6.9

wifi: ath11k: use RCU when accessing struct inet6_dev::ac_list

2024-04-16T15:25:20+00:00

Commit c3718936ec47 ("ipv6: anycast: complete RCU handling of struct
ifacaddr6") converted struct inet6_dev::ac_list to use RCU but missed that
ath11k also accesses this list. Now sparse warns:

drivers/net/wireless/ath/ath11k/mac.c:9145:21: warning: incorrect type in assignment (different address spaces)
drivers/net/wireless/ath/ath11k/mac.c:9145:21:    expected struct ifacaddr6 *ifaca6
drivers/net/wireless/ath/ath11k/mac.c:9145:21:    got struct ifacaddr6 [noderef] __rcu *ac_list
drivers/net/wireless/ath/ath11k/mac.c:9145:53: warning: incorrect type in assignment (different address spaces)
drivers/net/wireless/ath/ath11k/mac.c:9145:53:    expected struct ifacaddr6 *ifaca6
drivers/net/wireless/ath/ath11k/mac.c:9145:53:    got struct ifacaddr6 [noderef] __rcu *aca_next

Fix it by using rtnl_dereference(). Also add a note that read_lock_bh() calls
rcu_read_lock() which I was not aware of.

Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.37

Fixes: c3718936ec47 ("ipv6: anycast: complete RCU handling of struct ifacaddr6")
Signed-off-by: Kalle Valo 
Acked-by: Jeff Johnson 
Signed-off-by: Kalle Valo 
Link: https://msgid.link/20240411165516.4070649-2-kvalo@kernel.org

wifi: ath12k: fix license in p2p.c and p2p.h

2024-02-28T14:09:29+00:00

ath12k uses BSD-3-Clause-Clear, not ISC.

Signed-off-by: Kalle Valo 
Link: https://msgid.link/20240226180745.3195805-1-kvalo@kernel.org

wifi: ath11k: constify MHI channel and controller configs

2024-02-28T14:08:39+00:00

Unlike the event configuration which can be modified by MHI, the
channel and controller configurations are expected to be const. And
since they are not modified locally, constify them to prevent runtime
modification.

No functional changes, compile tested only.

Signed-off-by: Jeff Johnson 
Signed-off-by: Kalle Valo 
Link: https://msgid.link/20240223-mhi-const-wifi-ath11k-v1-1-51b9d42d2639@quicinc.com

wifi: ath12k: add rcu lock for ath12k_wmi_p2p_noa_event()

2024-02-28T14:07:20+00:00

Warning will appear when running P2P GO:

WARNING: suspicious RCU usage
drivers/net/wireless/ath/ath12k/mac.c:583 suspicious rcu_dereference_check() usage!
other info that might help us debug this:
rcu_scheduler_active = 2, debug_locks = 1
no locks held by swapper/0/0.
stack backtrace:
CPU: 0 PID: 0 Comm: swapper/0 Not tainted 6.8.0-rc4-wt-ath+ #4
Call Trace:
 
 dump_stack_lvl+0x82/0xa0
 dump_stack+0x14/0x20
 lockdep_rcu_suspicious+0x214/0x3b0
 ath12k_mac_get_ar_by_vdev_id+0x192/0x220 [ath12k]
 ath12k_wmi_op_rx+0x2d7/0x1b40 [ath12k]

ath12k_mac_get_ar_by_vdev_id() requires its callers to have called
rcu_read_lock(), but in ath12k_wmi_p2p_noa_event() it is called without
doing so, and hence the warning was triggered.

Add rcu_read_lock() and rcu_read_unlock() to avoid warning.

Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3

Fixes: 9411eecb60cb ("wifi: ath12k: implement handling of P2P NoA event")
Reported-by: Kalle Valo 
Closes: https://lore.kernel.org/linux-wireless/87o7cusyvw.fsf@kernel.org/
Signed-off-by: Kang Yang 
Acked-by: Jeff Johnson 
Signed-off-by: Kalle Valo 
Link: https://msgid.link/20240223054505.438839-1-quic_kangyang@quicinc.com

wifi: ath11k: decrease MHI channel buffer length to 8KB

2024-02-28T14:06:53+00:00

Currently buf_len field of ath11k_mhi_config_qca6390 is assigned
with 0, making MHI use a default size, 64KB, to allocate channel
buffers. This is likely to fail in some scenarios where system
memory is highly fragmented and memory compaction or reclaim is
not allowed.

There is a fail report which is caused by it:
kworker/u32:45: page allocation failure: order:4, mode:0x40c00(GFP_NOIO|__GFP_COMP), nodemask=(null),cpuset=/,mems_allowed=0
CPU: 0 PID: 19318 Comm: kworker/u32:45 Not tainted 6.8.0-rc3-1.gae4495f-default #1 openSUSE Tumbleweed (unreleased) 493b6d5b382c603654d7a81fc3c144d59a1dfceb
Workqueue: events_unbound async_run_entry_fn
Call Trace:
 
 dump_stack_lvl+0x47/0x60
 warn_alloc+0x13a/0x1b0
 ? srso_alias_return_thunk+0x5/0xfbef5
 ? __alloc_pages_direct_compact+0xab/0x210
 __alloc_pages_slowpath.constprop.0+0xd3e/0xda0
 __alloc_pages+0x32d/0x350
 ? mhi_prepare_channel+0x127/0x2d0 [mhi 40df44e07c05479f7a6e7b90fba9f0e0031a7814]
 __kmalloc_large_node+0x72/0x110
 __kmalloc+0x37c/0x480
 ? mhi_map_single_no_bb+0x77/0xf0 [mhi 40df44e07c05479f7a6e7b90fba9f0e0031a7814]
 ? mhi_prepare_channel+0x127/0x2d0 [mhi 40df44e07c05479f7a6e7b90fba9f0e0031a7814]
 mhi_prepare_channel+0x127/0x2d0 [mhi 40df44e07c05479f7a6e7b90fba9f0e0031a7814]
 __mhi_prepare_for_transfer+0x44/0x80 [mhi 40df44e07c05479f7a6e7b90fba9f0e0031a7814]
 ? __pfx_____mhi_prepare_for_transfer+0x10/0x10 [mhi 40df44e07c05479f7a6e7b90fba9f0e0031a7814]
 device_for_each_child+0x5c/0xa0
 ? __pfx_pci_pm_resume+0x10/0x10
 ath11k_core_resume+0x65/0x100 [ath11k a5094e22d7223135c40d93c8f5321cf09fd85e4e]
 ? srso_alias_return_thunk+0x5/0xfbef5
 ath11k_pci_pm_resume+0x32/0x60 [ath11k_pci 830b7bfc3ea80ebef32e563cafe2cb55e9cc73ec]
 ? srso_alias_return_thunk+0x5/0xfbef5
 dpm_run_callback+0x8c/0x1e0
 device_resume+0x104/0x340
 ? __pfx_dpm_watchdog_handler+0x10/0x10
 async_resume+0x1d/0x30
 async_run_entry_fn+0x32/0x120
 process_one_work+0x168/0x330
 worker_thread+0x2f5/0x410
 ? __pfx_worker_thread+0x10/0x10
 kthread+0xe8/0x120
 ? __pfx_kthread+0x10/0x10
 ret_from_fork+0x34/0x50
 ? __pfx_kthread+0x10/0x10
 ret_from_fork_asm+0x1b/0x30
 

Actually those buffers are used only by QMI target -> host communication.
And for WCN6855 and QCA6390, the largest packet size for that is less
than 6KB. So change buf_len field to 8KB, which results in order 1
allocation if page size is 4KB. In this way, we can at least save some
memory, and as well as decrease the possibility of allocation failure
in those scenarios.

Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.30

Reported-by: Vlastimil Babka 
Closes: https://lore.kernel.org/ath11k/96481a45-3547-4d23-ad34-3a8f1d90c1cd@suse.cz/
Signed-off-by: Baochen Qiang 
Acked-by: Jeff Johnson 
Signed-off-by: Kalle Valo 
Link: https://msgid.link/20240223053111.29170-1-quic_bqiang@quicinc.com

wifi: ath11k: thermal: don't try to register multiple times

2024-02-23T15:52:08+00:00

Every time the firmware boots we call ath11k_core_qmi_firmware_ready() which
ends up calling ath11k_thermal_register(). So we try to register thermal
devices multiple times. And when we power off the firmware during
suspend/hibernation (implemented in the next patch) we get a warning in resume:

hwmon hwmon4: PM: parent phy0 should not be sleeping

Workaround this similarly like ath11k_mac_register() does by testing
ATH11K_FLAG_REGISTERED.

Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.30

Signed-off-by: Kalle Valo 
Signed-off-by: Baochen Qiang 
Link: https://msgid.link/20240221024725.10057-6-quic_bqiang@quicinc.com

wifi: ath11k: fix warning on DMA ring capabilities event

2024-02-23T15:52:08+00:00

We are seeing below warning in both reset and suspend/resume scenarios:

[69663.691847] ath11k_pci 0000:02:00.0: Already processed, so ignoring dma ring caps

This is because ab->num_db_cap is not cleared in
ath11k_wmi_free_dbring_caps(), so clear it to avoid such
warnings.

Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.30

Signed-off-by: Kalle Valo 
Signed-off-by: Baochen Qiang 
Link: https://msgid.link/20240221024725.10057-5-quic_bqiang@quicinc.com

wifi: ath11k: do not dump SRNG statistics during resume

2024-02-23T15:52:08+00:00

Both the firmware reset feature and the power management
suspend/resume feature share common power-down and power-up
functionality. One aspect of the power-up functionality is
the handling of the ATH11K_QMI_EVENT_FW_INIT_DONE event.
When this event is received, a call is made to
ath11k_hal_dump_srng_stats(), with the purpose to collect
information that may be useful in debugging the cause of a
firmware reset.

Unfortunately, since this functionality is shared between
both the firmware reset path and the power management
resume path, the kernel log is flooded with messages during
resume. Since these messages are not useful during resume,
and in fact can be confusing and can increase the time it
takes to resume, update the logic to only call
ath11k_hal_dump_srng_stats() during firmware reset.

Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.30

Signed-off-by: Kalle Valo 
Signed-off-by: Baochen Qiang 
Link: https://msgid.link/20240221024725.10057-4-quic_bqiang@quicinc.com

wifi: ath11k: remove MHI LOOPBACK channels

2024-02-23T15:52:07+00:00

There is no driver to match these two channels, so
remove them. This fixes warnings from MHI subsystem during suspend:

mhi mhi0_LOOPBACK: 1: Failed to reset channel, still resetting
mhi mhi0_LOOPBACK: 0: Failed to reset channel, still resetting

Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.30

Signed-off-by: Kalle Valo 
Signed-off-by: Baochen Qiang 
Link: https://msgid.link/20240221024725.10057-3-quic_bqiang@quicinc.com

wifi: ath11k: rearrange IRQ enable/disable in reset path

2024-02-23T15:52:07+00:00

For non WoW suspend/resume, ath11k host powers down whole hardware
when suspend and powers up it when resume, the code path it goes
through is very like the ath11k reset logic.

In order to reuse that logic, rearrange IRQ handling in the reset
path.

Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.30

Signed-off-by: Kalle Valo 
Signed-off-by: Baochen Qiang 
Link: https://msgid.link/20240221024725.10057-2-quic_bqiang@quicinc.com