Commits · ath-pending-202504112343 · CodeLinaro / qsdk / oss / kernel / linux-ipq-5.4

Apr 11, 2025

Merge branch 'pending' into main-pending · 2cdda57f
Jeff Johnson authored 2 weeks ago

ath-pending-202504112343

2cdda57f

wifi: ath12k: support 2 channels for single pdev device · 7fb76d22

Baochen Qiang authored 2 weeks ago

For single pdev device, radio number of a device is forced as 1 in
ath12k_wmi_ext_soc_hal_reg_caps_parse(). This leads to ah->num_radio == 1
and then in ath12k_mac_setup_iface_combinations() we report to
mac/cfg80211 that only 1 channel is supported. In MLO case, it finally
results in failing to bring up the second link as it is in another
channel.

Change num_different_channels to 2 to allow a second link. Since DFS on
multiple channels are not supported yet, remove radar_detect_widths.

For now WCN7850 is the only single pdev device, so others should not be
affected.

Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3
Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c5-00284-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1
Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.3.1-00209-QCAHKSWPL_SILICONZ-1

Signed-off-by: Baochen Qiang <quic_bqiang@quicinc.com>
Link: https://patch.msgid.link/20250409-ath12k-wcn7850-mlo-support-v2-9-3801132ca2c3@quicinc.com

Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>

7fb76d22

wifi: ath12k: don't skip non-primary links for WCN7850 · b4c6936c

Baochen Qiang authored 2 weeks ago

The primary link check bypasses REO queue setup for non-primary links
in ath12k_dp_rx_peer_tid_setup(), this works for QCN9274 but breaks
WCN7850 as WCN7850 needs it to be done for each link peer.

Add a new hardware parameter to differentiate them.

Signed-off-by: Baochen Qiang <quic_bqiang@quicinc.com>
Link: https://patch.msgid.link/20250409-ath12k-wcn7850-mlo-support-v2-8-3801132ca2c3@quicinc.com

Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>

b4c6936c

wifi: ath12k: alloc REO queue per station · bc8d4327

Baochen Qiang authored 2 weeks ago

In MLO case, all link peers share the same REO queue, so the queue
should be allocated only once, currently this is done by checking
primary_link flag in ath12k_dp_rx_peer_tid_setup(). However, the
check not only avoids duplicate allocation, but also bypasses sending
queue configuration to firmware for non-primary links. In an upcoming
patch, changes will be added to make this check no-ops for WCN7850,
as WCN7850 firmware needs to be explicitly notified each link peer's
queue configuration. That said, the duplicate allocation would arise
again after that change, hence it needs to be resolved before hand.

Since all link peers share the same queue, it should be allocated per
MLD peer, not per link peer. So change to do allocation once and save
it in MLD peer, link peers can simply get queue configuration from
there.

Also relocate ath12k_reoq_buf structure to core.h to avoid circular
dependency.

Signed-off-by: Baochen Qiang <quic_bqiang@quicinc.com>
Link: https://patch.msgid.link/20250409-ath12k-wcn7850-mlo-support-v2-7-3801132ca2c3@quicinc.com

Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>

bc8d4327

wifi: ath12k: group REO queue buffer parameters together · 7d656c49

Baochen Qiang authored 2 weeks ago

Currently vaddr, paddr and size fields are located together with other
fields in ath12k_dp_rx_tid structure. Logically they represents the
REO queue buffer so better to group them in an individual structure.

Introduce a new structure ath12k_reoq_buf to group them. This improves
code readability, and benefits the upcoming patch where this structure
is heavily accessed.

While at it, change vaddr type to 'void *' since it is actually not
pointing to any u32 buffer. Also rename paddr as paddr_aligned to better
reflect its actual meaning.

Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0-03427-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1.15378.4
Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c5-00284-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1
Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.3.1-00209-QCAHKSWPL_SILICONZ-1

Signed-off-by: Baochen Qiang <quic_bqiang@quicinc.com>
Link: https://patch.msgid.link/20250409-ath12k-wcn7850-mlo-support-v2-6-3801132ca2c3@quicinc.com

Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>

7d656c49

wifi: ath12k: make assoc link associate first · d2b0073e

Baochen Qiang authored 2 weeks ago

In MLO scenario WCN7850 firmware requests the assoc link to associate
before any other links. However currently in
ath12k_mac_op_vif_cfg_changed() we are doing association in an ascending
order of link id. If the assoc link does not get assigned the smallest
id, a non-assoc link gets associated first and firmware crashes.

Change to do association for the assoc link first.

Signed-off-by: Baochen Qiang <quic_bqiang@quicinc.com>
Link: https://patch.msgid.link/20250409-ath12k-wcn7850-mlo-support-v2-5-3801132ca2c3@quicinc.com

Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>

d2b0073e

wifi: ath12k: identify assoc link vif in station mode · 9abf92f1

