- 15 Sep, 2022 13 commits
-
-
Dan Carpenter authored
This if statement is never true. It was supposed to have been deleted as part of commit 454b768f ("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>
-
Dan Carpenter authored
Don't dereference "sar_root" after it has been freed. Fixes: f965333e ("mt76: mt7921: introduce ACPI SAR support") Signed-off-by:
-
Dan Carpenter authored
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: 0880d408 ("mt76: connac: move mt76_connac2_reverse_frag0_hdr_trans in mt76-connac module") Signed-off-by: -
Sean Wang authored
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: d39b52e3 ("mt76: introduce mt76_sdio module") Signed-off-by:
Sean Wang <sean.wang@mediatek.com> Signed-off-by:
-
Sean Wang authored
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: d39b52e3 ("mt76: introduce mt76_sdio module") Co-developed-by:
YN Chen <YN.Chen@mediatek.com> Signed-off-by:
-
Lorenzo Bianconi authored
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:
-
Sean Wang authored
remove unnecessary MT76_STATE_SUSPEND manipulation to be consistent with the mt7921[e, s] driver. Acked-by:
-
Sean Wang authored
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: df3e4143 ("mt76: mt7921u: add suspend/resume support") Co-developed-by:
-
Sean Wang authored
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: ca74b9b9 ("mt76: mt7921s: add reset support") Co-developed-by:
-
Sean Wang authored
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: 0c1ce988 ("mt76: mt7921: add wifi reset support") Co-developed-by:
-
Lorenzo Bianconi authored
Introduce rx_check callback support for mt7663u and mt7921u drivers. Signed-off-by:
-
Shayne Chen authored
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:
-
Lorenzo Bianconi authored
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:
-
- 12 Sep, 2022 16 commits
-
-
Bitterblue Smith authored
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: f653e690 ("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
-
Bitterblue Smith authored
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: e1547c53 ("rtl8xxxu: First stab at adding IQK calibration for 8723bu parts") Signed-off-by:
-
Po-Hao Huang authored
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:
-
Po-Hao Huang authored
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:
-
Chin-Yen Lee authored
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:
-
Chin-Yen Lee authored
rtw8852c could support deep ps mode if the firmware version is greater than 0.17.34. Signed-off-by:
-
Chia-Yuan Li authored
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:
-
Yi-Tang Chiu authored
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 authored
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 authored
Enable MU-MIMO interference cancellation (MUIC) to yield expected performance of receiving MU-MIMO packets on 6GHz. Signed-off-by:
-
Eric Huang authored
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 authored
Check RSSI strength to decide which path is better, and then set TX path accordingly. Signed-off-by:
-
Ping-Ke Shih authored
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 authored
In order to support TX diversity, add a function to control TX path. Signed-off-by:
-
Ping-Ke Shih authored
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 authored
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:
-
- 07 Sep, 2022 11 commits
-
-
Johannes Berg authored
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:
-
Johannes Berg authored
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 authored
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 authored
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:
Brian Norris <briannorris@chromium.org> Signed-off-by:
-
Johannes Berg authored
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 authored
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 authored
This caused sparse warnings, and clearly is needed per how other firmware interfaces behave. Signed-off-by:
-
Johannes Berg authored
- endian swapping is required in one place, use the already swapped 'bsssize' local - lbs_disablemesh need not be exported and can be static Signed-off-by:
-
Johannes Berg authored
Just remove the extra asterisk to make it not be kernel-doc formatted. Signed-off-by:
-
Bitterblue Smith authored
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: 26f1fad2 ("New driver: rtl8xxxu (mac80211)") Signed-off-by:
-
Jinpeng Cui authored
Return value from brcmf_fil_iovar_data_set() and brcmf_config_ap_mgmt_ie() directly instead of taking this in another redundant variable. Reported-by:
Zeal Robot <zealci@zte.com.cn> Signed-off-by:
Jinpeng Cui <cui.jinpeng2@zte.com.cn> Signed-off-by:
-
