Fix transmitting packets hangs with continuing to pull the pending packet
from mac80211 queues when receiving Tx status notification from the device.
Fixes: aac5104bf6 ("mt76: sdio: do not run mt76_txq_schedule directly")
Acked-by: Sean Wang <sean.wang@mediatek.com>
Signed-off-by: YN Chen <yn.chen@mediatek.com>
Signed-off-by: Felix Fietkau <nbd@nbd.name>
This if statement is never true. It was supposed to have been deleted
as part of commit 454b768f9b ("mt76: mt7921: Let PCI core handle
power state and use pm_sleep_ptr()") but was missed.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Don't dereference "sar_root" after it has been freed.
Fixes: f965333e49 ("mt76: mt7921: introduce ACPI SAR support")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Smatch complains that:
drivers/net/wireless/mediatek/mt76/mt7915/mac.c:428 mt7915_mac_fill_rx()
error: uninitialized symbol 'msta'.
It looks like this was supposed to be initialized to NULL.
Fixes: 0880d40871 ("mt76: connac: move mt76_connac2_reverse_frag0_hdr_trans in mt76-connac module")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Felix Fietkau <nbd@nbd.name>
It is not meaningful to poll sta stat when there is no data traffic.
So polling sta stat when the device has transmitted data instead to save
CPU power.
That implies that it is unallowed the stat_work to work while MCU is being
initialized in the really early stage to fix the possible time to time MCU
initialization failure.
Fixes: d39b52e31a ("mt76: introduce mt76_sdio module")
Signed-off-by: Sean Wang <sean.wang@mediatek.com>
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Because wake_work and sdio->stat_work share the same workqueue mt76->wq,
if sdio->stat_work cannot acquire the mutex lock such as that was possibly
held up by [mt7615, mt7921]_mutex_acquire. Additionally, if
[mt7615, mt7921]_mutex_acquire was called by sdio->stat_work self, the wake
would be blocked by itself. Thus, we move the stat_work into
ieee80211_workqueue instead to break the deadlock.
Fixes: d39b52e31a ("mt76: introduce mt76_sdio module")
Co-developed-by: YN Chen <YN.Chen@mediatek.com>
Signed-off-by: YN Chen <YN.Chen@mediatek.com>
Signed-off-by: Sean Wang <sean.wang@mediatek.com>
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Since both mt7921_rx_check and mt7921_queue_rx_skb routines are used by
all chipsets (mmio, usb and sdio), move them in mac.c and remove
duplicated code.
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
Signed-off-by: Felix Fietkau <nbd@nbd.name>
remove unnecessary MT76_STATE_SUSPEND manipulation to be consistent
with the mt7921[e, s] driver.
Acked-by: Lorenzo Bianconi <lorenzo@kernel.org>
Signed-off-by: Sean Wang <sean.wang@mediatek.com>
Signed-off-by: Felix Fietkau <nbd@nbd.name>
It is unexpected that the reset work is running simultaneously with
the suspend or resume context and it is possible that reset work is still
running even after mt7921 is suspended if we don't fix the race issue.
Thus, the suspend procedure should be waiting until the reset is completed
at the beginning and ignore the subsequent the reset requests.
In case there is an error that happens during either suspend or resume
handler, we will schedule a reset task to recover the error before
returning the error code to ensure we can immediately fix the error there.
Fixes: df3e4143ba ("mt76: mt7921u: add suspend/resume support")
Co-developed-by: YN Chen <YN.Chen@mediatek.com>
Signed-off-by: YN Chen <YN.Chen@mediatek.com>
Signed-off-by: Sean Wang <sean.wang@mediatek.com>
Signed-off-by: Felix Fietkau <nbd@nbd.name>
It is unexpected that the reset work is running simultaneously with
the suspend or resume context and it is possible that reset work is still
running even after mt7921 is suspended if we don't fix the race issue.
Thus, the suspend procedure should be waiting until the reset is completed
at the beginning and ignore the subsequent the reset requests.
In case there is an error that happens during either suspend or resume
handler, we will schedule a reset task to recover the error before
returning the error code to ensure we can immediately fix the error there.
Fixes: ca74b9b907 ("mt76: mt7921s: add reset support")
Co-developed-by: YN Chen <YN.Chen@mediatek.com>
Signed-off-by: YN Chen <YN.Chen@mediatek.com>
Signed-off-by: Sean Wang <sean.wang@mediatek.com>
Signed-off-by: Felix Fietkau <nbd@nbd.name>
It is unexpected that the reset work is running simultaneously with
the suspend or resume context and it is possible that reset work is still
running even after mt7921 is suspended if we don't fix the race issue.
Thus, the suspend procedure should be waiting until the reset is completed
at the beginning and ignore the subsequent the reset requests.
In case there is an error that happens during either suspend or resume
handler, we will schedule a reset task to recover the error before
returning the error code to ensure we can immediately fix the error there.
Fixes: 0c1ce98846 ("mt76: mt7921: add wifi reset support")
Co-developed-by: YN Chen <YN.Chen@mediatek.com>
Signed-off-by: YN Chen <YN.Chen@mediatek.com>
Signed-off-by: Sean Wang <sean.wang@mediatek.com>
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Introduce rx_check callback support for mt7663u and mt7921u drivers.
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Compared to fixed payload packets, random payload packets have better
measured EVM under the same txpower. Our tests show EVM becomes at least
2-3 dB better in test cases with high rate and long tx length, which also
aligns the testing results to proprietary driver.
Suggested-by: Jm Chen <jm.chen@mediatek.com>
Signed-off-by: Shayne Chen <shayne.chen@mediatek.com>
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Introduce mt76_connac_reg_map structure in mt76-connac module since it
is used by all connac2 chipset. Align structure definitions.
This is a preliminary patch to add mt7990 chipset support.
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Found by comparing with the vendor driver. Currently this affects
only the RTL8192EU, which is the only gen2 chip with 2 TX paths
supported by this driver. It's unclear what kind of effect the
mistake had in practice, since I don't have any RTL8192EU devices
to test it.
Fixes: e1547c535e ("rtl8xxxu: First stab at adding IQK calibration for 8723bu parts")
Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/30a59f3a-cfa9-8379-7af0-78a8f4c77cfd@gmail.com
The range of calibration time of RX DCK is quite wide from ~40us to
~1300us by experiments, and probability is about 0.1% for the cases larger
than 1000us. Though it can retry calibration and get positive result, it
will spend more time. Therefore, enlarge it to avoid warning and duplicate
calibration.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20220908051257.25353-4-pkshih@realtek.com
Currently in the case of WCN6750, only one TCL ring is used for TX,
this is limiting the TX throughput in 160 MHz case, enabling multiple
TCL rings on WCN6750 has shown an improvement of nearly 300 Mbps in
the case of TCP TX, therefore add the support of multi TX ring for
WCN6750.
Currently TCL ring is selected based on CPU ID, this logic cannot be
applied for WCN6750 as there is chance of out of order TX of packets
and to avoid this, choose TCL ring based on flow hash so that packets
of the same flow will end up on same TCL ring. For the same reason,
TCL ring retry logic is also not applicable for WCN6750.
Also the mapping of TCL, WBM & RBM IDs for WCN6750 is different from
existing devices. Create a new TCM/WBM/RBM mapping for WCN6750.
Change does not impact existing ath11k devices.
Tested-on: WCN6750 hw1.0 AHB WLAN.MSL.1.0.1-00887-QCAMSLSWPLZ-1
Signed-off-by: Manikanta Pubbisetty <quic_mpubbise@quicinc.com>
Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com>
Link: https://lore.kernel.org/r/20220905071805.31625-3-quic_mpubbise@quicinc.com
Enable threaded NAPI on all ath11k targets. Unlike traditional
NAPI poll which runs in softirq context and on the core which
scheduled the NAPI, threaded NAPI makes use of kernel threads
which are under direct control of the scheduler and helps in
balancing the NAPI processing load across multiple CPUs thereby
improving throughput.
In the case of WCN6750, enabling threaded NAPI has improved
160 MHz RX throughput by nearly 400 Mbps. Similar gains can
be expected on other ath11k devices as well.
Tested-on: WCN6750 hw1.0 AHB WLAN.MSL.1.0.1-00887-QCAMSLSWPLZ-1
Signed-off-by: Manikanta Pubbisetty <quic_mpubbise@quicinc.com>
Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com>
Link: https://lore.kernel.org/r/20220905071805.31625-2-quic_mpubbise@quicinc.com
mhi_alloc_controller() allocates a memory space for mhi_ctrl. When gets
some error, mhi_ctrl should be freed with mhi_free_controller(). But
when ath11k_mhi_read_addr_from_dt() fails, the function returns without
calling mhi_free_controller(), which will lead to a memory leak.
We can fix it by calling mhi_free_controller() when
ath11k_mhi_read_addr_from_dt() fails.
Signed-off-by: Jianglei Nie <niejianglei2021@163.com>
Reviewed-by: Jeff Johnson <quic_jjohnson@quicinc.com>
Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com>
Link: https://lore.kernel.org/r/20220907073704.58806-1-niejianglei2021@163.com
On-board SRAM contains valuable information for firmware debugging so
add a new file named "sram" to debugfs with which we can dump SRAM
content using following the following:
cp /sys/kernel/debug/ath11k/wcn6855\ hw2.0/sram /tmp/sram
Currently this feature is enabled for QCA6390 and WCN6855.
Tested-on: QCA6390 hw2.0 PCI WLAN.HST.1.0.1-01740-QCAHSTSWPLZ_V2_TO_X86-1
Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-01720.1-QCAHSPSWPL_V1_V2_SILICONZ_LITE-1
Signed-off-by: Baochen Qiang <quic_bqiang@quicinc.com>
Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com>
Link: https://lore.kernel.org/r/20220802075533.1744-3-quic_bqiang@quicinc.com
ath11k_pcic_write32/read32 tries to do wake up before doing actual
write/read work, which means each time a u32 is written/read, wake
up is performed. This is not necessary in case where we do a
large amount of write/read, because only one time of wake up is needed.
So split each one into two parts, the first part does wake up and
release, and the second one does actual write/read work.
Tested-on: QCA6390 hw2.0 PCI WLAN.HST.1.0.1-01740-QCAHSTSWPLZ_V2_TO_X86-1
Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-01720.1-QCAHSPSWPL_V1_V2_SILICONZ_LITE-1
Signed-off-by: Baochen Qiang <quic_bqiang@quicinc.com>
Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com>
Link: https://lore.kernel.org/r/20220802075533.1744-2-quic_bqiang@quicinc.com
We can call this in one of two ways: through mac80211, where
we're already in an RCU read-side critical section, or from
some other code in the driver where this pointer can only be
NULL. In any case, we get a 'free' already protected pointer
to the sta through info->control.sta, so we can use it on
the stack without any further protection.
Remove the rcu_dereference() and critical section.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20220904212910.e5bc20dd17bf.Ib570ff7fde33c2b6eddef493a3541fa04eb47181@changeid
rtl8xxxu_queue_select() selects the wrong TX queues because it's
reading memory from the wrong address. It expects to find ieee80211_hdr
at skb->data, but that's not the case after skb_push(). Move the call
to rtl8xxxu_queue_select() before the call to skb_push().
Fixes: 26f1fad29a ("New driver: rtl8xxxu (mac80211)")
Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/7fa4819a-4f20-b2af-b7a6-8ee01ac49295@gmail.com