Baochen Qiang authored 2 weeks ago

In MLO scenario, for station mode interface, WCN7850 firmware requests
the assoc link vdev to get started before any other link vdevs starts.
Firmware internally checks assoc_link field of
wmi_vdev_start_mlo_params.flags when the first vdev starts. And if the
check fails firmware crashes.

Current connection flow guarantees the assoc link vdev gets started
first (at assoc stage only one link vdev is created/started, i.e. the
assoc link vdev), however the assoc_link flag is never set, resulting
in WCN7850 firmware crash.

Note ath12k_link_sta structure already has is_assoc_link flag, and it
is properly set for assoc link. However we can not use it because it
won't be available before peer gets created, which is too late for vdev
starts.

So add a new flag 'is_sta_assoc_link' in ath12k_link_vif structure and
set it when deflink vdev is created. This is valid because we always
use deflink as the assoc link. This flag is passed to firmware vdev
starts to avoid firmware crash. Also verify the link vif/sta pair has
the same settings when creating link sta.

Signed-off-by: Baochen Qiang <quic_bqiang@quicinc.com>
Link: https://patch.msgid.link/20250409-ath12k-wcn7850-mlo-support-v2-4-3801132ca2c3@quicinc.com

Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>

9abf92f1

wifi: ath12k: support MLO as well if single_chip_mlo_support flag is set · 0d147abf

Baochen Qiang authored 2 weeks ago

Currently firmware MLO capability is validated via firmware IE, however
WCN7850 firmware does not support this method but instead advertises
MLO by single_chip_mlo_support bit in QMI phy capability message.

Change to consider single_chip_mlo_support bit as well for MLO capability
validation.

Signed-off-by: Baochen Qiang <quic_bqiang@quicinc.com>
Link: https://patch.msgid.link/20250409-ath12k-wcn7850-mlo-support-v2-3-3801132ca2c3@quicinc.com

Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>

0d147abf

wifi: ath12k: use fw_features only when it is valid · 42704df9

Baochen Qiang authored 2 weeks ago

Currently fw_features is used to check if a specific feature is supported
or not: if the feature bit is set the feature is believed to be supported,
otherwise not supported. Since fw_features is populated only when using
firmware API-2, and by default it is zero, in case of API-1 such as
WCN7850 firmware it is possible that a feature is not enabled by host
while actually firmware supports it.

To avoid this, add a new flag indicating whether fw_features has been ever
populated or not, and only when that flag is true we choose to believe
fw_features. This benefits firmware MLO capability validation in an
upcoming patch.

Signed-off-by: Baochen Qiang <quic_bqiang@quicinc.com>
Link: https://patch.msgid.link/20250409-ath12k-wcn7850-mlo-support-v2-2-3801132ca2c3@quicinc.com

Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>

42704df9

wifi: ath12k: introduce ath12k_fw_feature_supported() · 127cc4cb

Baochen Qiang authored 2 weeks ago

There are several places checking if a specific bit set in
ab->fw.fw_features, and in an upcoming patch additional check needs to be
added at all places.

Introduce a new helper ath12k_fw_feature_supported() to avoid code
duplication.

Signed-off-by: Baochen Qiang <quic_bqiang@quicinc.com>
Link: https://patch.msgid.link/20250409-ath12k-wcn7850-mlo-support-v2-1-3801132ca2c3@quicinc.com

Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>

127cc4cb

wifi: ath12k: reset MLO global memory during recovery · f948d903

Aditya Kumar Singh authored 2 weeks ago

When operating with multiple devices grouped together, the firmware stores
data related to the state machine of each partner device in the MLO global
memory region. If the firmware crashes, it updates the state to 'crashed'.
During recovery, this memory is shared with the firmware again, and upon
detecting the 'crashed' state, it reasserts. This leads to a loop of
firmware asserts and it never recovers.

Hence to fix this issue, once all devices in the group have been asserted
and powered down, reset the MLO global memory region.

Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.3.1-00173-QCAHKSWPL_SILICONZ-1
Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.4.1-00199-QCAHKSWPL_SILICONZ-1
Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3

Signed-off-by: Aditya Kumar Singh <aditya.kumar.singh@oss.qualcomm.com>
Reviewed-by: Vasanthakumar Thiagarajan <vasanthakumar.thiagarajan@oss.qualcomm.com>
Link: https://patch.msgid.link/20250408-fix_reboot_issues_with_hw_grouping-v4-9-95e7bf048595@oss.qualcomm.com

Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>

f948d903

wifi: ath12k: handle ath12k_core_reset() with hardware grouping · d66d1d7f

Aditya Kumar Singh authored 2 weeks ago

Currently, in ath12k_core_reset(), the device is powered up immediately
after a power down. However, with hardware grouping, when one device
asserts, all partner devices also asserts. If there is a delay in
processing these asserts, by the time this device powers up, other devices
might still be asserting, leading to an overall recovery failure.

