Currently, mem_ce and mem iomem addresses are used to calculate the
CE offset address. mem_ce is initialized with mem address, and for
targets where ce_remap is needed, mem_ce is remapped to a new address
space during AHB probe.
For targets such as WCN6750 in which CE address space is same as WCSS
address space (i.e. "ce_remap" hw_param is set to false), mem_ce and
mem iomem addresses are same. In the initial SRNG setup for such targets,
the CE offset address and hence CE register base addresses are
calculated correctly in ath11k_hal_srng_init() as both mem and mem_ce
are initialized with same iomem address.
Later, after the firmware download, mem is initialized with BAR address
received in qmi_wlanfw_device_info_resp_msg_v01 QMI message, while mem_ce
is not updated.
After initial setup success, during Subsystem Restart (SSR), as part
of reinitialization, ath11k_hal_srng_init() will be called again,
and CE offset address will be calculated incorrectly this time as mem_ce
address was not updated. Due to the incorrect CE offset address,
APPS accesses an invalid CE register address which leads to improper
behavior in firmware after SSR is triggered.
To fix the above issue, update mem_ce to mem iomem address in
ath11k_qmi_request_device_info() for targets which do not support
ce_remap feature.
Signed-off-by: Balaji Pothunoori <quic_bpothuno@quicinc.com>
Fixes: b42b3678c9 ("wifi: ath11k: remap ce register space for IPQ5018")
Link: https://patch.msgid.link/20240927095825.22317-1-quic_bpothuno@quicinc.com
Signed-off-by: Jeff Johnson <quic_jjohnson@quicinc.com>
A previous patch addressed a fortified-memcpy warning on older compilers,
but there is still a warning on gcc-14 in some configurations:
In file included from include/linux/string.h:390,
from drivers/net/wireless/ath/ath12k/wow.c:7:
drivers/net/wireless/ath/ath12k/wow.c: In function 'ath12k_wow_convert_8023_to_80211.isra':
include/linux/fortify-string.h:114:33: error: '__builtin_memcpy' accessing 18446744073709551610 or more bytes at offsets 0 and 0 overlaps 9223372036854775797 bytes at offset -9223372036854775803 [-Werror=restrict]
include/linux/fortify-string.h:679:26: note: in expansion of macro '__fortify_memcpy_chk'
679 | #define memcpy(p, q, s) __fortify_memcpy_chk(p, q, s, \
| ^~~~~~~~~~~~~~~~~~~~
drivers/net/wireless/ath/ath12k/wow.c:199:25: note: in expansion of macro 'memcpy'
199 | memcpy(pat + a3_ofs - pkt_ofs,
| ^~~~~~
Address this the same way as the other two, using size_add().
Fixes: b49991d83b ("wifi: ath12k: fix build vs old compiler")
Fixes: 4a3c212eee ("wifi: ath12k: add basic WoW functionalities")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Kalle Valo <kvalo@kernel.org>
Link: https://patch.msgid.link/20241004095420.637091-1-arnd@kernel.org
Signed-off-by: Jeff Johnson <quic_jjohnson@quicinc.com>
The API print_array_to_buf() currently supports printing
arrays with 0 indexing. In some cases, a few arrays need
to be printed with 1-based indexing, i.e., array should be
printed, starting with 1.
Add a new version of print_array_to_buf(), named
print_array_to_buf_index(), which implements the functionality
of print_array_to_index(), but with an extra variable, pointing
to the index starting with which the array should be printed.
Modify print_array_to_buf() to call
print_array_to_buf_index() with 0 as the starting index.
Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.0.1-00029-QCAHKSWPL_SILICONZ-1
Signed-off-by: Roopni Devanathan <quic_rdevanat@quicinc.com>
Link: https://patch.msgid.link/20241004085915.1788951-1-quic_rdevanat@quicinc.com
Signed-off-by: Jeff Johnson <quic_jjohnson@quicinc.com>
During ath12k module removal, in ath12k_core_deinit(),
ath12k_mac_destroy() un-registers ah->hw from mac80211 and frees
the ah->hw as well as all the ar's in it. After this
ath12k_core_soc_destroy()-> ath12k_dp_free()-> ath12k_dp_cc_cleanup()
tries to access one of the freed ar's from pending skb.
This is because during mac destroy, driver failed to flush few
data packets, which were accessed later in ath12k_dp_cc_cleanup()
and freed, but using ar from the packet led to this use-after-free.
BUG: KASAN: use-after-free in ath12k_dp_cc_cleanup.part.0+0x5e2/0xd40 [ath12k]
Write of size 4 at addr ffff888150bd3514 by task modprobe/8926
CPU: 0 UID: 0 PID: 8926 Comm: modprobe Not tainted
6.11.0-rc2-wt-ath+ #1746
Hardware name: Intel(R) Client Systems NUC8i7HVK/NUC8i7HVB, BIOS
HNKBLi70.86A.0067.2021.0528.1339 05/28/2021
Call Trace:
<TASK>
dump_stack_lvl+0x7d/0xe0
print_address_description.constprop.0+0x33/0x3a0
print_report+0xb5/0x260
? kasan_addr_to_slab+0x24/0x80
kasan_report+0xd8/0x110
? ath12k_dp_cc_cleanup.part.0+0x5e2/0xd40 [ath12k]
? ath12k_dp_cc_cleanup.part.0+0x5e2/0xd40 [ath12k]
kasan_check_range+0xf3/0x1a0
__kasan_check_write+0x14/0x20
ath12k_dp_cc_cleanup.part.0+0x5e2/0xd40 [ath12k]
ath12k_dp_free+0x178/0x420 [ath12k]
ath12k_core_stop+0x176/0x200 [ath12k]
ath12k_core_deinit+0x13f/0x210 [ath12k]
ath12k_pci_remove+0xad/0x1c0 [ath12k]
pci_device_remove+0x9b/0x1b0
device_remove+0xbf/0x150
device_release_driver_internal+0x3c3/0x580
? __kasan_check_read+0x11/0x20
driver_detach+0xc4/0x190
bus_remove_driver+0x130/0x2a0
driver_unregister+0x68/0x90
pci_unregister_driver+0x24/0x240
? find_module_all+0x13e/0x1e0
ath12k_pci_exit+0x10/0x20 [ath12k]
__do_sys_delete_module+0x32c/0x580
? module_flags+0x2f0/0x2f0
? kmem_cache_free+0xf0/0x410
? __fput+0x56f/0xab0
? __fput+0x56f/0xab0
? debug_smp_processor_id+0x17/0x20
__x64_sys_delete_module+0x4f/0x70
x64_sys_call+0x522/0x9f0
do_syscall_64+0x64/0x130
entry_SYSCALL_64_after_hwframe+0x4b/0x53
RIP: 0033:0x7f8182c6ac8b
Commit 24de1b7b23 ("wifi: ath12k: fix flush failure in recovery
scenarios") added the change to decrement the pending packets count
in case of recovery which make sense as ah->hw as well all
ar's in it are intact during recovery, but during core deinit there
is no use in decrementing packets count or waking up the empty waitq
as the module is going to be removed also ar's from pending skb's
can't be used and the packets should just be released back.
To fix this, avoid accessing ar from skb->cb when driver is being
unregistered.
Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.1.1-00214-QCAHKSWPL_SILICONZ-1
Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3
Fixes: 24de1b7b23 ("wifi: ath12k: fix flush failure in recovery scenarios")
Signed-off-by: Rameshkumar Sundaram <quic_ramess@quicinc.com>
Acked-by: Jeff Johnson <quic_jjohnson@quicinc.com>
Link: https://patch.msgid.link/20241001092652.3134334-1-quic_ramess@quicinc.com
Signed-off-by: Jeff Johnson <quic_jjohnson@quicinc.com>
During peer create, dp setup for the peer is done where Rx TID is
updated for all the TIDs. Peer object for self peer will not go through
dp setup.
When core halts, dp cleanup is done for all the peers. While cleanup,
rx_tid::ab is accessed which causes below stack trace for self peer.
WARNING: CPU: 6 PID: 12297 at drivers/net/wireless/ath/ath12k/dp_rx.c:851
Call Trace:
__warn+0x7b/0x1a0
ath12k_dp_rx_frags_cleanup+0xd2/0xe0 [ath12k]
report_bug+0x10b/0x200
handle_bug+0x3f/0x70
exc_invalid_op+0x13/0x60
asm_exc_invalid_op+0x16/0x20
ath12k_dp_rx_frags_cleanup+0xd2/0xe0 [ath12k]
ath12k_dp_rx_frags_cleanup+0xca/0xe0 [ath12k]
ath12k_dp_rx_peer_tid_cleanup+0x39/0xa0 [ath12k]
ath12k_mac_peer_cleanup_all+0x61/0x100 [ath12k]
ath12k_core_halt+0x3b/0x100 [ath12k]
ath12k_core_reset+0x494/0x4c0 [ath12k]
sta object in peer will be updated when remote peer is created. Hence
use peer::sta to detect the self peer and skip the cleanup.
Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.0.1-00029-QCAHKSWPL_SILICONZ-1
Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3
Fixes: d889913205 ("wifi: ath12k: driver for Qualcomm Wi-Fi 7 devices")
Signed-off-by: Ramya Gnanasekar <quic_rgnanase@quicinc.com>
Acked-by: Jeff Johnson <quic_jjohnson@quicinc.com>
Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com>
Link: https://patch.msgid.link/20240905042851.2282306-1-quic_rgnanase@quicinc.com
Those two fields are used to store the per SPT page of tx/rx descriptors send to
the firmware for cookie conversion. Right now they are in struct ath12k_spt_info
which means they are duplicated PPT page times while we only need one instance
of them. This works for now as we always use the first spt_info as a global
storage for all PPT pages.
Let's move them into struct ath12k_dp where they belong, alongside of the
spt_info array they are tied to, to avoid waisting a good bit of memory.
Tested-on: QCN9274 hw2.0 PCI CI_WLAN.WBE.1.3-03283.1-QCAHKSWPL_SILICONZ-2
Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3
Signed-off-by: Nicolas Escande <nico.escande@gmail.com>
Reviewed-by: Remi Pommarel <repk@triplefau.lt>
Acked-by: Jeff Johnson <quic_jjohnson@quicinc.com>
Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com>
Link: https://patch.msgid.link/20240830081942.3623380-1-nico.escande@gmail.com
On SC7280 platforms which are running with TrustZone, it is not
necessary to manually map the memory regions used by the wifi hardware.
However, ath11k will currently fail to load unless both memory regions
are specified.
This breaks wifi on the rb3gen2 which only specifies the firmware memory
region and does not use the CE region.
Adjust the order of operations in ath11k_ahb_fw_resources_init() to
check for the wifi-firmware subnode before attempting to parse the
memory regions.
Signed-off-by: Caleb Connolly <caleb.connolly@linaro.org>
Acked-by: Jeff Johnson <quic_jjohnson@quicinc.com>
Reviewed-by: Raj Kumar Bhagat <quic_rajkbhag@quicinc.com>
Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com>
Link: https://patch.msgid.link/20240904095815.1572186-2-caleb.connolly@linaro.org
Fix the following W=1 kernel build warning:
drivers/net/wireless/ath/ath11k/wow.c: In function ‘ath11k_vif_wow_set_wakeups’:
drivers/net/wireless/ath/ath11k/wow.c:461:1: warning: the frame size of 1352 bytes is larger than 1024 bytes [-Wframe-larger-than=]
Remove the nonessential variable 'struct cfg80211_pkt_pattern
old_pattern' by relocating bitmask to bytemask conversion into
ath11k_wow_convert_8023_to_80211().
Tested-on: WCN6855 hw2.1 PCI WLAN.HSP.1.1-04358-QCAHSPSWPL_V1_V2_SILICONZ_LITE-1
Signed-off-by: Miaoqing Pan <quic_miaoqing@quicinc.com>
Acked-by: Jeff Johnson <quic_jjohnson@quicinc.com>
Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com>
Link: https://patch.msgid.link/20240829075253.657667-1-quic_miaoqing@quicinc.com
WCN6750 firmware sends the log messages via WMI_DIAG_EVENTID only
when the host driver enables the same via QMI_WLANFW_WLAN_INI_REQ_V01
QMI message. This is further controlled via fw_wmi_diag_event.
Hence set this flag to true for the firmware to send the logs.
These logs are further collected in the user space through
the trace infrastructure.
Tested-on: WCN6750 hw1.0 AHB WLAN.MSL.2.0.c2-00233-QCAMSLSWPLZ-1
Signed-off-by: Balaji Pothunoori <quic_bpothuno@quicinc.com>
Acked-by: Jeff Johnson <quic_jjohnson@quicinc.com>
Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com>
Link: https://patch.msgid.link/20240828103043.2413-1-quic_bpothuno@quicinc.com
Currently struct ath11k_hal::srng_config pointer is not assigned
to NULL after freeing the memory in ath11k_hal_srng_deinit().
This could lead to double free issue in a scenario where
ath11k_hal_srng_deinit() is invoked back to back.
In the current code, although the chances are very low, the above
said scenario could happen when hardware recovery has failed and
then there is another FW assert where ath11k_hal_srng_deinit() is
invoked once again as part of recovery.
Fix this by assigning the struct ath11k_hal::srng_config pointer
to NULL after freeing the memory.
Tested-on: WCN6750 hw1.0 AHB WLAN.MSL.1.0.1-00887-QCAMSLSWPLZ-1
Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.16
Tested-on: IPQ5018 hw1.0 AHB WLAN.HK.2.6.0.1-00861-QCAHKSWPL_SILICONZ-1
Tested-on: QCN9074 hw1.0 PCI WLAN.HK.2.7.0.1-01744-QCAHKSWPL_SILICONZ-1
Signed-off-by: Manikanta Pubbisetty <quic_mpubbise@quicinc.com>
Signed-off-by: Balaji Pothunoori <quic_bpothuno@quicinc.com>
Acked-by: Jeff Johnson <quic_jjohnson@quicinc.com>
Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com>
Link: https://patch.msgid.link/20240826053326.8878-1-quic_bpothuno@quicinc.com
I found the following bug in my fuzzer:
UBSAN: array-index-out-of-bounds in drivers/net/wireless/ath/ath9k/htc_hst.c:26:51
index 255 is out of range for type 'htc_endpoint [22]'
CPU: 0 UID: 0 PID: 8 Comm: kworker/0:0 Not tainted 6.11.0-rc6-dirty #14
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014
Workqueue: events request_firmware_work_func
Call Trace:
<TASK>
dump_stack_lvl+0x180/0x1b0
__ubsan_handle_out_of_bounds+0xd4/0x130
htc_issue_send.constprop.0+0x20c/0x230
? _raw_spin_unlock_irqrestore+0x3c/0x70
ath9k_wmi_cmd+0x41d/0x610
? mark_held_locks+0x9f/0xe0
...
Since this bug has been confirmed to be caused by insufficient verification
of conn_rsp_epid, I think it would be appropriate to add a range check for
conn_rsp_epid to htc_connect_service() to prevent the bug from occurring.
Fixes: fb9987d0f7 ("ath9k_htc: Support for AR9271 chipset.")
Signed-off-by: Jeongjun Park <aha310510@gmail.com>
Acked-by: Toke Høiland-Jørgensen <toke@toke.dk>
Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com>
Link: https://patch.msgid.link/20240909103855.68006-1-aha310510@gmail.com
Display channel info in the RPM map debugfs output.
With this, cat /sys/kernel/debug/cn10k/rvu_pf_rpm_map
would display channel number for each device in addition to
the existing data.
Sample output:
PCI dev RVU PF Func NIX block rpm LMAC CHAN
0002:02:00.0 0x400 NIX0 rpm0 LMAC0 256
Signed-off-by: Linu Cherian <lcherian@marvell.com>
Link: https://patch.msgid.link/20240912161450.164402-3-lcherian@marvell.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Marc Kleine-Budde says:
====================
pull-request: can-next 2024-09-11
The first patch is by Uwe Kleine-König targets all CAN platform driver
and switches back the remove function to struct
platform_driver::remove().
A patch by Stefan Mätje fixes the help text of the ESD USB driver.
Jake Hamby's patch masks an unneeded interrupt in the m_can driver.
The last 2 patches target the rockchip_canfd driver. Arnd Bergmann's
patch reworks the delay calculation for the timekeeping worker, a
patch by me fixes the decoding of the error code register.
* tag 'linux-can-next-for-6.12-20240911' of git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can-next:
can: rockchip_canfd: rkcanfd_handle_error_int_reg_ec(): fix decoding of error code register
can: rockchip_canfd: rkcanfd_timestamp_init(): rework delay calculation
can: m_can: m_can_chip_config(): mask timestamp wraparound IRQ
can: usb: Kconfig: Fix list of devices for esd_usb driver
can: Switch back to struct platform_driver::remove()
====================
Link: https://patch.msgid.link/20240912080438.2826895-1-mkl@pengutronix.de
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Nelson Escobar says:
====================
enic: Report per queue stats
Patch #1: Use a macro instead of static const variables for array sizes. I
didn't want to add more static const variables in the next patch
so clean up the existing ones first.
Patch #2: Collect per queue statistics
Patch #3: Report per queue stats in netdev qstats
Patch #4: Report some per queue stats in ethtool
# NETIF="eno6" tools/testing/selftests/drivers/net/stats.py
KTAP version 1
1..5
ok 1 stats.check_pause # XFAIL pause not supported by the device
ok 2 stats.check_fec # XFAIL FEC not supported by the device
ok 3 stats.pkt_byte_sum
ok 4 stats.qstat_by_ifindex
ok 5 stats.check_down
# tools/net/ynl/cli.py --spec Documentation/netlink/specs/netdev.yaml \
--dump qstats-get --json '{"ifindex": "34"}'
[{'ifindex': 34,
'rx-bytes': 66762680,
'rx-csum-unnecessary': 1009345,
'rx-hw-drop-overruns': 0,
'rx-hw-drops': 0,
'rx-packets': 1009673,
'tx-bytes': 137936674899,
'tx-csum-none': 125,
'tx-hw-gso-packets': 2408712,
'tx-needs-csum': 2431531,
'tx-packets': 15475466,
'tx-stop': 0,
'tx-wake': 0}]
v2: https://lore.kernel.org/20240905010900.24152-1-neescoba@cisco.com
v1: https://lore.kernel.org/20240823235401.29996-1-neescoba@cisco.com
====================
Link: https://patch.msgid.link/20240912005039.10797-1-neescoba@cisco.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Ido Schimmel says:
====================
net: fib_rules: Add DSCP selector support
Currently, the kernel rejects IPv4 FIB rules that try to match on the
upper three DSCP bits:
# ip -4 rule add tos 0x1c table 100
# ip -4 rule add tos 0x3c table 100
Error: Invalid tos.
The reason for that is that historically users of the FIB lookup API
only populated the lower three DSCP bits in the TOS field of the IPv4
flow key ('flowi4_tos'), which fits the TOS definition from the initial
IPv4 specification (RFC 791).
This is not very useful nowadays and instead some users want to be able
to match on the six bits DSCP field, which replaced the TOS and IP
precedence fields over 25 years ago (RFC 2474). In addition, the current
behavior differs between IPv4 and IPv6 which does allow users to match
on the entire DSCP field using the TOS selector.
Recent patchsets made sure that callers of the FIB lookup API now
populate the entire DSCP field in the IPv4 flow key. Therefore, it is
now possible to extend FIB rules to match on DSCP.
This is done by adding a new DSCP attribute which is implemented for
both IPv4 and IPv6 to provide user space programs a consistent behavior
between both address families.
The behavior of the old TOS selector is unchanged and IPv4 FIB rules
using it will only match on the lower three DSCP bits. The kernel will
reject rules that try to use both selectors.
Patch #1 adds the new DSCP attribute but rejects its usage.
Patches #2-#3 implement IPv4 and IPv6 support.
Patch #4 allows user space to use the new attribute.
Patches #5-#6 add selftests.
====================
Link: https://patch.msgid.link/20240911093748.3662015-1-idosch@nvidia.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Test that locally generated traffic from a socket that specifies a DS
Field using the IP_TOS / IPV6_TCLASS socket options is correctly
redirected using a FIB rule that matches on DSCP. Add negative tests to
verify that the rule is not it when it should not. Test with both IPv4
and IPv6 and with both TCP and UDP sockets.
Signed-off-by: Ido Schimmel <idosch@nvidia.com>
Reviewed-by: Guillaume Nault <gnault@redhat.com>
Reviewed-by: David Ahern <dsahern@kernel.org>
Link: https://patch.msgid.link/20240911093748.3662015-7-idosch@nvidia.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
