Age | Commit message (Collapse) | Author |
|
False positive reset would be possibly triggered by those commands we
applied in suspend with HZ MCU timeout, especially it happened when we
enabled kernel log in pm core to diagnose how much time we spend in each
driver during suspend procedure. So we enlarge the value and align the MCU
timeout as other commands we did to reduce the false positive reset.
Signed-off-by: Sean Wang <sean.wang@mediatek.com>
Acked-by: Lorenzo Bianconi <lorenzo@kernel.org>
Signed-off-by: Felix Fietkau <nbd@nbd.name>
|
|
Correct spelling on 'transmitted' in comment
Signed-off-by: Ruffalo Lavoisier <RuffaloLavoisier@gmail.com>
Signed-off-by: Felix Fietkau <nbd@nbd.name>
|
|
Given that there's no data coming from network stack for binding flows,
hence driver counts and reports station's statistics directly through
NL80211_STA_INFO_* based on active PPDU based TxS for offloading data.
Apart from that, WA firmware and its offloading engine (SDO) have hardcoded
"2" as PID, so we introduce MT_PACKET_ID_WED to differentiate WED reporting.
Note that PPDU format TxS is mutually exclusive with MT_TXD5_TX_STATUS_HOST.
Co-developed-by: Yi-Chia Hsieh <yi-chia.hsieh@mediatek.com>
Signed-off-by: Yi-Chia Hsieh <yi-chia.hsieh@mediatek.com>
Signed-off-by: Ryder Lee <ryder.lee@mediatek.com>
Signed-off-by: Felix Fietkau <nbd@nbd.name>
|
|
This is a preliminary patch for WED's TxS support.
Signed-off-by: Ryder Lee <ryder.lee@mediatek.com>
Signed-off-by: Felix Fietkau <nbd@nbd.name>
|
|
Fix the regression of the firmware version report since
'b9ec27102ac0 ('mt76: connac: move mt76_connac2_load_ram in connac
module')'.
Fixes: b9ec27102ac0 ("mt76: connac: move mt76_connac2_load_ram in connac module")
Signed-off-by: Sean Wang <sean.wang@mediatek.com>
Signed-off-by: Felix Fietkau <nbd@nbd.name>
|
|
Add mt7921_mutex_acquire at mt7921_[start, stop]_ap to fix the race
with the context holding dev->muxtex and the driver might access the
device in low power state.
Fixes: 24299fc869f7 ("mt76: mt7921: enable rx header traslation offload")
Tested-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Acked-by: Lorenzo Bianconi <lorenzo@kernel.org>
Signed-off-by: Sean Wang <sean.wang@mediatek.com>
Signed-off-by: Felix Fietkau <nbd@nbd.name>
|
|
Add mt7921_mutex_acquire at mt7921_[start, stop]_ap to fix the race
with the context holding dev->muxtex and the driver might access the
device in low power state.
Fixes: 9d958b60ebc2 ("mt76: mt7921: fix command timeout in AP stop period")
Tested-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Signed-off-by: Sean Wang <sean.wang@mediatek.com>
Acked-by: Lorenzo Bianconi <lorenzo@kernel.org>
Signed-off-by: Felix Fietkau <nbd@nbd.name>
|
|
Simplify mt76x02u_multiple_mcu_reads routine since burst is always
false.
Signed-off-by: Gergo Koteles <soyer@irl.hu>
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
Signed-off-by: Felix Fietkau <nbd@nbd.name>
|
|
Introduce rx_check callback support for mt7663s driver.
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
Signed-off-by: Felix Fietkau <nbd@nbd.name>
|
|
mt76_connac_mcu_add_nested_tlv
Fix possible unaligned pointer in mt76_connac_mcu_add_nested_tlv
routine.
Reported-by: kernel test robot <lkp@intel.com>
Fixes: 25702d9c55dc5 ("mt76: connac: rely on le16_add_cpu in mt76_connac_mcu_add_nested_tlv")
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
Signed-off-by: Felix Fietkau <nbd@nbd.name>
|
|
Fix possible unaligned pointer in mt7915_mac_add_twt_setup routine.
Reported-by: kernel test robot <lkp@intel.com>
Fixes: 3782b69d03e71 ("mt76: mt7915: introduce mt7915_mac_add_twt_setup routine")
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
Signed-off-by: Felix Fietkau <nbd@nbd.name>
|
|
mt7615_sta_set_decap_offload
Similar to mt7921 driver, introduce mt7615_mutex_acquire/release in
mt7615_sta_set_decap_offload in order to avoid sending mcu commands
while the device is in low-power state.
Fixes: d4b98c63d7a77 ("mt76: mt7615: add support for rx decapsulation offload")
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
Signed-off-by: Felix Fietkau <nbd@nbd.name>
|
|
Fix transmitting packets hangs with continuing to pull the pending packet
from mac80211 queues when receiving Tx status notification from the device.
Fixes: aac5104bf631 ("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>
|
|
Introduce rx_check callback support for mt7921s driver.
Tested-by: Sean Wang <sean.wang@mediatek.com>
Co-developed-by: Sean Wang <sean.wang@mediatek.com>
Signed-off-by: Sean Wang <sean.wang@mediatek.com>
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
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 454b768f9ba6 ("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: f965333e491e ("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: 0880d40871d1 ("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: d39b52e31aa6 ("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: d39b52e31aa6 ("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: df3e4143ba8a ("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: ca74b9b907f9 ("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: 0c1ce9884607 ("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>
|
|
It looks like a leftover from copying rtl8xxxu_update_rate_mask,
which is used with the gen1 chips.
It wasn't causing any problems for my RTL8188FU test device, but it's
clearly a mistake, so remove it.
Fixes: f653e69009c6 ("rtl8xxxu: Implement basic 8723b specific update_rate_mask() function")
Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/d5544fe8-9798-28f1-54bd-6839a1974b10@gmail.com
|
|
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: e1547c535ede ("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 size limit of H2C commands is 2048. With regulatory that enables
U-NII-6 ~ UNII-8 channels, channel list length combining with channel info
length will exceed that. Split the channel list to parts and do scan
multiple times to workaround that.
Signed-off-by: Po-Hao Huang <phhuang@realtek.com>
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-10-pkshih@realtek.com
|
|
This enables hw_scan function for 52c. The mechanism is similar to 52a
except that it adds modifications required for 6G channels and extends the
command length to make driver compatible to both newer and existing
firmware.
Signed-off-by: Po-Hao Huang <phhuang@realtek.com>
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-9-pkshih@realtek.com
|
|
8852c transmits packets with slow response in deep ps mode,
and lead to low throughput. We need to call tx_wake for
each pakcet to trigger firmware wake earlier to avoid it.
Signed-off-by: Chin-Yen Lee <timlee@realtek.com>
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-8-pkshih@realtek.com
|
|
rtw8852c could support deep ps mode if the firmware version
is greater than 0.17.34.
Signed-off-by: Chin-Yen Lee <timlee@realtek.com>
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-7-pkshih@realtek.com
|
|
With suitable response rate, it can acknowledge peer packets are received.
Otherwise, peer could re-transmit again due to missing of ACK frames.
To achieve this, refer to RX rate and CMAC table to choose the smaller
as initial response rate.
Signed-off-by: Chia-Yuan Li <leo.li@realtek.com>
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-6-pkshih@realtek.com
|
|
With one path TX for 1SS rate, it can transmit higher power in 6GHz band
to yield better performance in high attenuation circumstance.
Signed-off-by: Yi-Tang Chiu <chiuyitang@realtek.com>
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-5-pkshih@realtek.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
|
|
Enable MU-MIMO interference cancellation (MUIC) to yield expected
performance of receiving MU-MIMO packets on 6GHz.
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-3-pkshih@realtek.com
|
|
Since control register address for DIG are different per IC, add a new
struct rtw89_dig_regs in chip info for each IC to define their own address.
Signed-off-by: Eric Huang <echuang@realtek.com>
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-2-pkshih@realtek.com
|
|
Check RSSI strength to decide which path is better, and then set TX path
accordingly.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20220908074140.39776-6-pkshih@realtek.com
|
|
Originally, we show average signal strength. To support TX diversity, this
patch prepares strength per path, then we can decide TX path.
RSSI: -54 dBm (raw=112, prev=110) [-57, -52]
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20220908074140.39776-5-pkshih@realtek.com
|
|
In order to support TX diversity, add a function to control TX path.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20220908074140.39776-4-pkshih@realtek.com
|
|
Two fields, TX/RX ANT NUM, are introduced to address variant TX/RX antenna
number of hardware. For example, a 1x1 chip with TX diversity, TX NSS = 1
and TX/RX ANT NUM = 2.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20220908074140.39776-3-pkshih@realtek.com
|
|
The definitions of bit fields in structure will be wrong in big-endian
platform, so use u32_get_bits() to access them.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20220908074140.39776-2-pkshih@realtek.com
|
|
There's a TODO here, just move the dependency on phy->rev
into the comment. Not that this driver is likely to get
any updates.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20220904212910.ea00a892e41b.I709217fc307125f8670c7f6a9093111b46194131@changeid
|
|
Instead of the code here that copies into a variable
first and then flips endianness, which confuses sparse,
just directly use get_unaligned_le64().
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20220904212910.a5c9ea122f0f.If786a66f8fd9d45659cd5a2532cf395e21334453@changeid
|
|
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
|
|
These cause sparse warnings, and since the device generally
works in little endian we can assume the code is correct, so
just fix the casts accordingly. No binary changes on x86.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Reviewed-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20220904212910.3f72609a3825.If4048592701bf04981be1dab18eaaa339b2ea382@changeid
|
|
Clearly the value should be converted and then compared,
not the result of the comparison be converted. No binary
changes on x86.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Reviewed-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20220904212910.a32e45adb2b2.I8c966b07c0bf7be4485967b044d9dad3f4772a27@changeid
|
|
We need to read a value from the device to wake it, but if it
succeeds we don't really care about it. Mark the variable to
avoid a compiler warning.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20220904212910.5d67f55178a1.If0789ab326935896e5886fa06dbb9ef0da6c0b41@changeid
|
|
This caused sparse warnings, and clearly is needed per
how other firmware interfaces behave.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20220904212910.2b5cb713cf4b.Ibabba2deb7bb22863d3a134e7a3333422d7eff17@changeid
|