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>
The removed patches were applied upstream.
of_get_mac_address() was backported in our OpenWrt kernel, remove the
change from backports.
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
The removed patches were applied upstream.
This backports version 5.11.22 and later does not support kernel
versions < 4.4, this allows us to remove some patches too.
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
In the current state, nvmem cells are only detected on platform device.
To quickly fix the problem, we register the affected problematic driver
with the of_platform but that is more an hack than a real solution.
Backport from net-next the required patch so that nvmem can work also
with non-platform devices and rework our current patch.
Drop the mediatek and dsa workaround and rework the ath10k patches.
Rework every driver that use the of_get_mac_address api.
Signed-off-by: Ansuel Smith <ansuelsmth@gmail.com>
of_platform_device_create require CONFIG_OF selected.
Add an ifdef and register to the of platform only if of is available.
Fixes: 985954ccbd ("kernel: add ath10k support for of_get_mac_address")
Signed-off-by: Ansuel Smith <ansuelsmth@gmail.com>
ath10k doesn't currently support the standard function to get mac-address from the dts.
Add this for both ath10k and ath10k-ct
Signed-off-by: Ansuel Smith <ansuelsmth@gmail.com>
Use of WPA3 and things like FILS is getting much more common, and platforms
that can't affort the extra kilobytes for this code are fading away.
Let's not hold back modern authentication methods any longer
Signed-off-by: Felix Fietkau <nbd@nbd.name>
We need to skip sampling if the next sample time is after jiffies, not before.
This patch fixes an issue where in some cases only very little sampling (or none
at all) is performed, leading to really bad data rates
Signed-off-by: Felix Fietkau <nbd@nbd.name>
The removed patches were integrated upstream.
The brcmf_driver_work workqueue was removed in brcmfmac with kernel
5.10.42, the asynchronous call was covered to a synchronous call. There
is no need to wait any more.
This part was removed manually from this patch:
brcm/860-brcmfmac-register-wiphy-s-during-module_init.patch
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
The ath patch number is already large and adding other patch for ath11k
will add more confusion with the patch numbering.
Since the support of ath11k based device is imminent, prepare the mac80211
ath patch dir and split it in the dedicated ath5k, ath9k, ath10k and ath11k
(empty for now).
Signed-off-by: Ansuel Smith <ansuelsmth@gmail.com>
From the patch series description:
Several security issues in the 802.11 implementations were found by
Mathy Vanhoef (New York University Abu Dhabi), who has published all
the details at
https://papers.mathyvanhoef.com/usenix2021.pdf
Specifically, the following CVEs were assigned:
* CVE-2020-24586 - Fragmentation cache not cleared on reconnection
* CVE-2020-24587 - Reassembling fragments encrypted under different
keys
* CVE-2020-24588 - Accepting non-SPP A-MSDU frames, which leads to
payload being parsed as an L2 frame under an
A-MSDU bit toggling attack
* CVE-2020-26139 - Forwarding EAPOL from unauthenticated sender
* CVE-2020-26140 - Accepting plaintext data frames in protected
networks
* CVE-2020-26141 - Not verifying TKIP MIC of fragmented frames
* CVE-2020-26142 - Processing fragmented frames as full frames
* CVE-2020-26143 - Accepting fragmented plaintext frames in
protected networks
* CVE-2020-26144 - Always accepting unencrypted A-MSDU frames that
start with RFC1042 header with EAPOL ethertype
* CVE-2020-26145 - Accepting plaintext broadcast fragments as full
frames
* CVE-2020-26146 - Reassembling encrypted fragments with non-consecutive
packet numbers
* CVE-2020-26147 - Reassembling mixed encrypted/plaintext fragments
In general, the scope of these attacks is that they may allow an
attacker to
* inject L2 frames that they can more or less control (depending on the
vulnerability and attack method) into an otherwise protected network;
* exfiltrate (some) network data under certain conditions, this is
specific to the fragmentation issues.
A subset of these issues is known to apply to the Linux IEEE 802.11
implementation (mac80211). Where it is affected, the attached patches
fix the issues, even if not all of them reference the exact CVE IDs.
In addition, driver and/or firmware updates may be necessary, as well
as potentially more fixes to mac80211, depending on how drivers are
using it.
Specifically, for Intel devices, firmware needs to be updated to the
most recently released versions (which was done without any reference
to the security issues) to address some of the vulnerabilities.
To have a single set of patches, I'm also including patches for the
ath10k and ath11k drivers here.
We currently don't have information about how other drivers are, if
at all, affected.
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Missing braces in a macro were leading to badly working rates sometimes
getting a success probabilty of 1.0
Signed-off-by: Felix Fietkau <nbd@nbd.name>
When transmitting to a receiver in dynamic SMPS mode, all transmissions that
use multiple spatial streams need to be sent using CTS-to-self or RTS/CTS to
give the receiver's extra chains some time to wake up.
This fixes the tx rate getting stuck at <= MCS7 for some clients, especially
Intel ones, which make aggressive use of SMPS.
Signed-off-by: Felix Fietkau <nbd@nbd.name>
On hardware that supports this, this will improve performance by passing
802.3 frames from the hardware to the stack
Signed-off-by: Felix Fietkau <nbd@nbd.name>
The removed patches were applied upstream.
This adapts ath10k-ct and mt76 to changed APIs.
nl80211.h in iw is updated to match the version from backports.
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
The removed patches were applied upstream.
Remove the 300-mac80211-optimize-skb-resizing.patch.
This patch was not applied upstream, but it conflicts with upstream
changes and needs bigger changes. It was applied with Felix to remove
this patch for now. It should be reworked and then send upstream later.
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
If the driver uses .sta_add, station entries are only uploaded after the sta
is in assoc state. Fix early station rate table updates by deferring them
until the sta has been uploaded
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Enable support for the Ubiquiti UniFi Outdoor+ RF filter via
device-tree. The old way of using platform data is not required anymore,
as it was only used on the now removed ar71xx target.
Signed-off-by: David Bauer <mail@david-bauer.net>
Legacy minstrel is essentially unmaintained and was showing poor performance
Replace it with minstrel_ht and improve rate selection and sampling behavior
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Remove deferred sampling code which does not work well with rate tables +
probing.
Fix tx status handling if the first invalid rate idx is not set to -1
Signed-off-by: Felix Fietkau <nbd@nbd.name>
rt2800 olny gives you survey for current channel.
Survey-based ACS algorithms are failing to perform their job when working
with rt2800.
Make rt2800 save survey for every channel visited and be able to give away
that information.
There is a bug registred https://dev.archive.openwrt.org/ticket/19081 and
this patch solves the issue.
Signed-off-by: Markov Mikhail <markov.mikhail@itmh.ru>
After the status rework, ieee80211_tx_status_ext is leaking un-acknowledged
packets for stations in powersave mode.
To fix this, move the code handling those packets from __ieee80211_tx_status
into ieee80211_tx_status_ext
Reported-by: Tobias Waldvogel <tobias.waldvogel@gmail.com>
Signed-off-by: Felix Fietkau <nbd@nbd.name>
The vendor driver does things differently based on what it finds in the
SoC's CHIP_VER register, which should tell whether this is MT7620N or
MT7620A (PKG) and probably also the revision (VER) and most likely
also something about the silicon implementer (ECO).
Introduce codepaths just like the ones in the vendor driver to handle
the different chips properly.
Some of those paths are most likely dead code and left-overs from FPGA
versions or early prototypes of the chip. It'd thus be great if people
can post their kernel logs, at least the line telling the chip version
and eco, so we know what's actually out there in the wild -- all I
could find is
[ 0.000000] SoC Type: Ralink MT7620A ver:2 eco:6
and
[ 0.000000] SoC Type: Ralink MT7620N ver:2 eco:6
which would make things easier, as then we really just need to know
whether it's MT7620N or MT7620A and not care about FPGA or prototypes
with ver <= 1 and eco <= 2.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
When the nulldata frame was acked, the probe send count needs to be reset,
otherwise it will keep increasing until the connection is considered dead,
even though it fine.
Reported-by: Georgi Valkov <gvalkov@abv.bg>
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Minor cleanup and code reorganization, along with a change to not disable
offload anymore when a tkip or sw crypto key is added
Signed-off-by: Felix Fietkau <nbd@nbd.name>
mac80211 reports a packet loss event to user space when 50 consecutive packets
were not acked. On a high throughput link with long aggregates and sudden
link changes, this can trigger way too easily.
Mitigate false positives by only triggering the event on a packet loss if
no ACK was received for at least a second
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Exchange the patch fixing the kernel ringbuffer WARNING flood for the
one accepted upstream.
Fixes commit a956c14d6a ("mac80211: util: don't warn on missing sband
iftype data")
Signed-off-by: David Bauer <mail@david-bauer.net>
The kernel currently floods the ringbuffer with warnings when adding a
mesh interface for a device not support HE 6GHz modes.
Return without warning in this case, as mesh_add_he_6ghz_cap_ie calls
ieee80211_ie_build_he_6ghz_cap regardless of the supported interface
modes.
Signed-off-by: David Bauer <mail@david-bauer.net>
The following patches:
* 972-ath10k_fix-crash-due-to-wrong-handling-of-peer_bw_rxnss_override-parameter.patch
* 973-ath10k_fix-band_center_freq-handling-for-VHT160-in-recent-firmwares.patch
are replaced by this commit in the upstream kernel:
* 3db24065c2c8 ("ath10k: enable VHT160 and VHT80+80 modes")
The following patches were applied upstream:
* 001-rt2800-enable-MFP-support-unconditionally.patch
* 090-wireless-Use-linux-stddef.h-instead-of-stddef.h.patch
The rtw88 driver is now split into multiple kernel modules, just put it
all into one OpenWrt kernel package.
rtl8812au-ct was patched to compile against the mac80211 from kernel
5.8, but not runtime tested.
Add a patch which fixes ath10k on IPQ40XX, this patch was send upstream
and fixes a crash when loading ath10k on this SoC.
Tested-by: Stefan Lippers-Hollmann <s.l-h@gmx.de> [ipq40xx/ map-ac2200]
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Make sure RF5592 is set for RT5592 chip which apparently sometimes
doesn't have RF defined (but always comes with RF5592).
This patch was originally submitted on linux-wireless by
Tom Psyborg <pozega.tomislav@gmail.com> but got rejected.
Turns out the patch is actually needed.
Reported-by: Sebastian Gottschall <s.gottschall@dd-wrt.com>
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
ath9k will already fallback on software-crypto for chipsets not
supporting IEEE802.11w (MFP). So advertising MFP is not dependent
on disabling HW crypto for all traffic entirely.
Tested on Sonicwall SonicPoint Ni (AR9132)
Signed-off-by: David Bauer <mail@david-bauer.net>
From: Rui Salvaterra <rsalvaterra@gmail.com>
Date: Mon, 25 May 2020 14:49:07 +0100
Subject: [PATCH] rt2800: enable MFP support unconditionally
This gives us WPA3 support out of the box without having to manually disable
hardware crypto. The driver will fall back to software crypto if the connection
requires management frame protection.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
This fixes the following compile error seen on the mpc85xx target:
CC [M] /linux-mpc85xx_p2020/backports-5.7-rc3-1/drivers/net/wireless/intersil/orinoco/main.o
In file included from /builder/shared-workdir/build/staging_dir/toolchain-powerpc_8540_gcc-8.4.0_musl/include/stddef.h:17,
from /linux-mpc85xx_p2020/backports-5.7-rc3-1/include/uapi/linux/wireless.h:77,
from /linux-mpc85xx_p2020/backports-5.7-rc3-1/include/linux/wireless.h:13,
from /linux-mpc85xx_p2020/backports-5.7-rc3-1/drivers/net/wireless/intersil/orinoco/main.c:89:
/builder/shared-workdir/build/staging_dir/toolchain-powerpc_8540_gcc-8.4.0_musl/include/bits/alltypes.h:106:15: error: conflicting types for 'ptrdiff_t'
typedef _Addr ptrdiff_t;
^~~~~~~~~
In file included from /linux-mpc85xx_p2020/backports-5.7-rc3-1/backport-include/linux/types.h:4,
from ./include/linux/list.h:5,
from /linux-mpc85xx_p2020/backports-5.7-rc3-1/backport-include/linux/list.h:3,
from ./include/linux/module.h:9,
from /linux-mpc85xx_p2020/backports-5.7-rc3-1/backport-include/linux/module.h:3,
from /linux-mpc85xx_p2020/backports-5.7-rc3-1/drivers/net/wireless/intersil/orinoco/main.c:79:
./include/linux/types.h:65:28: note: previous declaration of 'ptrdiff_t' was here
typedef __kernel_ptrdiff_t ptrdiff_t;
^~~~~~~~~
scripts/Makefile.build:265: recipe for target '/linux-mpc85xx_p2020/backports-5.7-rc3-1/drivers/net/wireless/intersil/orinoco/main.o' failed
Fixes: 289c632425 ("mac80211: Update to version 5.7-rc3-1")
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
This updates the mac80211 backport.
The removed patches are already integrated in the upstream version.
The 131-Revert-mac80211-aes-cmac-switch-to-shash-CMAC-driver.patch patch
was manually adapted to the changes in kernel 5.7.
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
This updates the mac80211 backport.
The removed patches are already integrated in the upstream version.
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
This updates the mac80211 backport.
The removed patches are already integrated in the upstream version.
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
This updates the mac80211 backport to the latest minor version.
The removed patch was a backport from the upstream kernel which is now
integrated.
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Before, only frames with a maximum size of 1528 bytes could be
transmitted between two 802.11s nodes.
For batman-adv for instance, which adds its own header to each frame,
we typically need an MTU of at least 1532 bytes to be able to transmit
without fragmentation.
This patch now increases the maxmimum frame size from 1528 to 1656
bytes.
Tested with two ath10k devices in 802.11s mode, as well as with
batman-adv on top of 802.11s with forwarding disabled.
Fix originally found and developed by Ben Greear.
Link: https://github.com/greearb/ath10k-ct/issues/89
Link: 9e5ab25027
Cc: Ben Greear <greearb@candelatech.com>
Signed-off-by: Linus Lüssing <ll@simonwunderlich.de>
Signed-off-by: Sven Eckelmann <sven@narfation.org>
If we know that we have an encrypted link (based on having had
a key configured for TX in the past) then drop all data frames
in the key selection handler if there's no key anymore.
This fixes an issue with mac80211 internal TXQs - there we can
buffer frames for an encrypted link, but then if the key is no
longer there when they're dequeued, the frames are sent without
encryption. This happens if a station is disconnected while the
frames are still on the TXQ.
Detecting that a link should be encrypted based on a first key
having been configured for TX is fine as there are no use cases
for a connection going from with encryption to no encryption.
With extended key IDs, however, there is a case of having a key
configured for only decryption, so we can't just trigger this
behaviour on a key being configured.
Cc: stable@vger.kernel.org
Reported-by: Jouni Malinen <j@w1.fi>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Signed-off-by: David Bauer <mail@david-bauer.net>
The calibration patches for MT7620 unnecessarily export symbols and
populate never accessed function pointers. Remove all that and make
functions static as the only place where each of those functions is
called is within rt2800lib.c.
Also make code more readable by fixing indentation, removing
unnecessary parantheses and simplifying some instructions using
shorthands here and there.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
Do not export static functions, they are anyway not referenced by any
code in a different module.
This fixes the following compile warning:
WARNING: "rt2800_rf_aux_tx0_loopback" [/drivers/net/wireless/ralink/rt2x00/rt2800lib] is a static EXPORT_SYMBOL_GPL
WARNING: "rt2800_write_dc" [/drivers/net/wireless/ralink/rt2x00/rt2800lib] is a static EXPORT_SYMBOL_GPL
WARNING: "rt2800_rf_configstore" [/drivers/net/wireless/ralink/rt2x00/rt2800lib] is a static EXPORT_SYMBOL_GPL
WARNING: "rt2800_do_sqrt_accumulation" [/drivers/net/wireless/ralink/rt2x00/rt2800lib] is a static EXPORT_SYMBOL_GPL
WARNING: "rt2800_rf_configrecover" [/drivers/net/wireless/ralink/rt2x00/rt2800lib] is a static EXPORT_SYMBOL_GPL
WARNING: "rt2800_loft_search" [/drivers/net/wireless/ralink/rt2x00/rt2800lib] is a static EXPORT_SYMBOL_GPL
WARNING: "rt2800_iq_search" [/drivers/net/wireless/ralink/rt2x00/rt2800lib] is a static EXPORT_SYMBOL_GPL
WARNING: "rt2800_setbbptonegenerator" [/drivers/net/wireless/ralink/rt2x00/rt2800lib] is a static EXPORT_SYMBOL_GPL
WARNING: "rt2800_rf_aux_tx1_loopback" [/drivers/net/wireless/ralink/rt2x00/rt2800lib] is a static EXPORT_SYMBOL_GPL
Acked-by: Daniel Golle <daniel@makrotopia.org>
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
On platforms that do not have CONFIG_MTD enabled, loading the
rt2x00lib kernel module fails because it depends on symbols from
the mtd module ("Unknown symbol get_mtd_device_nm").
This commit disables the code that can read the eeprom from mtd if
mtd is not enabled.
Signed-off-by: Sven Over <sp@cedenti.st>
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
ath10k-ct supports the combination to select IBSS (ADHOC) mode and
different beacon intervals together. mac80211 does not like this
combination, but Ben says this is ok, so remove this check.
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
This patch adds 'qca,gpio-mask=<u32>' device tree property to ath9k node.
This optional setting is a hack and should only be used in very special
(and rare) cases when a button or LED is wired to a GPIO pin normally
masked out (due to being one-way etc). Netgear WNDR4300 v2 is one such
example - it uses GPI9 for RFKILL.
See ath9k/reg.h *_GPIO_MASK constants.
Use with caution and expect to see stream of kernel warnings if wrong
mask value is provided.
Signed-off-by: Michal Cieslakiewicz <michal.cieslakiewicz@wp.pl>
These two hacks are no longer necessary as they've
been moved to a special variant of kmod-ath10k-ct.
So, if you have a device suffering from low-memory
situation and getting applications crashes due to
the OOM reaper or kernel panics with ath10k, please
use the "kmod-ath10k-ct-smallbuffers" package from
now on.
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>
This adds a (currently missing) throughput LED trigger for the rt2x00
driver. Previously, LED triggers had to be assigned to the netdev, which
was limited to a single VAP.
Signed-off-by: David Bauer <mail@david-bauer.net>
Tested-by: Christoph Krapp <achterin@googlemail.com>
This update doesn't include:
3b1e0a7bdfee brcmfmac: add support for SAE authentication offload
be898fed355e brcmfmac: send port authorized event for FT-802.1X
due to nl80211 dependencies.
Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
The Owl Loader (named after the codename that Atheros gave
these devices back in the day) has been accepted upstream.
This patch removes the "misc" driver OpenWrt had and adds
the remaining differences against the version that ships
with 5.4-rc1 into a separate "120-owl-loader-compat.patch"
file that can be cut down once AR71XX is being dealt with.
Note: I decided to keep the existing (kmod-)owl-loader
package name around for now. The kernel module file in
the kmod package will be called ath9k_pci_owl_loader.ko
though.
Acked-by: Hauke Mehrtens <hauke@hauke-m.de>
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>
This updates mac80211 to backports based on kernel 5.4-rc8.
The deleted patches were applied upstream.
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
This potentially fixes some issues seen on IBSS
when interfaces go out of range and then re-appear.
Signed-off-by: Koen Vandeputte <koen.vandeputte@ncentric.com>
The skb_get_hash_perturb() function now takes a siphash_key_t instead of
an u32. This was changed in commit 55667441c84f ("net/flow_dissector:
switch to siphash"). Use the correct type in the fq header file
depending on the kernel version.
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Signed-off-by: Stefan Lippers-Hollmann <s.l-h@gmx.de>
The QCA953x only supports 25 MHz refclk, however some OEMs set an
invalid bootstrap value for the REF_CLK option, which would break the
clock detection in ath9k.
Force the QCA953x refclk to 25MHz in ath9k, as this is (according to the
datasheet) the only valid frequency.
Signed-off-by: David Bauer <mail@david-bauer.net>
https://patchwork.kernel.org/patch/11224189/
--
On 2019-10-28 06:07, wbob wrote:
> Hello Roman,
>
> while reading around drivers/net/wireless/ralink/rt2x00/rt2800lib.c
> I stumbled on what I think is an edit of yours made in error in march
> 2017:
>
> https://github.com/torvalds/linux/commit/41977e86#diff-dae5dc10da180f3b055809a48118e18aR5281
>
> RT6352 in line 5281 should not have been introduced as the "else if"
> below line 5291 can then not take effect for a RT6352 device. Another
> possibility is for line 5291 to be not for RT6352, but this seems
> very unlikely. Are you able to clarify still after this substantial time?
>
> 5277: static int rt2800_init_registers(struct rt2x00_dev *rt2x00dev)
> ...
> 5279: } else if (rt2x00_rt(rt2x00dev, RT5390) ||
> 5280: rt2x00_rt(rt2x00dev, RT5392) ||
> 5281: rt2x00_rt(rt2x00dev, RT6352)) {
> ...
> 5291: } else if (rt2x00_rt(rt2x00dev, RT6352)) {
> ...
Hence remove errornous line 5281 to make the driver actually
execute the correct initialization routine for MT7620 chips.
As it was requested by Stanislaw Gruszka remove setting values of
MIMO_PS_CFG and TX_PIN_CFG. MIMO_PS_CFG is responsible for MIMO
power-safe mode (which is disabled), hence we can drop setting it.
TX_PIN_CFG is set correctly in other functions, and as setting this
value breaks some devices, rather don't set it here during init, but
only modify it later on.
Fixes: 41977e86c984 ("rt2x00: add support for MT7620")
Reported-by: wbob <wbob@jify.de>
Reported-by: Roman Yeryomin <roman@advem.lv>
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
Acked-by: Stanislaw Gruszka <sgruszka@redhat.com>
--
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
This updates mac80211 to backports based on kernel 5.4-rc2
ath10k-ct was updated to match the API changes and iw now uses the new
nl80211.h header file.
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
In non-ETSI regulatory domains scan is blocked when operating channel
is a DFS channel. For ETSI, however, once DFS channel is marked as
available after the CAC, this channel will remain available (for some
time) even after leaving this channel.
Therefore a scan can be done without any impact on the availability
of the DFS channel as no new CAC is required after the scan.
Enable scan in mac80211 in these cases.
Signed-off-by: Aaron Komisar <aaron.komisar@tandemg.com>
Link: https://lore.kernel.org/r/1570024728-17284-1-git-send-email-aaron.komisar@tandemg.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Stefan Lippers-Hollmann <s.l-h@gmx.de>
This backport fixes high latency (>100ms) on the WiFi link when using a
QCA988x Wave 1 radio. The ath10k-ct driver is not affected by this bug
from my testing, hence why it hasn't been discovered earlier.
Signed-off-by: David Bauer <mail@david-bauer.net>
https://patchwork.kernel.org/patch/11161981/
--
From: Stanislaw Gruszka <sgruszka@redhat.com>
Subject: [PATCH] rt2x00: initialize last_reset
Initialize last_reset variable to INITIAL_JIFFIES, otherwise it is not
possible to test H/W reset for first 5 minutes of system run.
Fixes: e403fa31ed71 ("rt2x00: add restart hw")
Reported-and-tested-by: Jonathan Liu <net147@gmail.com>
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
--
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
This makes brcmfmac use the same wiphy after PCIe reset to help user
space handle corner cases (e.g. firmware crash).
Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
From: Stanislaw Gruszka <sgruszka@redhat.com>
This reverts commit 9ad3b55654455258a9463384edb40077439d879f.
As reported by Sergey:
"I got some problem after upgrade kernel to 5.2 version (debian testing
linux-image-5.2.0-2-amd64). 5Ghz client stopped to see AP.
Some tests with 1metre distance between client-AP: 2.4Ghz -22dBm, for
5Ghz - 53dBm !, for longer distance (8m + walls) 2.4 - 61dBm, 5Ghz not
visible."
It was identified that rx signal level degradation was caused by
9ad3b5565445 ("rt2800: enable TX_PIN_CFG_LNA_PE_ bits per band").
So revert this commit.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
Close cooperation with Lorenzo Bianconi resulted
in these patches which fix all remaining seen issues
when using dynack.
Fix link losses when:
- Late Ack's are not seen or not present
- switching from too low static coverage class to dynack on a live link
These are fixed by setting the Ack Timeout/Slottime to
the max possible value for the currently used channel width when
a new station has been discovered.
When traffic flows, dynack is able to adjust to optimal values
within a few packets received (typically < 1 second)
These changes have been thoroughly tested on ~60 offshore devices
all interconnected using mesh over IBSS and dynack enabled on all.
Distances between devices varied from <100m up to ~35km
Signed-off-by: Koen Vandeputte <koen.vandeputte@ncentric.com>
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
To do not brake HW restart we should keep initialization vectors data.
I assumed that on start the data is already initialized to zeros, but
that not true on some scenarios and we should clear it. So add
additional flag to check if we are under HW restart and clear IV's
data if we are not.
Patch fixes AP mode regression.
Patch pending on linux-wireless and imported from patchwork.
Fixes: 0b2c42ced2 ("mac80211: Update to version 5.2-rc7")
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
This fixes a bug introduced in backports from kernel 5.1 which makes
ath10k crash on QCA9984 when a station connects. The FW sends a airtime
report, but this station is not yet fully registered and a NULL pointer
is used.
Fixes: 0b2c42ced2 ("mac80211: Update to version 5.2-rc7")
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
