Kalle Valo [Thu, 10 Feb 2022 14:36:03 +0000 (16:36 +0200)]
Merge tag 'mt76-for-kvalo-2022-02-04' of https://github.com/nbd168/wireless into main
mt76 patches for 5.18
- mt7915 mcu code cleanup
- mt7916 support
- fixes for SDIO support
- fixes for DFS
- power management fixes
- stability improvements
- background radar detection support
brcmfmac: p2p: Replace one-element arrays with flexible-array members
There is a regular need in the kernel to provide a way to declare having
a dynamically sized set of trailing elements in a structure. Kernel code
should always use “flexible array members”[1] for these cases. The older
style of one-element or zero-length arrays should no longer be used[2].
This helps with the ongoing efforts to globally enable -Warray-bounds
and get us closer to being able to tighten the FORTIFY_SOURCE routines
on memcpy().
This issue was found with the help of Coccinelle and audited and fixed,
manually.
Ping-Ke Shih [Tue, 8 Feb 2022 08:27:51 +0000 (16:27 +0800)]
rtw89: coex: set EN bit to PLT register
B_AX_PLT_EN is to enable polluted mechanism. If it is enabled and
gnt_bt = 1 while wlan TX, B_AX_BT_PLT_PKT_CNT counter will increase,
but TX counter to BB will not. Without this bit BTCoex mechanism might
have some problems.
Chien-Hsun Liao [Tue, 8 Feb 2022 08:24:27 +0000 (16:24 +0800)]
rtw89: recover rates of rate adaptive mechanism
Some APs like CMW270 only support one phyrate and the function
rtw89_phy_ra_mask_rssi could disable that rate. To fix such problem, we
restore the rate mask if we find that the rate_mask is empty.
Also, apply missed legacy rates from sta->supp_rates[].
Signed-off-by: Chien-Hsun Liao <ben.liao@realtek.com> Signed-off-by: Kuan-Chung Chen <damon.chen@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/20220208082427.42433-3-pkshih@realtek.com
Chien-Hsun Liao [Tue, 8 Feb 2022 08:24:26 +0000 (16:24 +0800)]
rtw88: recover rates of rate adaptive mechanism
Some APs like CMW270 only support one phyrate and the function
rtw_update_rate_mask could disable that rate. To fix such problem, we
restore the rate mask if we find that the rate_mask is empty.
Signed-off-by: Chien-Hsun Liao <ben.liao@realtek.com> Signed-off-by: Kuan-Chung Chen <damon.chen@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/20220208082427.42433-2-pkshih@realtek.com
Ping-Ke Shih [Mon, 7 Feb 2022 06:38:57 +0000 (14:38 +0800)]
rtw89: maintain assoc/disassoc STA states of firmware and hardware
In AP mode, when a STA associate to us, we need to create an entry in
firmware and hardware, and then they can transmit data properly.
The entry index called mac_id which is assigned when sta_add, and we ask
firmware to create an entry for an associated station. Also, the address
CAM should be filled so hardware can know which packet is ours, and lookup
the mac_id for further use.
Ping-Ke Shih [Mon, 7 Feb 2022 06:38:56 +0000 (14:38 +0800)]
rtw89: only STA mode change vif_type mapping dynamically
vif_type mapping indicates hardware operating mode corresponding to vif
type. In STA mode, hardware mode should be INFRA or NO_LINK mode
dynamically according to association status. Since AP mode don't need to
change this by association status intuitively, just do the mapping in
STA mode.
Dan Carpenter [Thu, 3 Feb 2022 08:25:32 +0000 (11:25 +0300)]
rtw88: fix use after free in rtw_hw_scan_update_probe_req()
This code needs to use skb_queue_walk_safe() instead of skb_queue_walk()
because it frees the list iterator.
Fixes: d95984b5580d ("rtw88: fix memory overrun and memory leak during hw_scan") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Acked-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20220203082532.GA25151@kili
Avraham Stern [Wed, 2 Feb 2022 08:49:47 +0000 (10:49 +0200)]
mac80211: fix struct ieee80211_tx_info size
The size of the status_driver_data field was not adjusted when
the is_valid_ack_signal field was added.
Since the size of struct ieee80211_tx_info is limited, replace
the is_valid_ack_signal field with a flags field, and adjust the
struct size accordingly.
mac80211: vht: use HE macros for parsing HE capabilities
IEEE80211_VHT_MCS_NOT_SUPPORTED and IEEE80211_HE_MCS_NOT_SUPPORTED
have the same value so no real bug, but for code integrity use the
HE macros for parsing HE capabilities.
Avraham Stern [Wed, 2 Feb 2022 08:49:37 +0000 (10:49 +0200)]
cfg80211: don't add non transmitted BSS to 6GHz scanned channels
When adding 6GHz channels to scan request based on reported
co-located APs, don't add channels that have only APs with
"non-transmitted" BSSes if they only match the wildcard SSID since
they will be found by probing the "transmitted" BSS.
Johannes Berg [Wed, 2 Feb 2022 08:49:36 +0000 (10:49 +0200)]
cfg80211/mac80211: assume CHECKSUM_COMPLETE includes SNAP
There's currently only one driver that reports CHECKSUM_COMPLETE,
that is iwlwifi. The current hardware there calculates checksum
after the SNAP header, but only RFC 1042 (and some other cases,
but replicating the exact hardware logic for corner cases in the
driver seemed awkward.)
Newer generations of hardware will checksum _including_ the SNAP,
which makes things easier.
To handle that, simply always assume the checksum _includes_ the
SNAP header, which this patch does, requiring to first add it
for older iwlwifi hardware, and then remove it again later on
conversion.
Alternatively, we could have:
1) Always assumed the checksum starts _after_ the SNAP header;
the problem with this is that we'd have to replace the exact
"what is the SNAP" check in iwlwifi that cfg80211 has.
2) Made it configurable with some flag, but that seemed like too
much complexity.
In UHB connection we don't have any HT/VHT elemens so in order to
calculate the max RX-NSS we need also to look at HE capa element, this
causes to limit us to max rx nss in UHB to 1.
Also anyway we need to look at HE max rx NSS and not only at HT/VHT
capa to determine the max rx nss over the connection.
Johannes Berg [Wed, 2 Feb 2022 08:49:34 +0000 (10:49 +0200)]
mac80211: limit bandwidth in HE capabilities
If we're limiting bandwidth for some reason such as regulatory
restrictions, then advertise that limitation just like we do
for VHT today, so the AP is aware we cannot use the higher BW
it might be using.
mt76: dma: initialize skip_unmap in mt76_dma_rx_fill
Even if it is only a false-positive since skip_buf0/skip_buf1 are only
used in mt76_dma_tx_cleanup_idx routine, initialize skip_unmap in
mt76_dma_rx_fill in order to fix the following UBSAN report:
Felix Fietkau [Wed, 2 Feb 2022 22:11:58 +0000 (23:11 +0100)]
mt76: mt7915: fix/rewrite the dfs state handling logic
Client mode on DFS channels was broken, because the old code was activating
the DFS detector on radar channels while leaving it in CAC state.
This was caused by making the decision based on the channel radar flag,
instead of hw->conf.radar_enabled.
In order to properly deal with the various corner cases, rip out the state
handling code and replace it with something that's much easier to reason
about.
Tested-by: Lorenzo Bianconi <lorenzo@kernel.org> Signed-off-by: Felix Fietkau <nbd@nbd.name>
Felix Fietkau [Mon, 31 Jan 2022 14:04:43 +0000 (15:04 +0100)]
mt76: mt76x02: improve tx hang detection
Instead of checking if any queue has not made progress since the last run,
only trigger hang detection if one of the queues has not made any progress
in 10 subsequent runs. This should reduce false positive firmware restarts
Sean Wang [Fri, 14 Jan 2022 23:56:32 +0000 (07:56 +0800)]
mt76: sdio: honor the largest Tx buffer the hardware can support
We don't have to create a separate sdio.xmit_buf buffer for each queue.
Instead, we just need to create one, reuse it across all queues to reduce
memory consumption further.
And then we should take it into account the actual the host and the device
MMC capability to determine what the appropriate xmit_buf_size can be.
Both MT7921S and MT7663 can support up to Tx FIFO size of 0x3fe00 which
means the device can receive 511 blocks of block size 512 in a row from
the host. So if the driver aggregates the frames as many as possible the
the device can support, we can merge multiple MMC requests into a single
one to get rid of the overhead of the handling and synchronizing in those
unnecessary MMC requests and reduce the SDIO lock contention with the
Bluetooth concurrent traffic and finally to have the higher bus
utilization with less idle cycle.
With the patch, it is helpful for WiFi to have steady throughput
performance especially while running Bluetooth concurrently.
Co-developed-by: Deren Wu <deren.wu@mediatek.com> Signed-off-by: Deren Wu <deren.wu@mediatek.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>
MeiChia Chiu [Thu, 27 Jan 2022 13:32:26 +0000 (21:32 +0800)]
mt76: mt7915: fix the nss setting in bitrates
without this change, the fixed MCS only supports 1 Nss.
Fixes: 70fd1333cd32f ("mt76: mt7915: rework .set_bitrate_mask() to support more options") Reviewed-by: Ryder Lee <ryder.lee@mediatek.com> Signed-off-by: MeiChia Chiu <meichia.chiu@mediatek.com> Signed-off-by: Felix Fietkau <nbd@nbd.name>
Lorenzo Bianconi [Mon, 24 Jan 2022 20:03:44 +0000 (21:03 +0100)]
mt76: mt7921s: fix a possible memory leak in mt7921_load_patch
Always release fw data at the end of mt7921_load_patch routine.
Fixes: 78b217580c509 ("mt76: mt7921s: fix bus hang with wrong privilege") Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Signed-off-by: Felix Fietkau <nbd@nbd.name>
Xing Song [Mon, 24 Jan 2022 03:28:11 +0000 (11:28 +0800)]
mt76: stop the radar detector after leaving dfs channel
The radar detctor is used for dfs channel. So it will start after switching
to dfs channel and will stop after leaving. The TX will be blocked if radar
detctor isn't stopped in non-dfs channel.
This patch resets the dfs state to indicate the radar detector needs to be
stopped.
Signed-off-by: Xing Song <xing.song@mediatek.com> Signed-off-by: Felix Fietkau <nbd@nbd.name>
Lorenzo Bianconi [Sat, 22 Jan 2022 14:58:57 +0000 (15:58 +0100)]
mt76: mt7603: check sta_rates pointer in mt7603_sta_rate_tbl_update
Check sta_rates pointer value in mt7603_sta_rate_tbl_update routine
since minstrel_ht_update_rates can fail allocating rates array.
Fixes: c8846e1015022 ("mt76: add driver for MT7603E and MT7628/7688") Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Signed-off-by: Felix Fietkau <nbd@nbd.name>
Piotr Dymacz [Wed, 19 Jan 2022 12:31:21 +0000 (13:31 +0100)]
mt76: mt7615: add support for LG LGSBWAC02 (MT7663BUN)
The LG LGSBWAC02 (FCC ID: BEJLGSBWAC02) is a combo Wi-Fi/BT module which
can be found in several different LG TV models. This module is based on
already supported MediaTek MT7663U series.
Add the capability to disable/enable radar/CAC detection running on
a dedicated offchannel chain available on some hw.
Offchannel radar/CAC detection allows to avoid CAC downtime switching
on a different channel during CAC detection on the selected radar
channel.
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Felix Fietkau <nbd@nbd.name>
Introduce mt7915_mcu_rdd_background_enable and
mt7915_mcu_background_chain_ctrl routines to configure rx dfs dedicated chain.
This is a preliminary patch to add zero-wait dfs support performing CAC
detection on rdd2.
Tested-by: Owen Peng <owen.peng@mediatek.com> Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Signed-off-by: Felix Fietkau <nbd@nbd.name>
Shayne Chen [Fri, 14 Jan 2022 09:49:11 +0000 (17:49 +0800)]
mt76: mt7915: set bssinfo/starec command when adding interface
bssinfo/starec disabled commands are sent during removing interface.
However, if we don't set corresponding enabled commands before
removing interface, the fw may enter an exception state due to
some NULL structs.
For example, the following commands can cause fw timeout in our newer
chips:
ifconfig wlan0/mon0 up
ifconfig wlan0/mon0 down
Fix this by setting enabled commands once interface added.
Signed-off-by: Shayne Chen <shayne.chen@mediatek.com> Signed-off-by: Felix Fietkau <nbd@nbd.name>
Sean Wang [Sun, 9 Jan 2022 08:33:50 +0000 (16:33 +0800)]
mt76: sdio: disable interrupt in mt76s_sdio_irq
It is unnecessary to keep the interrupt enabled in mt76s_sdio_irq because
the driver is already aware of the interrupt, schedules the
mt76s_txrx_worker to handle the corresponding actions, and eventually,
the interrupt would be enabled again when mt76s_txrx_worker finishes its
work.
So we can safely disable the interrupt in mt76s_sdio_irq as soon as
possible to increase the CPU productivity by dropping the redundant
interrupt triggers.
Note that sdio lock acquired/released would be handled in sdio_irq_work
at mmc driver so we don't take care in mt76s_sdio_irq at function driver.
Co-developed-by: Leon Yen <leon.yen@mediatek.com> Signed-off-by: Leon Yen <leon.yen@mediatek.com> Co-developed-by: Deren Wu <deren.wu@mediatek.com> Signed-off-by: Deren Wu <deren.wu@mediatek.com> Signed-off-by: Sean Wang <sean.wang@mediatek.com> Signed-off-by: Felix Fietkau <nbd@nbd.name>
Ben Greear [Sat, 8 Jan 2022 19:08:14 +0000 (11:08 -0800)]
mt76: mt7921: fix crash when startup fails.
If the nic fails to start, it is possible that the
reset_work has already been scheduled. Ensure the
work item is canceled so we do not have use-after-free
crash in case cleanup is called before the work item
is executed.
This fixes crash on my x86_64 apu2 when mt7921k radio
fails to work. Radio still fails, but OS does not
crash.
Signed-off-by: Ben Greear <greearb@candelatech.com> Signed-off-by: Felix Fietkau <nbd@nbd.name>
Sean Wang [Fri, 7 Jan 2022 07:30:03 +0000 (15:30 +0800)]
mt76: mt7921e: fix possible probe failure after reboot
It doesn't guarantee the mt7921e gets started with ASPM L0 after each
machine reboot on every platform.
If mt7921e gets started with not ASPM L0, it would be possible that the
driver encounters time to time failure in mt7921_pci_probe, like a
weird chip identifier is read
[ 215.514503] mt7921e 0000:05:00.0: ASIC revision: feed0000
[ 216.604741] mt7921e: probe of 0000:05:00.0 failed with error -110
or failing to init hardware because the driver is not allowed to access the
register until the device is in ASPM L0 state. So, we call
__mt7921e_mcu_drv_pmctrl in early mt7921_pci_probe to force the device
to bring back to the L0 state for we can safely access registers in any
case.
In the patch, we move all functions from dma.c to pci.c and register mt76
bus operation earilier, that is the __mt7921e_mcu_drv_pmctrl depends on.
Fixes: bf3747ae2e25 ("mt76: mt7921: enable aspm by default") Reported-by: Kai-Chuan Hsieh <kaichuan.hsieh@canonical.com> Co-developed-by: Deren Wu <deren.wu@mediatek.com> Signed-off-by: Deren Wu <deren.wu@mediatek.com> Signed-off-by: Sean Wang <sean.wang@mediatek.com> Signed-off-by: Felix Fietkau <nbd@nbd.name>
Leon Yen [Thu, 6 Jan 2022 19:50:10 +0000 (03:50 +0800)]
mt76: mt7921s: fix mt7921s_mcu_[fw|drv]_pmctrl
According to the firmware behavior (even the oldest one in linux-firmware)
If the firmware is downloaded, MT7921S must rely on the additional mailbox
mechanism that resides in firmware to check if the device is the right
state for mt7921s_mcu_[fw|drv]_pmctrl. Otherwise, we still apply the old
way for that.
That is a necessary patch before we enable runtime pm for mt7921s as
default.
Fixes: 48fab5bbef40 ("mt76: mt7921: introduce mt7921s support") Co-developed-by: Sean Wang <sean.wang@mediatek.com> Signed-off-by: Sean Wang <sean.wang@mediatek.com> Signed-off-by: Leon Yen <leon.yen@mediatek.com> Signed-off-by: Felix Fietkau <nbd@nbd.name>
Lorenzo Bianconi [Thu, 30 Dec 2021 20:47:06 +0000 (21:47 +0100)]
mt76: mt7615: fix a leftover race in runtime-pm
Fix a possible race in mt7615_pm_power_save_work() if rx/tx napi
schedules ps_work and we are currently accessing device register
on a different cpu.
Fixes: db928f1ab9789 ("mt76: mt7663: rely on mt76_connac_pm_ref/mt76_connac_pm_unref in tx/rx napi") Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Signed-off-by: Felix Fietkau <nbd@nbd.name>
Lorenzo Bianconi [Fri, 31 Dec 2021 11:36:02 +0000 (12:36 +0100)]
mt76: mt7921: do not always disable fw runtime-pm
After commit 'd430dffbe9dd ("mt76: mt7921: fix a possible race
enabling/disabling runtime-pm")', runtime-pm is always disabled in the
fw even if the user requests to enable it toggling debugfs node since
mt7921_pm_interface_iter routine will use pm->enable to configure the fw.
Fix the issue moving enable variable configuration before running
mt7921_pm_interface_iter routine.
Fixes: d430dffbe9dd ("mt76: mt7921: fix a possible race enabling/disabling runtime-pm") Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Signed-off-by: Felix Fietkau <nbd@nbd.name>
Lorenzo Bianconi [Mon, 27 Dec 2021 13:08:52 +0000 (14:08 +0100)]
mt76: mt7615: fix a possible race enabling/disabling runtime-pm
Similar to mt7921 driver, fix a possible race enabling/disabling
runtime-pm between mt7615_pm_set() and mt7615_poll_rx().
mt7615_pm_wake_work() always schedules rx-napi callback and it will
trigger mt7615_pm_power_save_work routine putting the chip in low-power
state even if we are disabling runtime-pm deferring the actual chip wake
at the next access.
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Signed-off-by: Felix Fietkau <nbd@nbd.name>
Sean Wang [Fri, 24 Dec 2021 08:33:56 +0000 (16:33 +0800)]
mt76: mt7921: set EDCA parameters with the MCU CE command
The command MCU_EXT_CMD_EDCA_UPDATE is not fully supported by the MT7921
firmware, so we apply CE command MCU_CE_CMD_SET_EDCA_PARAMS instead which
is supported even in the oldest firmware to properly set up EDCA parameters
for each AC.
Fixes: 1c099ab44727 ("mt76: mt7921: add MCU support") Signed-off-by: Sean Wang <sean.wang@mediatek.com> Signed-off-by: Felix Fietkau <nbd@nbd.name>
Fixed an MCU_CE_CMD_SET_ROC definition error that occurred from a previous
refactor work.
Fixes: d0e274af2f2e4 ("mt76: mt76_connac: create mcu library") Signed-off-by: Sean Wang <sean.wang@mediatek.com> Signed-off-by: Felix Fietkau <nbd@nbd.name>
YN Chen [Fri, 24 Dec 2021 08:32:49 +0000 (16:32 +0800)]
mt76: mt7921: forbid the doze mode when coredump is in progress
We forbid the doze mode while the collecting core dump is going because
that doesn't make sense and the firmware possibly stays in the abnormal
state where cannot handle the doze request from the driver anymore until
the WiFi reset procedure is completed.
Co-developed-by: Sean Wang <sean.wang@mediatek.com> Signed-off-by: Sean Wang <sean.wang@mediatek.com> Signed-off-by: YN Chen <YN.Chen@mediatek.com> Signed-off-by: Felix Fietkau <nbd@nbd.name>
projects / thirdparty / linux.git / log