To prevent this issue, ensure all asserts for a group are processed before
initiating the power-up sequence.

Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>

d66d1d7f

wifi: ath12k: handle ath12k_core_restart() with hardware grouping · 6f37995b

Aditya Kumar Singh authored 2 weeks ago

Currently, when ath12k_core_restart() is called and the ab->is_reset flag
is set, it invokes ieee80211_restart_hw() for all hardware in the same
group. However, other hardware might still be in the recovery process,
making this call inappropriate with grouping into picture.

To address this, add a condition to check if the group is ready. If the
group is not ready, do not call ieee80211_restart_hw().

Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>

6f37995b

wifi: ath12k: fix ath12k_core_pre_reconfigure_recovery() with grouping · 81276072

Aditya Kumar Singh authored 2 weeks ago

Currently, ath12k_core_pre_reconfigure_recovery() reconfigures all radios
within the same group. During grouping and driver going for a recovery,
this function is called as many times as there are devices in the group.
Consequently, it performs the same reconfiguration multiple times, which
is unnecessary.

To prevent this, add a check to continue if the action has already been
taken.

To simplify the management of various flags, the reason for hardware queues
being stopped is used as a check instead of introducing a new flag.

While at it, also add missing wiphy locks. Wiphy lock is required since
ath12k_mac_drain_tx() which is called by
ath12k_core_pre_reconfigure_recovery() needs this lock to be held by the
caller.

Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>

81276072

wifi: ath12k: fix firmware assert during reboot with hardware grouping · 039fa90e

Aditya Kumar Singh authored 2 weeks ago

At present, during PCI shutdown, the power down is only executed for a
single device. However, when operating in a group, all devices need to be
powered down simultaneously. Failure to do so will result in a firmware
assertion.

Hence, introduce a new ath12k_pci_hw_group_power_down() and call it during
power down. This will ensure that all partner devices are properly powered
down.

Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>

039fa90e

wifi: ath12k: fix ATH12K_FLAG_REGISTERED flag handling · 0365dbaf

Aditya Kumar Singh authored 2 weeks ago

