IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
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.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20211219121514.f05488ce8b83.I65bb83721498d8433e4ee2b09415eb74ab579445@changeid
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
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.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/20211210091245.289008-2-luca@coelho.fi
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
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).
Signed-off-by: Avraham Stern <avraham.stern@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20211210110539.3dd63c381839.Id79b39f650103bb9b851e31ed6a0178e81988587@changeid
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
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.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20211210110539.1f742f0eb58a.I1315f22f6aa632d94ae2069f85e1bca5e734dce0@changeid
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
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.
Fix this by adding the relevant size check.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20211210110539.84848da8067f.Ifb4f80c95d283ec62e495a7928069af711b5fee2@changeid
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
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.
Fixes: b68bd2e3143a ("iwlwifi: mvm: Add FTM initiator RTT smoothing logic")
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20211219111352.e56cbf614a4d.Ib98004ccd2c7a55fd883a8ea7eebd810f406dec6@changeid
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
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.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20211210110539.779d68490f68.I472c7d9cbaca46000a10ec18808ef54836b33a8a@changeid
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
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.
Cc: stable@vger.kernel.org
Signed-off-by: Ilan Peer <ilan.peer@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20211210090244.3c851b93aef5.I346fa2e1d79220a6770496e773c6f87a2ad9e6c4@changeid
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
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.
Reported-by: Sam Edwards <CFSworks@gmail.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20211210090244.1d8725b7518a.I0c36617a7282bd445cda484d97ac4a83022706ee@changeid
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
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.
Signed-off-by: Mordechay Goodstein <mordechay.goodstein@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20211210090244.7d1a57f3df1b.Ibc01dde2b064329ad5f5bcefa83d1998d557cbdb@changeid
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
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.
Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20211210090244.6f2fca102739.I8b5e37a00c50b7b51f7d377216dde91e71faffba@changeid
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
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.
Signed-off-by: Ayala Barazani <ayala.barazani@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20211210090244.27fe6abf2e4c.I806e4b47dabddaa8ac27172e7cfa3d719c100e8f@changeid
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
The original implementation checked the HW family, and as a result
of that used different addresses for the prph registers.
The old HWs addresses start with 0xa****** and the newer
ones start with 0xd******.
For this there are iwl_read/write_umac_prph functions that just add the
diff in the address automatically (in this case 0x300000), so the code will
be common for all HWs
In the original implementation the address given already had the 0xd******
causing the address to become 0x10***** (after adding the offset)
Change the registers to start with 0xa*****.
Signed-off-by: Matti Gottlieb <matti.gottlieb@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20211210090244.db2722547eb2.I03dce63698befc2fd9105111c3015b8d6e36868a@changeid
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
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.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Fixes: 6c0795f1a524 ("iwlwifi: implement Bz NMI behaviour")
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20211210090244.75b6207536e3.I7d170a48a9096e6b7269c3a9f447c326f929b171@changeid
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
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".
Sponsored by: The FreeBSD Foundation
Signed-off-by: Bjoern A. Zeeb <bz@FreeBSD.ORG>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
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.
Sponsored by: The FreeBSD Foundation
Signed-off-by: Bjoern A. Zeeb <bz@FreeBSD.ORG>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
These lines need to be indented one more tab.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Link: https://lore.kernel.org/r/20211110080922.GF5176@kili
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
This line was indented too far and was a bit confusing.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Link: https://lore.kernel.org/r/20211110080759.GE5176@kili
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
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.
download regdb.bin log:
[430082.334162] ath11k_pci 0000:05:00.0: chip_id 0x2 chip_family 0xb board_id 0x106 soc_id 0x400c0200
[430082.334169] ath11k_pci 0000:05:00.0: fw_version 0x110c8b4c fw_build_timestamp 2021-10-25 07:41 fw_build_id QC_IMAGE_VERSION_STRING=WLAN.HSP.1.1-02892-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3
[430082.334414] ath11k_pci 0000:05:00.0: boot firmware request ath11k/WCN6855/hw2.0/regdb.bin size 24310
output of "iw reg get"
global
country US: DFS-FCC
(2402 - 2472 @ 40), (N/A, 30), (N/A)
(5170 - 5250 @ 80), (N/A, 23), (N/A), AUTO-BW
(5250 - 5330 @ 80), (N/A, 23), (0 ms), DFS, AUTO-BW
(5490 - 5730 @ 160), (N/A, 23), (0 ms), DFS
(5735 - 5835 @ 80), (N/A, 30), (N/A)
(57240 - 63720 @ 2160), (N/A, 40), (N/A)
phy#0 (self-managed)
country US: DFS-FCC
(2402 - 2472 @ 40), (6, 30), (N/A)
(5170 - 5250 @ 80), (N/A, 24), (N/A), AUTO-BW
(5250 - 5330 @ 80), (N/A, 24), (0 ms), DFS, AUTO-BW
(5490 - 5730 @ 160), (N/A, 24), (0 ms), DFS, AUTO-BW
(5735 - 5895 @ 160), (N/A, 30), (N/A), AUTO-BW
(5945 - 7125 @ 160), (N/A, 24), (N/A), NO-OUTDOOR, AUTO-BW
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: Wen Gong <quic_wgong@quicinc.com>
Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com>
Link: https://lore.kernel.org/r/20211220062355.17021-1-quic_wgong@quicinc.com
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").
Reported-by: syzbot+cce1ee31614c171f5595@syzkaller.appspotmail.com
Cc: stable@vger.kernel.org
Fixes: a53268be0cb9 ("rtlwifi: rtl8192cu: Fix too long disable of IRQs")
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20211215171105.20623-1-Larry.Finger@lwfinger.net
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.
Signed-off-by: Chris Chiu <chris.chiu@canonical.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20211215085819.729345-1-chris.chiu@canonical.com
These settings enables mac to detect and recover when rx fifo
circuit deadlock occurs. Previous version missed this, so we fix it.
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/20211217012708.8623-1-pkshih@realtek.com
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.
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/20211217012421.7859-1-pkshih@realtek.com
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.
Fixes: 9e2fd29864c5 ("rtw88: add napi support")
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=215131
BugLink: https://bugs.launchpad.net/bugs/1927808
Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
Acked-by: Jian-Hong Pan <jhp@endlessos.org>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20211215114635.333767-1-kai.heng.feng@canonical.com
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.
Fixes: dc8b338f3bcd ("wilc1000: use goto labels on error path")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: Claudiu Beznea <claudiu.beznea@microchip.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20211217150311.GC16611@kili
If iwl_transt_start_hw() failed, we were returning without calling
wiphy_unlock() and rtnl_unlock(), causing a locking imbalance:
drivers/net/wireless/intel/iwlwifi/mvm/ops.c:686:12: warning: context imbalance in 'iwl_mvm_start_get_nvm' - wrong count at exit
Fix that by adding the unlock calls.
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20211219090128.42417-2-luca@coelho.fi
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.
Tested-on: QCA6390 hw2.0 PCI WLAN.HST.1.0.1-01740-QCAHSTSWPLZ_V2_TO_X86-1
Signed-off-by: Wen Gong <quic_wgong@quicinc.com>
Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com>
Link: https://lore.kernel.org/r/20211217102334.14907-1-quic_wgong@quicinc.com
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
Tested-on: QCA6390 hw2.0 PCI WLAN.HST.1.0.1-01740-QCAHSTSWPLZ_V2_TO_X86-1
Signed-off-by: Wen Gong <quic_wgong@quicinc.com>
Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com>
Link: https://lore.kernel.org/r/20211217093722.5739-1-quic_wgong@quicinc.com
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
CPU: 0 PID: 23 Comm: kworker/0:1 Not tainted 5.6.0 #63
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),
BIOS rel-1.10.2-0-g5f4c7b1-prebuilt.qemu-project.org 04/01/2014
Workqueue: events request_firmware_work_func
Call Trace:
<IRQ>
dump_stack+0x76/0xa0
print_address_description.constprop.0+0x16/0x200
? ath9k_hif_usb_rx_cb+0x490/0xed7 [ath9k_htc]
? ath9k_hif_usb_rx_cb+0x490/0xed7 [ath9k_htc]
__kasan_report.cold+0x37/0x7c
? ath9k_hif_usb_rx_cb+0x490/0xed7 [ath9k_htc]
kasan_report+0xe/0x20
check_memory_region+0x15a/0x1d0
memcpy+0x20/0x50
ath9k_hif_usb_rx_cb+0x490/0xed7 [ath9k_htc]
? hif_usb_mgmt_cb+0x2d9/0x2d9 [ath9k_htc]
? _raw_spin_lock_irqsave+0x7b/0xd0
? _raw_spin_trylock_bh+0x120/0x120
? __usb_unanchor_urb+0x12f/0x210
__usb_hcd_giveback_urb+0x1e4/0x380
usb_giveback_urb_bh+0x241/0x4f0
? __hrtimer_run_queues+0x316/0x740
? __usb_hcd_giveback_urb+0x380/0x380
tasklet_action_common.isra.0+0x135/0x330
__do_softirq+0x18c/0x634
irq_exit+0x114/0x140
smp_apic_timer_interrupt+0xde/0x380
apic_timer_interrupt+0xf/0x20
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.
Signed-off-by: Zekun Shen <bruceshenzk@gmail.com>
Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com>
Link: https://lore.kernel.org/r/YXsidrRuK6zBJicZ@10-18-43-117.dynapool.wireless.nyu.edu
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.
Link: https://syzkaller.appspot.com/bug?extid=31d54c60c5b254d6f75b [1]
Reported-by: syzbot <syzbot+31d54c60c5b254d6f75b@syzkaller.appspotmail.com>
Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Tested-by: syzbot <syzbot+31d54c60c5b254d6f75b@syzkaller.appspotmail.com>
Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com>
Link: https://lore.kernel.org/r/77b76ac8-2bee-6444-d26c-8c30858b8daa@i-love.sakura.ne.jp
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.
Link: https://syzkaller.appspot.com/bug?extid=4d2d56175b934b9a7bf9 [1]
Reported-by: syzbot <syzbot+4d2d56175b934b9a7bf9@syzkaller.appspotmail.com>
Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Tested-by: syzbot <syzbot+4d2d56175b934b9a7bf9@syzkaller.appspotmail.com>
Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com>
Link: https://lore.kernel.org/r/2b88f416-b2cb-7a18-d688-951e6dc3fe92@i-love.sakura.ne.jp
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.
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: Wen Gong <quic_wgong@quicinc.com>
Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com>
Link: https://lore.kernel.org/r/20211216070535.31732-1-quic_wgong@quicinc.com
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.
Co-developed-by: Thomas Huehn <thomas.huehn@hs-nordhausen.de>
Signed-off-by: Thomas Huehn <thomas.huehn@hs-nordhausen.de>
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com>
Link: https://lore.kernel.org/r/20211215215042.637-1-jelonek.jonas@gmail.com
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.
Signed-off-by: Deren Wu <deren.wu@mediatek.com>
Signed-off-by: Felix Fietkau <nbd@nbd.name>
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 <sean.wang@mediatek.com>
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Update pm->suspended usage to be consistent with mt7921e driver.
Signed-off-by: Sean Wang <sean.wang@mediatek.com>
Signed-off-by: Felix Fietkau <nbd@nbd.name>
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.
Fixes: ffa1bf97425b ("mt76: mt7921: introduce PM 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>
