wilc1000: Add reset/enable GPIO support to SPI driver
For the SDIO driver, the RESET/ENABLE pins of WILC1000 are controlled
through the SDIO power sequence driver. This commit adds analogous
support for the SPI driver. Specifically, during initialization, the
chip will be ENABLEd and taken out of RESET and during
deinitialization, the chip will be placed back into RESET and disabled
(both to reduce power consumption and to ensure the WiFi radio is
off).
Both RESET and ENABLE GPIOs are optional. However, if the ENABLE GPIO
is specified, then the RESET GPIO should normally also be specified as
otherwise there is no way to ensure proper timing of the ENABLE/RESET
sequence.
Chin-Yen Lee [Tue, 21 Dec 2021 02:02:30 +0000 (10:02 +0800)]
rtw88: don't consider deep PS mode when transmitting packet
In original flow, driver needs to ensure chip leave deep ps mode
before transmitting any packet, and don't enter deep ps mode beofre
PCIE DMA is finished. Now with the support of 8822ce's hardware
setting and firmware after v9.9.11, these limits are removed.
Baochen Qiang [Wed, 22 Dec 2021 01:35:35 +0000 (09:35 +0800)]
ath11k: Fix unexpected return buffer manager error for QCA6390
We are seeing below error on QCA6390:
...
[70211.671189] ath11k_pci 0000:72:00.0: failed to parse rx error in wbm_rel ring desc -22
[70212.696154] ath11k_pci 0000:72:00.0: failed to parse rx error in wbm_rel ring desc -22
[70213.092941] ath11k_pci 0000:72:00.0: failed to parse rx error in wbm_rel ring desc -22
...
The reason is that, with commit 734223d78428 ("ath11k: change return
buffer manager for QCA6390"), ath11k expects the return buffer manager
(RBM) field of descriptor configured as HAL_RX_BUF_RBM_SW1_BM when
parsing error frames from WBM2SW3_RELEASE ring. This is a wrong change
cause the RBM field is set as HAL_RX_BUF_RBM_SW3_BM.
The same issue also applies to REO2TCL ring though we have not got any
error reported.
Fix it by changing RBM from HAL_RX_BUF_RBM_SW1_BM to HAL_RX_BUF_RBM_SW3_BM
for these two rings.
Cheng Wang [Mon, 20 Dec 2021 12:10:53 +0000 (20:10 +0800)]
ath11k: add support of firmware logging for WCN6855
Host enables WMI firmware logging feature via QMI message.
Host receives firmware logging messages on WMI_DIAG_EVENTID, then
sends logging messages to user space via event tracing infrastructure.
Ben Greear [Thu, 3 Sep 2020 19:52:54 +0000 (12:52 -0700)]
ath11k: Fix napi related hang
Similar to the same bug in ath10k, a napi disable w/out it being enabled
will hang forever. I believe I saw this while trying rmmod after driver
had some failure on startup. Fix it by keeping state on whether napi is
enabled or not.
And, remove un-used napi pointer in ath11k driver base struct.
Jason Wang [Tue, 21 Dec 2021 10:04:20 +0000 (12:04 +0200)]
ath10k: replace strlcpy with strscpy
The strlcpy should not be used because it doesn't limit the source
length. So that it will lead some potential bugs.
But the strscpy doesn't require reading memory from the src string
beyond the specified "count" bytes, and since the return value is
easier to error-check than strlcpy()'s. In addition, the implementation
is robust to the string changing out from underneath it, unlike the
current strlcpy() implementation.
Zong-Zhe Yang [Mon, 20 Dec 2021 09:36:56 +0000 (17:36 +0800)]
rtw88: support SAR via kernel common API
Register cfg80211_sar_capa with type NL80211_SAR_TYPE_POWER and four
frequency ranges for configurations in unit of 0.25 dBm. And handle
callback set_sar_specs.
Originally, TX power has three main parameters, i.e. power base,
power by rate, and power limit. The formula can be simply considered
as TX power = power base + min(power by rate, power limit). With the
support of SAR which can be treated as another power limit, there is
one more parameter for TX power. And the formula will evolve into
TX power = power base + min(power by rate, power limit, power sar).
Besides, debugfs tx_pwr_tbl is also refined to show SAR information.
The following is an example for the difference.
Before supporting SAR,
-----------------------------------
...
path rate pwr base (byr lmt ) rem
A CCK_1M 66(0x42) 78 -12 ( 12 -12) 0
A CCK_2M 66(0x42) 78 -12 ( 8 -12) 0
...
-----------------------------------
After supporting SAR and making some configurations,
-----------------------------------
...
path rate pwr base (byr lmt sar ) rem
A CCK_1M 62(0x3e) 78 -16 ( 12 -12 -16) 0
A CCK_2M 62(0x3e) 78 -16 ( 8 -12 -16) 0
...
-----------------------------------
Po-Hao Huang [Tue, 21 Dec 2021 08:50:10 +0000 (16:50 +0800)]
rtw88: 8822c: add ieee80211_ops::hw_scan
Declare this function allows us to use customized scanning policy.
By doing so we can be more time efficient on each scan. In order to
make existing coex mechanism work as usual, firmware notifies driver
on each channel switch event, then decide antenna ownership based on
the current channel/band. Do note that this new mechanism affects
throughput more than the sw_scan we used to have, but the overall
average throughput is not affected since each scan take less time.
Since the firmware size is limited, we only support probe requests
with custom IEs length under 128 bytes for now, if any user space
tools requires more than that, we'll introduce related changes
afterwards. For backward compatibility, we fallback to sw_scan when
using older firmware that does not support this feature.
Kalle Valo [Tue, 21 Dec 2021 18:07:09 +0000 (20:07 +0200)]
Merge tag 'iwlwifi-next-for-kalle-2021-12-21-v2' of git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-next
wlwifi patches for v5.17 v2
* Support for Time-Aware-SAR (TAS) as read from the BIOS;
* Fix scan timeout issue when 6GHz is enabled;
* Work continues for new HW family Bz;
* Support for Optimized Connectivity Experience (OCE) scan;
* A bunch of FW debugging improvements and fixes;
* Fix one 32-bit compilation issue;
* Some RX changes for new HW family
* Some fixes for 6 GHz scan;
* Fix SAR table fixes with newer platforms;
* Fix early restart crash;
* Small fix in the debugging code;
* Add new Killer device IDs;
* Datapath updates for Bz family continues;
* A couple of important fixes in iwlmei;
* Some other small fixes, clean-ups and improvements.
The shared area is a DMA memory allocated in the host and
mapped so that the host and the CSME firmware can
exchange data. It is mapped through a dedicated PCI device
that is driven by the mei bus driver.
The bus driver is in charge of allocating and mapping this
memory. It also needs to configure the CSME firmware with
a specific set of commands, so that the CSME firmware will
know that this memory is meant to be used by its internal
WLAN module.
For this, the CSME firmware first needs to completely
initialize its WLAN module and only then get the mapping
request.
The problem is that the mei bus enumeration completes
before the WLAN is completely ready. This means that
the WLAN module's initialization is racing with iwlmei's
allocation and mapping flow.
Testing showed a problem in resume flows where iwlmei
was too fast and the DMA mapping failed.
Add a delay to avoid this. This is still racy, but our
measurements showed that we have a good margin and we
should now be safe.
iwlwifi: mei: clear the ownership when the driver goes down
When the driver is unregistered, CSME will take ownership on the
device. Reflect this in the iwlmei object so that we will remember
to re-ask for ownership when the driver will register again.
Not doing so will cause CSME not to give the host ownership and
we will see the following error message when trying to bring up
the interface:
iwlwifi 0000:a9:00.0: iwl_pcie_prepare_card_hw iwl_trans_prepare_card_hw enter
iwlwifi 0000:a9:00.0: iwl_pcie_set_hw_ready hardware not ready
iwlwifi 0000:a9:00.0: iwl_pcie_set_hw_ready hardware not ready
iwlwifi 0000:a9:00.0: iwl_pcie_prepare_card_hw Couldn't prepare the card but SAP is connected
iwlwifi 0000:a9:00.0: Error while preparing HW: -16
Luca Coelho [Sun, 19 Dec 2021 11:28:34 +0000 (13:28 +0200)]
iwlwifi: pcie: make sure prph_info is set when treating wakeup IRQ
In some rare cases when the HW is in a bad state, we may get this
interrupt when prph_info is not set yet. Then we will try to
dereference it to check the sleep_notif element, which will cause an
oops.
Fix that by ignoring the interrupt if prph_info is not set yet.
Avraham Stern [Sun, 19 Dec 2021 11:28:31 +0000 (13:28 +0200)]
iwlwifi: mvm: fix AUX ROC removal
When IWL_UCODE_TLV_CAPA_SESSION_PROT_CMD is set, removing a time event
always tries to cancel session protection. However, AUX ROC does
not use session protection so it was never removed. As a result,
if the driver tries to allocate another AUX ROC event right after
cancelling the first one, it will fail with a warning.
In addition, the time event data passed to iwl_mvm_remove_aux_roc_te()
is incorrect. Fix it.
iwlwifi: return op_mode only in case the failure is from MEI
Currently we always return the op_mode with valid pointer in case
getting NVM failed, while it's only relevant for cases that CSME is the
owner of the nic.
Fix this by checking also who's the owner of the nic.
Johannes Berg [Sun, 19 Dec 2021 11:28:29 +0000 (13:28 +0200)]
iwlwifi: mvm: support Bz TX checksum offload
Support TX checksum offload for Bz devices, where we have full
checksum offload (NETIF_F_HW_CSUM) and the hardware doesn't
need to parse the IP headers or anything.
Miri Korenblit [Sun, 19 Dec 2021 11:28:28 +0000 (13:28 +0200)]
iwlwifi: mvm: add US/CA to TAS block list if OEM isn't allowed
If OEM isn't in the allowed list, TAS should be disabled in US/CA.
Currently, if the OEM isn't allowed - we're sending the TAS only
if we are not in US or CA.
But this country check is done before we even know the country
(usually the configuration is ZZ in that stage).
So do the following instead:
1. Check if the current OEM is in the allowed list
2. If not - add US and CA to tas_block_list_array
3. Send the TAS table to FW.
Avraham Stern [Sun, 19 Dec 2021 10:18:20 +0000 (12:18 +0200)]
iwlwifi: mvm: perform 6GHz passive scan after suspend
The 6GHz passive scan is performed only once every 50 minutes.
However, in case of suspend/resume, the regulatory information
is reset, so 6GHz channels may become disabled.
Fix it by performing a 6GHz passive scan within 60 seconds after
suspend/resume even if the 50 minutes timeout did not expire yet.
Miri Korenblit [Sun, 19 Dec 2021 10:18:18 +0000 (12:18 +0200)]
iwlwifi: mvm: always store the PPAG table as the latest version.
In case of a conflict between BIOS version and FW
version of the PPAG table - the values arrive in the FW in the wrong
places. This happens because we're storing the table in different
structures depending on the BIOS version, not on the FW version,
and so the FW doesn't get what it expect to.
Always store the table in a v2 structure (which is a superset
of v1 and v0).
Also store the table in a structured way and in it's own structure,
rather then storing it in the ppag command structure, similarly to
the WRDS, EWRD and WGDS tables.
Ilan Peer [Sun, 19 Dec 2021 10:18:16 +0000 (12:18 +0200)]
iwlwifi: mvm: Fix calculation of frame length
The RADA might include in the Rx frame the MIC and CRC bytes.
These bytes should be removed for non monitor interfaces and
should not be passed to mac80211.
Fix the Rx processing to remove the extra bytes on non monitor
cases.
Nathan Errera [Sun, 19 Dec 2021 10:18:15 +0000 (12:18 +0200)]
iwlwifi: mvm: test roc running status bits before removing the sta
In some cases the sta is being removed twice since we do not test the
roc aux running before removing it. Start looking at the bit before
removing the sta.
Luca Coelho [Sun, 19 Dec 2021 10:18:14 +0000 (12:18 +0200)]
iwlwifi: don't pass actual WGDS revision number in table_revision
The FW API for PER_CHAIN_LIMIT_OFFSET_CMD is misleading. The element
name is table_rev, but it shouldn't actually contain the table
revision number, but whether we should use the South Korea scheme or
not.
Fix the driver so that we only set this value to either 0 or 1. It
will only be 1 (meaning South Korea) if the ACPI WGDS table revision
is 1.
Mukesh Sisodiya [Sun, 19 Dec 2021 10:18:13 +0000 (12:18 +0200)]
iwlwifi: yoyo: support TLV-based firmware reset
Support resetting the firmware via TLV-based debugging. When applied,
this will cause the driver to reset the firmware when the debugging
is triggered.
Johannes Berg [Sun, 19 Dec 2021 10:18:11 +0000 (12:18 +0200)]
iwlwifi: mvm: don't trust hardware queue number
We don't really have much reason to mistrust the hardware
queue number, but if it gets mixed up we still don't want
to access some data out of bounds, so drop such frames.
Johannes Berg [Sun, 19 Dec 2021 10:18:10 +0000 (12:18 +0200)]
iwlwifi: mvm: handle RX checksum on Bz devices
On Bz devices, the hardware checksums including the SNAP header,
starting directly after the MAC header, so we don't need the
extra checks and can just pass the checksum to mac80211.
Johannes Berg [Sun, 19 Dec 2021 10:18:09 +0000 (12:18 +0200)]
iwlwifi: mvm: use a define for checksum flags mask
For the upcoming Bz devices, we will set NETIF_F_HW_CSUM instead
of NETIF_F_IP_CSUM and NETIF_F_IPV6_CSUM. However, we still need
to be able to remove all the checksum bits, so add a mask for the
removal, and keep the old define for the feature advertisement.
Johannes Berg [Fri, 10 Dec 2021 09:12:45 +0000 (11:12 +0200)]
iwlwifi: remove module loading failure message
When CONFIG_DEBUG_TEST_DRIVER_REMOVE is set, iwlwifi crashes
when the opmode module cannot be loaded, due to completing
the completion before using drv->dev, which can then already
be freed.
Fix this by removing the (fairly useless) message. Moving the
completion later causes a deadlock instead, so that's not an
option.
Avraham Stern [Fri, 10 Dec 2021 09:12:43 +0000 (11:12 +0200)]
iwlwifi: mvm: add support for OCE scan
In case the fw supports OCE scan and one of the OCE feature flags
are set in the scan request, set the corresponding flag in the
firmware scan request.
Note that new firmware that indicates OCE support does not support
the probe deferral and suppression feature (which is optional).
Johannes Berg [Fri, 10 Dec 2021 09:12:42 +0000 (11:12 +0200)]
iwlwifi: fix leaks/bad data after failed firmware load
If firmware load fails after having loaded some parts of the
firmware, e.g. the IML image, then this would leak. For the
host command list we'd end up running into a WARN on the next
attempt to load another firmware image.
Fix this by calling iwl_dealloc_ucode() on failures, and make
that also clear the data so we start fresh on the next round.
Johannes Berg [Fri, 10 Dec 2021 09:12:41 +0000 (11:12 +0200)]
iwlwifi: fix debug TLV parsing
Debug TLV parsing was missing size checks, so if a valid but
too short TLV was encountered, it would attempt to read it.
If the firmware file was arranged to be a multiple of pages
long with this happening just before the end, it could crash
reading out-of-bounds of a vmalloc area.
Johannes Berg [Sun, 19 Dec 2021 09:14:18 +0000 (11:14 +0200)]
iwlwifi: mvm: fix 32-bit build in FTM
On a 32-bit build, the division here needs to be done
using do_div(), otherwise the compiler will try to call
a function that doesn't exist, thus failing to build.
Johannes Berg [Fri, 10 Dec 2021 09:12:36 +0000 (11:12 +0200)]
iwlwifi: parse error tables from debug TLVs
With more things being added, we're no longer going to duplicate
the error tables from the debug TLVs nor send them at runtime.
Use the debug TLVs to find the locations of the error tables. As
we've never released firmware using IWL_UCODE_TLV_TCM_DEBUG_ADDRS
just remove that entirely.
Ilan Peer [Fri, 10 Dec 2021 07:06:21 +0000 (09:06 +0200)]
iwlwifi: mvm: Increase the scan timeout guard to 30 seconds
With the introduction of 6GHz channels the scan guard timeout should
be adjusted to account for the following extreme case:
- All 6GHz channels are scanned passively: 58 channels.
- The scan is fragmented with the following parameters: 3 fragments,
95 TUs suspend time, 44 TUs maximal out of channel time.
The above would result with scan time of more than 24 seconds. Thus,
set the timeout to 30 seconds.
Luca Coelho [Fri, 10 Dec 2021 07:06:20 +0000 (09:06 +0200)]
iwlwifi: recognize missing PNVM data and then log filename
We can detect that a FW SYSASSERT is due to missing PNVM data by
checking the assertion code. When this happens, it's is useful for
the user if we print the filename where the driver is looking for the
data.
Add the PNVM missing assertion code to the dump list and print out the
name of the file we're looking for when this happens.
iwlwifi: rs: add support for TLC config command ver 4
The new version enables support for EHT mode configurations.
The name of IWL_TLC_HT_BW_NONE_160 change to IWL_TLC_MCS_PER_BW_80
to make the difference from 80 bandwidth (non 160), and the new bandwidth
320 which is also non 160.
Gregory Greenman [Fri, 10 Dec 2021 07:06:18 +0000 (09:06 +0200)]
iwlwifi: mvm: rfi: update rfi table
After some lab experimentation with different DDRs, need
to update the table. Also, arrange it by frequency and not
by DDR type since now the table contains a super-set of all
possible conflicts.
Ayala Barazani [Fri, 10 Dec 2021 07:06:16 +0000 (09:06 +0200)]
iwlwifi: mvm: Add list of OEMs allowed to use TAS
Add list of vendors that are allowed to use TAS and check it
against the value provided in the SMBIOS manufacturer field.
Initially add the following approved vendors: HP, Dell, Lenovo and Samsung.
Johannes Berg [Fri, 10 Dec 2021 07:06:11 +0000 (09:06 +0200)]
iwlwifi: fix Bz NMI behaviour
Contrary to what was stated before, the hardware hasn't changed
the bits here yet. In any case, the new CSR is also directly
(lower 16 bits) connected to UREG_DOORBELL_TO_ISR6, so if it
still changes the changes would be there. Adjust the code and
comments accordingly.
Bjoern A. Zeeb [Wed, 10 Mar 2021 14:39:58 +0000 (14:39 +0000)]
iwlwifi: do not use __unused as variable name
On various systems __unused is a define to __attribute__((__unused__))
and yields compile errors as a result. Use __spare instead to describe
that these bits are "unused".
Bjoern A. Zeeb [Wed, 10 Mar 2021 14:40:23 +0000 (14:40 +0000)]
iwlwifi: iwl-eeprom-parse: mostly dvm only
Most of iwl-eeprom-parse.c is only used for dvm but not for mvm.
Hide the parts under #if IS_ENABLED(CONFIG_IWLDVM) to reduce size
and code surface for mvm-only builds.
Wen Gong [Mon, 20 Dec 2021 06:23:55 +0000 (01:23 -0500)]
ath11k: add regdb.bin download for regdb offload
The regdomain is self-managed type for ath11k, the regdomain info is
reported from firmware, it is not from wireless regdb. Firmware fetch
the regdomain info from board data file before. Currently most of the
regdomain info has moved to another file regdb.bin from board data
file for some chips such as QCA6390 and WCN6855, so the regdomain info
left in board data file is not enough to support the feature which need
more regdomain info.
After download regdb.bin, firmware will fetch the regdomain info from
regdb.bin instead of board data file and report to ath11k. If it does
not have the file regdb.bin, it also can initialize wlan success and
firmware then fetch regdomain info from board data file.
Add download the regdb.bin before download board data for some specific
chip which support supports_regdb in hardware parameters.
Larry Finger [Wed, 15 Dec 2021 17:11:05 +0000 (11:11 -0600)]
rtlwifi: rtl8192cu: Fix WARNING when calling local_irq_restore() with interrupts enabled
Syzbot reports the following WARNING:
[200~raw_local_irq_restore() called with IRQs enabled
WARNING: CPU: 1 PID: 1206 at kernel/locking/irqflag-debug.c:10
warn_bogus_irq_restore+0x1d/0x20 kernel/locking/irqflag-debug.c:10
Hardware initialization for the rtl8188cu can run for as long as 350 ms,
and the routine may be called with interrupts disabled. To avoid locking
the machine for this long, the current routine saves the interrupt flags
and enables local interrupts. The problem is that it restores the flags
at the end without disabling local interrupts first.
This patch fixes commit a53268be0cb9 ("rtlwifi: rtl8192cu: Fix too long
disable of IRQs").
Chris Chiu [Wed, 15 Dec 2021 08:58:19 +0000 (16:58 +0800)]
rtl8xxxu: Improve the A-MPDU retransmission rate with RTS/CTS protection
The A-MPDU TX retransmission rate is always high (> 20%) even in a very
clean environment. However, the vendor driver retransimission rate is
< 10% in the same test bed. The difference is the vendor driver starts
the A-MPDU TXOP with initial RTS/CTS handshake which is observed in the
air capture and the TX descriptor. Since the driver does not know how
many frames will be aggregated and the estimated duration, forcing the
RTS/CTS protection for A-MPDU helps to lower the retransmission rate
from > 20% to ~12% in the same test setup with the vendor driver.
Chin-Yen Lee [Fri, 17 Dec 2021 01:24:21 +0000 (09:24 +0800)]
rtw88: don't check CRC of VHT-SIG-B in 802.11ac signal
Currently all realtek wifi chip is set to check CRC of VHT-SIG-B
in 802.11ac signal, but some AP don't calculate the CRC and packets
from these AP can't be received and lead to disconnection.
We disable the check defaultly to avoid this case.
Kai-Heng Feng [Wed, 15 Dec 2021 11:46:34 +0000 (19:46 +0800)]
rtw88: Disable PCIe ASPM while doing NAPI poll on 8821CE
Many Intel based platforms face system random freeze after commit 9e2fd29864c5 ("rtw88: add napi support").
The commit itself shouldn't be the culprit. My guess is that the 8821CE
only leaves ASPM L1 for a short period when IRQ is raised. Since IRQ is
masked during NAPI polling, the PCIe link stays at L1 and makes RX DMA
extremely slow. Eventually the RX ring becomes messed up:
[ 1133.194697] rtw_8821ce 0000:02:00.0: pci bus timeout, check dma status
Since the 8821CE hardware may fail to leave ASPM L1, manually do it in
the driver to resolve the issue.
Dan Carpenter [Fri, 17 Dec 2021 15:03:12 +0000 (18:03 +0300)]
wilc1000: fix double free error in probe()
Smatch complains that there is a double free in probe:
drivers/net/wireless/microchip/wilc1000/spi.c:186 wilc_bus_probe() error: double free of 'spi_priv'
drivers/net/wireless/microchip/wilc1000/sdio.c:163 wilc_sdio_probe() error: double free of 'sdio_priv'
The problem is that wilc_netdev_cleanup() function frees "wilc->bus_data".
That's confusing and a layering violation. Leave the frees in probe(),
delete the free in wilc_netdev_cleanup(), and add some new frees to the
remove() functions.
Wen Gong [Mon, 20 Dec 2021 16:11:09 +0000 (18:11 +0200)]
ath11k: add support for hardware rfkill for QCA6390
When hardware rfkill is enabled in the firmware it will report the
capability via using WMI_SYS_CAP_INFO_RFKILL bit in the WMI_SERVICE_READY
event to the host. ath11k will check the capability, and if it is enabled then
ath11k will set the GPIO information to firmware using WMI_PDEV_SET_PARAM. When
the firmware detects hardware rfkill is enabled by the user, it will report it
via WMI_RFKILL_STATE_CHANGE_EVENTID. Once ath11k receives the event it will
send wmi command WMI_PDEV_SET_PARAM to the firmware and also notifies cfg80211.
This only enable rfkill feature for QCA6390, rfkill_pin is all initialized to 0
for other chips in ath11k_hw_params.
Wen Gong [Mon, 20 Dec 2021 16:11:09 +0000 (18:11 +0200)]
ath11k: report tx bitrate for iw wlan station dump
HTT_T2H_MSG_TYPE_PPDU_STATS_IND is a message which include the ppdu
info, currently it is not report from firmware for ath11k, then the
tx bitrate of "iw wlan0 station dump" always show an invalid value
"tx bitrate: 6.0 MBit/s".
To address the issue, this is to parse the info of tx complete report
from firmware and indicate the tx rate to mac80211.
After that, "iw wlan0 station dump" show the correct tx bit rate such
as:
tx bitrate: 78.0 MBit/s MCS 12
tx bitrate: 144.4 MBit/s VHT-MCS 7 short GI VHT-NSS 2
tx bitrate: 286.7 MBit/s HE-MCS 11 HE-NSS 2 HE-GI 0 HE-DCM 0
tx bitrate: 1921.5 MBit/s 160MHz HE-MCS 9 HE-NSS 2 HE-GI 0 HE-DCM 0
Zekun Shen [Thu, 28 Oct 2021 22:21:42 +0000 (18:21 -0400)]
ath9k: Fix out-of-bound memcpy in ath9k_hif_usb_rx_stream
Large pkt_len can lead to out-out-bound memcpy. Current
ath9k_hif_usb_rx_stream allows combining the content of two urb
inputs to one pkt. The first input can indicate the size of the
pkt. Any remaining size is saved in hif_dev->rx_remain_len.
While processing the next input, memcpy is used with rx_remain_len.
4-byte pkt_len can go up to 0xffff, while a single input is 0x4000
maximum in size (MAX_RX_BUF_SIZE). Thus, the patch adds a check for
pkt_len which must not exceed 2 * MAX_RX_BUG_SIZE.
BUG: KASAN: slab-out-of-bounds in ath9k_hif_usb_rx_cb+0x490/0xed7 [ath9k_htc]
Read of size 46393 at addr ffff888018798000 by task kworker/0:1/23
I found the bug using a custome USBFuzz port. It's a research work
to fuzz USB stack/drivers. I modified it to fuzz ath9k driver only,
providing hand-crafted usb descriptors to QEMU.
After fixing the value of pkt_tag to ATH_USB_RX_STREAM_MODE_TAG in QEMU
emulation, I found the KASAN report. The bug is triggerable whenever
pkt_len is above two MAX_RX_BUG_SIZE. I used the same input that crashes
to test the driver works when applying the patch.
ath9k_htc: fix NULL pointer dereference at ath9k_htc_tx_get_packet()
syzbot is reporting lockdep warning at ath9k_wmi_event_tasklet() followed
by kernel panic at get_htc_epid_queue() from ath9k_htc_tx_get_packet() from
ath9k_htc_txstatus() [1], for ath9k_wmi_event_tasklet(WMI_TXSTATUS_EVENTID)
depends on spin_lock_init() from ath9k_init_priv() being already completed.
Since ath9k_wmi_event_tasklet() is set by ath9k_init_wmi() from
ath9k_htc_probe_device(), it is possible that ath9k_wmi_event_tasklet() is
called via tasklet interrupt before spin_lock_init() from ath9k_init_priv()
from ath9k_init_device() from ath9k_htc_probe_device() is called.
Let's hold ath9k_wmi_event_tasklet(WMI_TXSTATUS_EVENTID) no-op until
ath9k_tx_init() completes.
ath9k_htc: fix NULL pointer dereference at ath9k_htc_rxep()
syzbot is reporting lockdep warning followed by kernel panic at
ath9k_htc_rxep() [1], for ath9k_htc_rxep() depends on ath9k_rx_init()
being already completed.
Since ath9k_htc_rxep() is set by ath9k_htc_connect_svc(WMI_BEACON_SVC)
from ath9k_init_htc_services(), it is possible that ath9k_htc_rxep() is
called via timer interrupt before ath9k_rx_init() from ath9k_init_device()
is called.
Since we can't call ath9k_init_device() before ath9k_init_htc_services(),
let's hold ath9k_htc_rxep() no-op until ath9k_rx_init() completes.
Wen Gong [Fri, 17 Dec 2021 18:27:21 +0000 (20:27 +0200)]
ath11k: fix warning of RCU usage for ath11k_mac_get_arvif_by_vdev_id()
When enable more debug config, it happen below warning. It is because
the caller does not add rcu_read_lock()/rcu_read_unlock() to wrap the
rcu_dereference().
Add rcu_read_lock()/rcu_read_unlock() to wrap rcu_dereference(), then
fixed it.
[ 180.716604] =============================
[ 180.716670] WARNING: suspicious RCU usage
[ 180.716734] 5.16.0-rc4-wt-ath+ #542 Not tainted
[ 180.716895] -----------------------------
[ 180.716957] drivers/net/wireless/ath/ath11k/mac.c:506 suspicious rcu_dereference_check() usage!
[ 180.717023]
other info that might help us debug this:
Wen Gong [Fri, 17 Dec 2021 18:27:21 +0000 (20:27 +0200)]
ath11k: add signal report to mac80211 for QCA6390 and WCN6855
IEEE80211_HW_USES_RSS is set in ath11k, then the device uses RSS and
thus requires parallel RX which implies using per-CPU station statistics
in sta_get_last_rx_stats() of mac80211. Currently signal is only set in
ath11k_mgmt_rx_event(), and not set for RX data packet, then it show
signal as 0 for iw command easily.
Change to get signal from firmware and report to mac80211.
For QCA6390 and WCN6855, the rssi value is already in dbm unit, so
don't need to convert it again.
Wen Gong [Fri, 17 Dec 2021 18:27:21 +0000 (20:27 +0200)]
ath11k: report rssi of each chain to mac80211 for QCA6390/WCN6855
Command "iw wls1 station dump" does not show each chain's rssi currently.
If the rssi of each chain from mon status which parsed in function
ath11k_hal_rx_parse_mon_status_tlv() is invalid, then ath11k send
wmi cmd WMI_REQUEST_STATS_CMDID with flag WMI_REQUEST_RSSI_PER_CHAIN_STAT
to firmware, and parse the rssi of chain in wmi WMI_UPDATE_STATS_EVENTID,
then report them to mac80211.
WMI_REQUEST_STATS_CMDID is only sent when CONFIG_ATH11K_DEBUGFS is set,
it is only called by ath11k_mac_op_sta_statistics(). It does not effect
performance and power consumption. Because after STATION connected to
AP, it is only called every 6 seconds by NetworkManager in below stack.
Jonas Jelonek [Fri, 17 Dec 2021 18:27:20 +0000 (20:27 +0200)]
ath5k: switch to rate table based lookup
Switching from legacy usage of ieee80211_get_tx_rates() lookup to direct
rate table lookup in struct ieee80211_sta->rates.
The current rate control API allows drivers to directly get rates from
ieee80211_sta->rates. ath5k is currently one of the legacy drivers that
perform translation/merge with the internal rate table via
ieee80211_get_tx_rates provided by rate control API.
For our upcoming changes to rate control API and the implementation of
transmit power control, this patch changes the behaviour. The call to
ieee80211_get_tx_rates and subsequent calls are also avoided. ath5k now
directly reads rates from sta->rates into its internal rate table. Cause
ath5k does not rely on the rate array in SKB->CB, this is not considered
anymore except for the first entry (used for probing).
Tested this on a PCEngines ALIX with CMP9-GP miniPCI wifi card (Atheros
AR5213A). Generated traffic between AP and multiple STAs before and
after applying the patch and simultaneously measured throughput and
captured rc_stats. Comparison resulted in same rate selection and no
performance loss between both runs.
Deren Wu [Thu, 16 Dec 2021 17:02:09 +0000 (01:02 +0800)]
mt76: mt7921s: fix cmd timeout in throughput test
During heavy loading throughtput test, the RX buffer (128)
would be exhausted and some RX pkts dropped randomly. Increase
buffer size from 128 to 512 (a safer length) to avoid tput degrade
or cmd-timeout problem.
Sean Wang [Wed, 15 Dec 2021 21:25:37 +0000 (05:25 +0800)]
mt76: mt7921s: fix suspend error with enlarging mcu timeout value
Fix the false positive suspend error that may occur on mt7921s
with enlarging mcu timeout value.
The reason why we have to enlarge mcu timeout from HZ / 3 to HZ is
we should consider the additional overhead caused by running
concurrently with btmtksdio (a MT7921 bluetooth SDIO driver) that
would compete for the same SDIO bus in process context to complete
the suspend procedure.
Fixes: 48fab5bbef40 ("mt76: mt7921: introduce mt7921s support") Signed-off-by: Sean Wang <[email protected]> Signed-off-by: Felix Fietkau <[email protected]>
Sean Wang [Wed, 15 Dec 2021 21:25:35 +0000 (05:25 +0800)]
mt76: mt7921: fix possible resume failure
Fix the possible resume failure due to mt76_connac_mcu_set_hif_suspend
timeout.
That is because clearing the flag pm->suspended too early opened up a race
window, where mt7921_poll_tx/rx scheduled a ps_work to put the device in
doze mode, that is unexpected for the device is being resumed from the
suspend state and would make the remaining MCU comamnds in resume handler
failed to execute.
projects / linux.git / log