In Turris MOX SDIO card [1], which uses Marvell 88W997 and its driver
mwifiex, you might get cryptic messages, which are not helpful to use.
@pali created patch, which improves messages by the driver and he will
send this to Linux kernel soon.
Before:
[ 81.026156] mwifiex_sdio mmc1:0001:1: CMD_RESP: cmd 0x20 error, result=0x1
After:
[ 15.784018] mwifiex_sdio mmc1:0001:1: CMD_RESP: cmd RF_ANTENNA (0x20) error, result=0x1
Signed-off-by: Josef Schlehofer <pepe.schlehofer@gmail.com>
SDIO chip 88W9997 from NXP [1] is quite limited by its firmware and
driver. Add hacky patch to allow up to 4 SSID instead of 3 SSID.
Signed-off-by: Josef Schlehofer <pepe.schlehofer@gmail.com>
This reverts the airtime scheduler back from the virtual-time based scheduler
to the deficit round robin scheduler implementation.
This reduces burstiness and improves fairness by improving interaction with AQL.
Signed-off-by: Felix Fietkau <nbd@nbd.name>
The MAC can be stored in OTP memory or in flash memory, currently the
driver could read it only from OTP. Backport the patch allowing setting
the MAC address from flash. Some modules have the OTP programmed but
the ODM/OEM decided to overwrite it with value stored in flash.
Signed-off-by: Tomasz Maciej Nowak <tmn505@gmail.com>
This backports encap offload support from upstream.
On some ath10k devices there can be about 10% improvement on tx throughput.
Users can turn it on by setting frame_mode=2.
Signed-off-by: Zhijun You <hujy652@gmail.com>
Sync nl80211.h with upstream in order to maintain parity with
nl80211_copy.h shipped with hostapd.
This is necessary, as currently the enum value for
NL80211_EXT_FEATURE_RADAR_BACKGROUND mismatches between hostapd and
mac80211. This breaks background radar capability detection in hostapd.
Reported-by: Lorenzo Bianconi <lorenzo@kernel.org>
Signed-off-by: David Bauer <mail@david-bauer.net>
latency and short-term fairness is improved by fixing the tx queue sorting
so that it considers the pending AQL budget
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Add ieee80211_rx_check_bss_color_collision routine in order to introduce
BSS color collision detection in mac80211 if it is not supported in HW/FW
(e.g. for mt7915 chipset).
Add IEEE80211_HW_DETECTS_COLOR_COLLISION flag to let the driver notify
BSS color collision detection is supported in HW/FW. Set this for ath11k
which apparently didn't need this code.
Tested-by: Peter Chiu <Chui-Hao.Chiu@mediatek.com>
Co-developed-by: Ryder Lee <ryder.lee@mediatek.com>
Signed-off-by: Ryder Lee <ryder.lee@mediatek.com>
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
Link: https://lore.kernel.org/r/a05eeeb1841a84560dc5aaec77894fcb69a54f27.1648204871.git.lorenzo@kernel.org
[clarify commit message a bit, move flag to mac80211]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: David Bauer <mail@david-bauer.net>
Some ath10k IPQ40xx devices like the MikroTik hAP ac2 and ac3 require the
BDF-s to be extracted from the device storage instead of shipping packaged
API 2 BDF-s.
This is required as MikroTik has started shipping boards that require BDF-s
to be updated, as otherwise their WLAN performance really suffers.
This is however impossible as the devices that require this are release under
the same revision and its not possible to differentiate them from devices
using the older BDF-s.
In OpenWrt we are extracting the calibration data during runtime and we are
able to extract the BDF-s in the same manner, however we cannot package the
BDF-s to API 2 format on the fly and can only use API 1 to provide BDF-s on
the fly.
This is an issue as the ath10k driver explicitly looks only for the board.bin
file and not for something like board-bus-device.bin like it does for pre-cal
data.
Due to this we have no way of providing correct BDF-s on the fly, so lets
extend the ath10k driver to first look for BDF-s in the board-bus-device.bin
format, for example: board-ahb-a800000.wifi.bin
If that fails, look for the default board file name as defined previously.
So, backport the upstream ath10k patch.
Signed-off-by: Robert Marko <robimarko@gmail.com>
This reverts commit f9ff282d17 as during
upstream patch review process nbd pointed out, that this patch needs
more work:
"The patch looks wrong to me. I'm pretty sure that AR_CH0_TOP2 is the
correct register, the definition has an explicit check for 9561 as well.
I believe this patch works by accident because it avoids writing a wrong
value to that register."
1. https://lore.kernel.org/all/91c58969-c60e-2f41-00ac-737786d435ae@nbd.name
Signed-off-by: Petr Štetiar <ynezz@true.cz>
ath9k is setting the TX PA DC bias level different on QCA9561 and QCA9565
although they have the same radio IP-core, which results in a very low
output power and very low throughput as devices are further away from
the AP (compared to other 2.4GHz APs.)
In real life testing, without this patch the 2.4GHz throughput on Yuncore
XD3200 is around 10Mbps sitting close to the AP, and close to theoretical
maximum with the patch applied.
Signed-off-by: Clemens Hopfer <openwrt@wireloss.net>
[edit commit message]
Signed-off-by: Thibaut VARÈNE <hacks@slashdirt.org>
This updates mac80211 to version 5.15.33-1 which is based on kernel
5.15.33.
The removed patches were applied upstream.
This new release contains many fixes which were merged into the upstream
Linux kernel.
This also contains the following new drivers which are needed for ath11k:
* net/qrtr/
* drivers/bus/mhi/
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
LOCK_STATE_HELD define was omitted during backport of
lockdep_assert_not_held() which leads to build failures of kernels with
CONFIG_LOCKDEP=y:
backports-5.15.8-1/backport-include/linux/lockdep.h:16:47: error: 'LOCK_STATE_HELD' undeclared (first use in this function)
Fix it by adding missing LOCK_STATE_HELD define.
References: PR#9373
Reported-by: Oskari Rauta <oskari.rauta@gmail.com>
Signed-off-by: Petr Štetiar <ynezz@true.cz>
Both struct net_device_path_ctx and struct net_device_path
are not available in 5.4. This causes an build error on the
bcm63xx target.
|mac80211/driver-ops.h: In function 'drv_net_fill_forward_path':
|driver-ops.h:1502:57: error: passing argument 4 of
|'local->ops->net_fill_forward_path' from incompatible pointer type
| [-Werror=incompatible-pointer-types]
| 1502 | ctx, path);
| | ^~~
| | |
| | struct net_device_path_ctx *
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>
Based on: 1ac627024d ("kernel: ath10k-ct: provide a build variant for
small RAM devices")
Like described in the ath10k-ct-smallbuffers version, oom-killer gets
triggered frequently by devices with small RAM.
That change is necessary for many community mesh networks which use
ath10k based devices with too little RAM. The -ct driver has been
proven unstable if used with 11s meshing and only wave2 chipsets are
supporting 11s. Freifunk Berlin is nowadays assembling its
firmware-based completely of vanilla OpenWRT with some package additions
which are made through the imagebuilder. Therefore we cannot take the
approach other freifunk communities have taken to maintain that patch
downstream [1]. Other communities consider these devices as broken and
that change would pretty much give those devices a second life [2].
[1] - 450b306e54
[2] - https://github.com/freifunk-gluon/gluon/issues/1988#issuecomment-619532909
Signed-off-by: Simon Polack <spolack+git@mailbox.org>
Signed-off-by: Nick Hainke <vincent@systemli.org>
The following patches were backported from upstream before and are not
needed any more:
package/kernel/mac80211/patches/ath10k/081-ath10k-fix-module-load-regression-with-iram-recovery-feature.patch
package/kernel/mac80211/patches/ath10k/980-ath10k-fix-max-antenna-gain-unit.patch
package/kernel/mac80211/patches/build/010-headers-Add-devm_platform_get_and_ioremap_resource.patch
package/kernel/mac80211/patches/subsys/300-mac80211-drop-check-for-DONT_REORDER-in-__ieee80211_.patch
package/kernel/mac80211/patches/subsys/307-mac80211-do-not-access-the-IV-when-it-was-stripped.patch
package/kernel/mac80211/patches/subsys/308-mac80211-fix-radiotap-header-generation.patch
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Some drivers that do their own sequence number allocation (e.g. ath9k, mwlwifi) rely
on being able to modify params->ssn on starting tx ampdu sessions.
This was broken by a change that modified it to use sta->tid_seq[tid] instead.
Signed-off-by: Felix Fietkau <nbd@nbd.name>
The nl80211_set_wiphy() function was changed between kernel 5.11 and
5.12 to take the rdev->wiphy lock which should be freed at the end
again. The 500-mac80211_configure_antenna_gain.patch added some code
which just returned in some cases without unlocking. This resulted in a
deadlock with brcmfmac.
This patch fixes this by also jumping to the out label in case we want
to leave the function.
This fixes a hanging system when brcmfmac is in use. I do not know why
we do not see this with other driver.
The kernel returns very useful debug details when setting these OpenWrt
configuration options:
CONFIG_KERNEL_DETECT_HUNG_TASK=y
CONFIG_KERNEL_PROVE_LOCKING=y
Fixes: FS#4122
Fixes: b96c2569ac ("mac80211: Update to version 5.12.19-1")
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
When __ieee80211_select_queue is called, skb->cb has not been cleared yet,
which means that info->control.flags can contain garbage.
In some cases this leads to IEEE80211_TX_CTRL_DONT_REORDER being set, causing
packets marked for other queues to randomly end up in BE instead.
Signed-off-by: Felix Fietkau <nbd@nbd.name>
With "getting WIFI MAC from NVMEM" working on ath79 on 5.10,
the next logical step I think is to utilize nvmem subsystem
to also get the calibration data from there.
This will tremendously speed up the wifi bring-up, since
we no longer need the userspace helper for the simple
devices that can just load them from there.
included with this patch is a package/mac80211/refresh.
Tested on: WNDR3700v2, TP-Link Archer C7v2
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>
Backport upstream fix for module load regression caused by IRAM recovery.
Without this patch devices using mainline ath10k driver could lost wireless
function because ath10k module failed to load.
Signed-off-by: Zhijun You <hujy652@gmail.com>
OpenWrt maintains two special out-of-tree DT properties:
"qca,disable-5ghz" and "qca,disable-2ghz". These are implemented
in a mac80211 ath9k patch "550-ath9k-disable-bands-via-dt.patch".
With the things being what they are, now might be a good
point to switch the devices to the generic and upstream
"ieee80211-freq-limit" property. This property is much
broader and works differently. Instead of disabling the
drivers logic which would add the affected band and
channels. It now disables all channels which are not
within the specified frequency range.
Reviewed-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Tested-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com> # HH5A
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>
This function is missing in kernel 5.4, but it is sued by ath10k.
This fixes the build of ath10k on some targets.
Fixes: cfe0eb7485 ("mac80211: Update to version 5.14.13-1")
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
The removed patches were applied upstream.
The Cisco Aironet 802.11b driver was removed from backports, remove
it also from OpenWrt.
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