Commit a5686ae8 ("wifi: ath12k: move ATH12K_FLAG_REGISTERED handling to
ath12k_mac_register()") relocated the setting of the ATH12K_FLAG_REGISTERED
flag to the ath12k_mac_register() function. However, this function only
accesses the first device (ab) via ag->ab[0], resulting in the flag being
set only for the first device in the group. Similarly,
ath12k_mac_unregister() only unsets the flag for the first device. The flag
should actually be set for all devices in the group to avoid issues during
recovery.

Hence, move setting and clearing of this flag in the function
ath12k_core_hw_group_start() and ath12k_core_hw_group_stop() respectively.

Fixes: a5686ae8 ("wifi: ath12k: move ATH12K_FLAG_REGISTERED handling to ath12k_mac_register()")
Signed-off-by: Aditya Kumar Singh <aditya.kumar.singh@oss.qualcomm.com>
Reviewed-by: Vasanthakumar Thiagarajan <vasanthakumar.thiagarajan@oss.qualcomm.com>
Link: https://patch.msgid.link/20250408-fix_reboot_issues_with_hw_grouping-v4-4-95e7bf048595@oss.qualcomm.com

Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>

0365dbaf

wifi: ath12k: fix failed to set mhi state error during reboot with hardware grouping · 5c48c18d

Aditya Kumar Singh authored 2 weeks ago

With hardware grouping, during reboot, whenever a device is removed, it
powers down itself and all its partner devices in the same group. Now this
is done by all devices and hence there is multiple power down for devices
and hence the following error messages can be seen:

ath12k_pci 0002:01:00.0: failed to set mhi state POWER_OFF(3) in current mhi state (0x0)
ath12k_pci 0002:01:00.0: failed to set mhi state: POWER_OFF(3)
ath12k_pci 0002:01:00.0: failed to set mhi state DEINIT(1) in current mhi state (0x0)
ath12k_pci 0002:01:00.0: failed to set mhi state: DEINIT(1)
ath12k_pci 0003:01:00.0: failed to set mhi state POWER_OFF(3) in current mhi state (0x0)
ath12k_pci 0003:01:00.0: failed to set mhi state: POWER_OFF(3)
ath12k_pci 0003:01:00.0: failed to set mhi state DEINIT(1) in current mhi state (0x0)
ath12k_pci 0003:01:00.0: failed to set mhi state: DEINIT(1)
ath12k_pci 0004:01:00.0: failed to set mhi state POWER_OFF(3) in current mhi state (0x0)
ath12k_pci 0004:01:00.0: failed to set mhi state: POWER_OFF(3)

To prevent this, check if the ATH12K_PCI_FLAG_INIT_DONE flag is already
set before powering down. If it is set, it indicates that another partner
device has already performed the power down, and this device can skip this
step.

Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>

5c48c18d

wifi: ath12k: add reference counting for core attachment to hardware group · f7a91c1a

Aditya Kumar Singh authored 2 weeks ago

Currently, driver does not manage reference counting for attaching and
detaching cores to/from hardware groups. This can lead to issues when
multiple cores are involved. Or with same core, attach/detach is called
multiple times back to back.

Fix this issue by using reference counting.

With that, it is now ensured that the core is properly attached or detached
from the hardware group and even back to back calls will not alter the
count.

Additionally, add some debug logs during the attachment and detachment
events for better debugging and tracking.

Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>

f7a91c1a

wifi: ath12k: fix SLUB BUG - Object already free in ath12k_reg_free() · b802fc57

Aditya Kumar Singh authored 2 weeks ago


During rmmod of ath12k module with SLUB debug enabled, following print is
seen -

=============================================================================
BUG kmalloc-1k (Not tainted): Object already free
-----------------------------------------------------------------------------

Allocated in ath12k_reg_build_regd+0x94/0xa20 [ath12k] age=10470 cpu=0 pid=0
 __kmalloc_noprof+0xf4/0x368
 ath12k_reg_build_regd+0x94/0xa20 [ath12k]
 ath12k_wmi_op_rx+0x199c/0x2c14 [ath12k]
 ath12k_htc_rx_completion_handler+0x398/0x554 [ath12k]
 ath12k_ce_per_engine_service+0x248/0x368 [ath12k]
 ath12k_pci_ce_workqueue+0x28/0x50 [ath12k]
 process_one_work+0x14c/0x28c
 bh_worker+0x22c/0x27c
 workqueue_softirq_action+0x80/0x90
 tasklet_action+0x14/0x3c
 handle_softirqs+0x108/0x240
 __do_softirq+0x14/0x20
Freed in ath12k_reg_free+0x40/0x74 [ath12k] age=136 cpu=2 pid=166
 kfree+0x148/0x248
 ath12k_reg_free+0x40/0x74 [ath12k]
 ath12k_core_hw_group_destroy+0x68/0xac [ath12k]
 ath12k_core_deinit+0xd8/0x124 [ath12k]
 ath12k_pci_remove+0x6c/0x130 [ath12k]
 pci_device_remove+0x44/0xe8
 device_remove+0x4c/0x80
 device_release_driver_internal+0x1d0/0x22c
 driver_detach+0x50/0x98
 bus_remove_driver+0x70/0xf4
 driver_unregister+0x30/0x60
 pci_unregister_driver+0x24/0x9c
 ath12k_pci_exit+0x18/0x24 [ath12k]
 __arm64_sys_delete_module+0x1a0/0x2a8
 invoke_syscall+0x48/0x110
 el0_svc_common.constprop.0+0x40/0xe0
Slab 0xfffffdffc0033600 objects=10 used=6 fp=0xffff000000cdcc00 flags=0x3fffe0000000240(workingset|head|node=0|zone=0|lastcpupid=0x1ffff)
Object 0xffff000000cdcc00 @offset=19456 fp=0xffff000000cde400
[...]

This issue arises because in ath12k_core_hw_group_destroy(), each device
calls ath12k_core_soc_destroy() for itself and all its partners within the
same group. Since ath12k_core_hw_group_destroy() is invoked for each
device, this results in a double free condition, eventually causing the
SLUB bug.

To resolve this, set the freed pointers to NULL. And since there could be
a race condition to read these pointers, guard these with the available
mutex lock.

Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.3.1-00173-QCAHKSWPL_SILICONZ-1
Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.4.1-00199-QCAHKSWPL_SILICONZ-1
Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3

Fixes: 6f245ea0 ("wifi: ath12k: introduce device group abstraction")
Signed-off-by: Aditya Kumar Singh <aditya.kumar.singh@oss.qualcomm.com>
Reviewed-by: Vasanthakumar Thiagarajan <vasanthakumar.thiagarajan@oss.qualcomm.com>
Link: https://patch.msgid.link/20250408-fix_reboot_issues_with_hw_grouping-v4-1-95e7bf048595@oss.qualcomm.com


Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>

b802fc57

wifi: ath12k: Fix buffer overflow in debugfs · 96dcca91

Dan Carpenter authored 2 weeks ago

If the user tries to write more than 32 bytes then it results in memory
corruption. Fortunately, this is debugfs so it's limited to root users.

Fixes: 3f73c24f ("wifi: ath12k: Add support to enable debugfs_htt_stats")
Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
Reviewed-by: Vasanthakumar Thiagarajan <vasanthakumar.thiagarajan@oss.qualcomm.com>
Link: https://patch.msgid.link/35daefbd-d493-41d9-b192-96177d521b40@stanley.mountain

Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>

96dcca91

wifi: ath12k: Fix a couple NULL vs IS_ERR() bugs · 5673e765

Dan Carpenter authored 2 weeks ago

The devm_memremap() function returns error pointers on error and the
ioremap() function returns NULL on error. The error checking here got
those flipped around.

Fixes: c01d5cc9 ("wifi: ath12k: Power up userPD")
Fixes: 6cee30f0 ("wifi: ath12k: add AHB driver support for IPQ5332")
Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
Reviewed-by: Vasanthakumar Thiagarajan <vasanthakumar.thiagarajan@oss.qualcomm.com>
Link: https://patch.msgid.link/937abc74-9648-4c05-a2c3-8db408b3ed9e@stanley.mountain

Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>

5673e765

wifi: ath11k: Use of_property_present() to test property presence · 1592484a

Rob Herring (Arm) authored 2 weeks ago


The use of of_property_read_u32() isn't really correct as
"memory-region" contains phandles (though those happen to be u32s. As
it is just testing for property presence, use of_property_present()
instead.

Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
Link: https://patch.msgid.link/20250408190211.2505737-2-robh@kernel.org


Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>

1592484a

wifi: ath12k: Fix WMI tag for EHT rate in peer assoc · 38645035

Ramya Gnanasekar authored 2 weeks ago

Incorrect WMI tag is used for EHT rate update from host to firmware
while encoding peer assoc WMI.

Correct the WMI tag used for EHT rate update from WMI_TAG_HE_RATE_SET
to the proper tag. This ensures firmware does not mistakenly update HE rate during parsing.

Found during code review. Compile tested only.

Fixes: 5b70ec60 ("wifi: ath12k: add WMI support for EHT peer")
Signed-off-by: Ramya Gnanasekar <ramya.gnanasekar@oss.qualcomm.com>
Link: https://patch.msgid.link/20250409152341.944628-1-ramya.gnanasekar@oss.qualcomm.com

Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>

38645035

wifi: ath12k: Disable broadcast TWT feature in HE MAC capabilities · b33cb9bc

Thomas Wu authored 2 weeks ago

Currently, the AP does not support the broadcast target wake time (TWT)
feature. Therefore, disable the broadcast TWT feature in the HE MAC
capabilities element field.

Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.3.1-00209-QCAHKSWPL_SILICONZ-1

Signed-off-by: Thomas Wu <quic_wthomas@quicinc.com>
Signed-off-by: Aaradhana Sahu <aaradhana.sahu@oss.qualcomm.com>
Reviewed-by: Vasanthakumar Thiagarajan <vasanthakumar.thiagarajan@oss.qualcomm.com>
Link: https://patch.msgid.link/20250409053830.4039467-1-aaradhana.sahu@oss.qualcomm.com

Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>

b33cb9bc

wifi: ath12k: Introduce check against zero for ahvif->key_cipher in ath12k_mac_op_tx() · f54b99f0

Aaradhana Sahu authored 3 weeks ago


Currently, ahvif->key_cipher is compared with the enum value
(WMI_CIPHER_NONE) inside ath12k_mac_op_tx(). However, ahvif->key_cipher is
set using the macro value WLAN_CIPHER_SUITE_XXXX which seems inconsistent.

To improve code consistency and readability, introduce check against zero
for ahvif->key_cipher instead of comparing it with the enum
(WMI_CIPHER_NONE).

Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.3.1-00209-QCAHKSWPL_SILICONZ-1

Signed-off-by: Aaradhana Sahu <aaradhana.sahu@oss.qualcomm.com>
Reviewed-by: Vasanthakumar Thiagarajan <vasanthakumar.thiagarajan@oss.qualcomm.com>
Link: https://patch.msgid.link/20250403082207.3323938-3-aaradhana.sahu@oss.qualcomm.com


Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>

f54b99f0

wifi: ath12k: Resolve multicast packet drop by populating key_cipher in ath12k_install_key() · e41371f3

Aaradhana Sahu authored 3 weeks ago

Currently, the key_cipher in the ath12k_vif structure, which represents the
group cipher of the MLD AP, is populated when the link address matches the
ieee80211_vif address within ath12k_install_key().

However, in MLD AP, the link address and ieee80211_vif address can differ.
Due to this key_cipher is not populated and multicast packets don't get the
correct cipher information and resulting multicast packets drop.

To fix this, compare the link address with the arvif->bssid instead of the
ieee80211_vif address.

Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.3.1-00209-QCAHKSWPL_SILICONZ-1

Fixes: 3dd2c68f ("wifi: ath12k: prepare vif data structure for MLO handling")
Signed-off-by: Aaradhana Sahu <aaradhana.sahu@oss.qualcomm.com>
Reviewed-by: Vasanthakumar Thiagarajan <vasanthakumar.thiagarajan@oss.qualcomm.com>
Link: https://patch.msgid.link/20250403082207.3323938-2-aaradhana.sahu@oss.qualcomm.com

Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>

e41371f3

wifi: ath12k: fix cleanup path after mhi init · 92848807

Raj Kumar Bhagat authored 3 weeks ago

Currently, the 'err_pci_msi_free' label is misplaced, causing the cleanup
sequence to be incorrect. Fix this by moving the 'err_pci_msi_free' label
to the correct position after 'err_irq_affinity_cleanup'.

Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.3.1-00209-QCAHKSWPL_SILICONZ-1

Fixes: a3012f20 ("wifi: ath12k: set IRQ affinity to CPU0 in case of one MSI vector")
Signed-off-by: Raj Kumar Bhagat <quic_rajkbhag@quicinc.com>
Reviewed-by: Vasanthakumar Thiagarajan <vasanthakumar.thiagarajan@oss.qualcomm.com>
Link: https://patch.msgid.link/20250403-ath12k-cleanup-v1-1-ad8f67b0e9cf@quicinc.com

Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>

92848807

wifi: ath12k: Add support for link specific datapath stats · 6b46456f

Balamurugan Mahalingam authored 2 weeks ago


Add support to record the number of frames enqueued, hardware
descriptor type, encapsulation/encryption types used, frames
dropped and completed. This is useful for understanding the
datapath performance and tune the peak throughput.

The link specific stats can be viewed through the below debugfs file

cat /sys/kernel/debug/ieee80211/phy0/netdev:wlan1/link_stats
link[0] Tx Unicast Frames Enqueued  = 9
link[0] Tx Broadcast Frames Enqueued = 78689
link[0] Tx Frames Completed = 78698
link[0] Tx Frames Dropped = 0
link[0] Tx Frame descriptor Encap Type =  raw:0 native wifi:78698 ethernet:0
link[0] Tx Frame descriptor Encrypt Type =  0:78698 1:0 2:0 3:0 4:0 5:0 6:0 7:0 8:0 9:0 10:0 11:0
link[0] Tx Frame descriptor Type = buffer:78698 extension:0
------------------------------------------------------
link[1] Tx Unicast Frames Enqueued  = 0
link[1] Tx Broadcast Frames Enqueued = 78689
link[1] Tx Frames Completed = 78689
link[1] Tx Frames Dropped = 0
link[1] Tx Frame descriptor Encap Type =  raw:0 native wifi:78689 ethernet:0
link[1] Tx Frame descriptor Encrypt Type =  0:78689 1:0 2:0 3:0 4:0 5:0 6:0 7:0 8:0 9:0 10:0 11:0
link[1] Tx Frame descriptor Type = buffer:78689 extension:0
------------------------------------------------------

Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.3.1-00173-QCAHKSWPL_SILICONZ-1
Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3

Signed-off-by: Balamurugan Mahalingam <quic_bmahalin@quicinc.com>
Link: https://patch.msgid.link/20250409155125.299380-1-quic_bmahalin@quicinc.com


Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>

6b46456f

wifi: ath12k: replace the usage of rx desc with rx_info · 42cfb8d8

P Praneesh authored 3 weeks ago

In ath12k_dp_rx_h_mpdu(), during the undecap to native wifi mode, the rx
descriptor memory is overwritten. After this function call, any subsequent
accesses to rx descriptor related memory yield invalid values. Fix this by
replacing instances where rx_desc was used with the pre-cached information
in rx_info. This ensures that the values populated from the rx descriptor
are accurate and prevents invalid memory access.

Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.4.1-00199-QCAHKSWPL_SILICONZ-1
Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3

Co-developed-by: Karthikeyan Periyasamy <karthikeyan.periyasamy@oss.qualcomm.com>
Signed-off-by: Karthikeyan Periyasamy <karthikeyan.periyasamy@oss.qualcomm.com>
Signed-off-by: P Praneesh <praneesh.p@oss.qualcomm.com>
Reviewed-by: Vasanthakumar Thiagarajan <vasanthakumar.thiagarajan@oss.qualcomm.com>
Link: https://patch.msgid.link/20250402182917.2715596-3-praneesh.p@oss.qualcomm.com

Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>

42cfb8d8

wifi: ath12k: add rx_info to capture required field from rx descriptor · c3e71075

P Praneesh authored 3 weeks ago

In ath12k_dp_rx_h_mpdu(), as part of undecap to native wifi mode, the rx
descriptor memory is getting overwritten. After this function call, all
the rx descriptor related memory accesses give invalid values. To handle
this scenario, introduce a new structure ath12k_dp_rx_info which
pre-caches all the required fields from the rx descriptor before calling
ath12k_dp_rx_h_ppdu(). This rx_info structure will be used in the next
patch.

Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.4.1-00199-QCAHKSWPL_SILICONZ-1
Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3

Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>

c3e71075

Apr 09, 2025

Add localversion-wireless-testing-ath · 1a7000fb
Jeff Johnson authored 2 weeks ago
```
Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
```
ath-202504091442

1a7000fb
Merge remote-tracking branch 'mhi/mhi-next' · 68e3c884
Jeff Johnson authored 2 weeks ago

68e3c884
Merge branch 'ath-next' · 055880ab
Jeff Johnson authored 2 weeks ago

055880ab

wifi: ath12k: ahb: Replace del_timer_sync() with timer_delete_sync() · 25b2f46b

Jeff Johnson authored 2 weeks ago

A linux-next build error was reported in [1].

This is the result of a treewide timer cleanup [2].

The ath12k AHB support has not yet landed in the tree where the
cleanup occurred, and hence a new call to del_timer_sync() was not
addressed by the treewide cleanup.

So fix that one instance.

Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Closes: https://msgid.link/20250408105146.459dfcf5@canb.auug.org.au # [1]
Link: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git/commit/?id=8fa7292fee5c5240402371ea89ab285ec856c916 # [2]
Link: https://patch.msgid.link/20250408-timer_delete_sync-v1-1-4dcb22f71083@oss.qualcomm.com

Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>

25b2f46b

Apr 08, 2025

bus: mhi: host: Address conflict between power_up and syserr · b60a0538

Jeffrey Hugo authored 4 weeks ago and

Mani Sadhasivam committed 2 weeks ago


mhi_async_power_up() enables IRQs, at which point we can receive a syserr
notification from the device.  The syserr notification queues a work item
that cannot execute until the pm_mutex is released.

If we receive a syserr notification at the right time during
mhi_async_power_up(), we will fail to initialize the device.

The syserr work item will be pending.  If mhi_async_power_up() detects the
syserr, it will handle it.  If the device is in PBL, then the PBL state
transition event will be queued, resulting in a work item after the
pending syserr work item.  Once mhi_async_power_up() releases the pm_mutex
the syserr work item can run.  It will blindly attempt to reset the MHI
state machine, which is the recovery action for syserr.  PBL/SBL are not
interrupt driven and will ignore the MHI Reset unless syserr is actively
advertised.  This will cause the syserr work item to timeout waiting for
Reset to be cleared, and will leave the host state in syserr processing.
The PBL transition work item will then run, and immediately fail because
syserr processing is not a valid state for PBL transition.

This leaves the device uninitialized.

This issue has a fairly unique signature in the kernel log:

[  909.803598] mhi mhi3: Requested to power ON
[  909.803775] Qualcomm Cloud AI 100 0000:36:00.0: Fatal error received from device.  Attempting to recover
[  909.803945] mhi mhi3: Power on setup success
[  911.808444] mhi mhi3: Device failed to exit MHI Reset state
[  911.808448] mhi mhi3: Device MHI is not in valid state

We cannot remove the syserr handling from mhi_async_power_up() because the
device may be in the syserr state, but we missed the notification as the
irq was fired before irqs were enabled.  We also can't queue the syserr
work item from mhi_async_power_up() if syserr is detected because that may
result in a duplicate work item, and cause the same issue since the
duplicate item will blindly issue MHI Reset even if syserr is no longer
active.

Instead, add a check in the syserr work item to make sure that the device
is in the syserr state if the device is in the PBL or SBL EEs.

It is unknown when this issue was introduced. It was first observed with
commit bce3f770 ("bus: mhi: host: Add MHI_PM_SYS_ERR_FAIL state") but
that commit does not appear to introduce the issue per code inspection.
This issue is suspected to trace back to the introduction of MHI, but the
relevant code paths have drastically changed since then. Therefore, do
not identify a specific commit in a Fixes tag as confidence is low that
such a commit would be correctly identified.

Signed-off-by: Jeffrey Hugo <quic_jhugo@quicinc.com>
Signed-off-by: Jeff Hugo <jeff.hugo@oss.qualcomm.com>
Reviewed-by: Troy Hanson <quic_thanson@quicinc.com>
Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Message-ID: <20250328163526.3365497-1-jeff.hugo@oss.qualcomm.com>
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>

b60a0538

Apr 07, 2025

wifi: ath12k: Fix misspelling "upto" in dp.c · 68218fa0

Jeff Johnson authored 2 weeks ago

ath12k-check is flagging:

drivers/net/wireless/ath/ath12k/dp.c:1656: 'upto' may be misspelled - perhaps 'up to'?

Replace "upto" with "up to" and split the comment line so that it
doesn't exceed 80 columns.

Link: https://patch.msgid.link/20250407-upto-v1-1-23ca65f2ccdf@oss.qualcomm.com


Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>

68218fa0

wifi: ath12k: Fix invalid memory access while forming 802.11 header · be908d23

P Praneesh authored 3 weeks ago

While forming the 802.11 header from the rx descriptor, skb_push() is
performed for the 802.11 header length and then calls
ath12k_dp_rx_desc_get_dot11_hdr(). Since skb_push() moves the skb->data
pointer backwards by the 802.11 header length, the rx descriptor points to
a different memory area than intended, causing invalid information to be
fetched from the rx descriptor.

Also, when IV and ICV are not stripped from the given MSDU, mac80211
performs PN validation for these MSDUs, which requires the crypto header.
Before forming the crypto header from the given rx descriptor, skb_push()
is performed for the crypto header length, which overwrites the memory
pointed to by the rx descriptor, causing invalid information to form the
802.11 header.

Fix these issues by moving all rx descriptor accesses before the skb_push()
operation which ensures the proper 802.11 headers are generated from the
given rx descriptor and removing ath12k_dp_rxdesc_get_mpdu_frame_ctrl()
for filling frame control, as this information is already fetched by
ath12k_dp_rx_desc_get_dot11_hdr().

Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.4.1-00199-QCAHKSWPL_SILICONZ-1
Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3

Fixes: d8899132 ("wifi: ath12k: driver for Qualcomm Wi-Fi 7 devices")
Co-developed-by: Karthikeyan Periyasamy <karthikeyan.periyasamy@oss.qualcomm.com>
Signed-off-by: Karthikeyan Periyasamy <karthikeyan.periyasamy@oss.qualcomm.com>
Signed-off-by: P Praneesh <praneesh.p@oss.qualcomm.com>
Link: https://patch.msgid.link/20250402180543.2670947-1-praneesh.p@oss.qualcomm.com

Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>

be908d23

wifi: ath12k: Fix memory corruption during MLO multicast tx · 6f8a27a5

P Praneesh authored 3 weeks ago

The struct sk_buff's control buffer is shared by mac80211's struct
ieee80211_tx_info and ath12k's struct ath12k_skb_cb. When the driver wants
to transmit an skb, it caches all the mac80211-specific information from
struct ieee80211_tx_info, then performs a memset on the control buffer
before writing the ath12k-specific information using struct ath12k_skb_cb.
However, during multicast tx, the key is being filled into the driver data,
which overwrites some crucial members like link_id and flags in struct
ath12k_skb_cb. This causes invalid information retrieval when the driver
accesses these fields during ath12k_dp_tx(). Fix this issue by removing
the key filling logic during MLO multicast tx, as it is not used anywhere
in the tx path.

Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.4.1-00199-QCAHKSWPL_SILICONZ-1
Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3

Fixes: 2f50de72 ("wifi: ath12k: Add support for MLO Multicast handling in driver")
Signed-off-by: P Praneesh <praneesh.p@oss.qualcomm.com>
Link: https://patch.msgid.link/20250402175714.2667270-1-praneesh.p@oss.qualcomm.com

Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>

6f8a27a5

wifi: ath12k: Fix memory leak during vdev_id mismatch · 75ec94db

P Praneesh authored 3 weeks ago

Currently driver enables vdev_id check as part of the bank configuration
in ath12k_dp_tx_get_vdev_bank_config(). This check ensures that the vdev_id
configured in the bank register aligns with the vdev_id in the packet's
address search table within the firmware. If there is a mismatch, the
firmware forwards the packet with the HTT status
HAL_WBM_REL_HTT_TX_COMP_STATUS_VDEVID_MISMATCH. Since driver does not
handle this vdev_id mismatch HTT status, the corresponding buffers are not
freed properly, causing a memory leak. Fix this issue by adding handling to
free the buffers when a vdev_id mismatch HTT status is encountered.

Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.4.1-00199-QCAHKSWPL_SILICONZ-1
Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-

Fixes: d8899132 ("wifi: ath12k: driver for Qualcomm Wi-Fi 7 devices")
Signed-off-by: P Praneesh <praneesh.p@oss.qualcomm.com>
Link: https://patch.msgid.link/20250402174032.2651221-1-praneesh.p@oss.qualcomm.com

Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>

75ec94db

wifi: ath12k: Fix incorrect rates sent to firmware · cb179024

Pradeep Kumar Chitrapu authored 1 month ago

Before firmware assert, if there is a station interface in the device
which is not associated with an AP, the basic rates are set to zero.
Following this, during firmware recovery, when basic rates are zero,
ath12k driver is sending invalid rate codes, which are negative values,
to firmware. This results in firmware assert.

Fix this by checking if rate codes are valid, before sending them
to the firmware.

Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.4.1-00199-QCAHKSWPL_SILICONZ-1

Signed-off-by: Pradeep Kumar Chitrapu <quic_pradeepc@quicinc.com>
Signed-off-by: Roopni Devanathan <quic_rdevanat@quicinc.com>
Reviewed-by: Vasanthakumar Thiagarajan <vasanthakumar.thiagarajan@oss.qualcomm.com>
Reviewed-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20250320112426.1956961-1-quic_rdevanat@quicinc.com

Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>

cb179024