Kernel 6.1 now has fortify_memcpy_chk() and it is causing the following
warning while trying to compile backports:
CC [M] /home/robimarko/Building/AX3600/ipq807x-5.15/build_dir/target-aarch64_cortex-a53_musl/linux-ipq807x_generic/backports-6.1.24/net/wireless/util.o
In file included from ./include/linux/string.h:253,
from /home/robimarko/Building/AX3600/ipq807x-5.15/build_dir/target-aarch64_cortex-a53_musl/linux-ipq807x_generic/backports-6.1.24/backport-include/linux/string.h:3,
from ./include/linux/bitmap.h:11,
from ./include/linux/cpumask.h:12,
from ./include/linux/smp.h:13,
from ./arch/arm64/include/asm/arch_timer.h:18,
from ./arch/arm64/include/asm/timex.h:8,
from ./include/linux/timex.h:67,
from ./include/linux/time32.h:13,
from ./include/linux/time.h:60,
from /home/robimarko/Building/AX3600/ipq807x-5.15/build_dir/target-aarch64_cortex-a53_musl/linux-ipq807x_generic/backports-6.1.24/backport-include/linux/time.h:3,
from ./include/linux/skbuff.h:15,
from /home/robimarko/Building/AX3600/ipq807x-5.15/build_dir/target-aarch64_cortex-a53_musl/linux-ipq807x_generic/backports-6.1.24/backport-include/linux/skbuff.h:3,
from ./include/linux/if_ether.h:19,
from /home/robimarko/Building/AX3600/ipq807x-5.15/build_dir/target-aarch64_cortex-a53_musl/linux-ipq807x_generic/backports-6.1.24/backport-include/linux/if_ether.h:3,
from ./include/linux/etherdevice.h:20,
from /home/robimarko/Building/AX3600/ipq807x-5.15/build_dir/target-aarch64_cortex-a53_musl/linux-ipq807x_generic/backports-6.1.24/backport-include/linux/etherdevice.h:3,
from /home/robimarko/Building/AX3600/ipq807x-5.15/build_dir/target-aarch64_cortex-a53_musl/linux-ipq807x_generic/backports-6.1.24/net/wireless/util.c:12:
In function 'fortify_memcpy_chk',
inlined from 'ieee80211_strip_8023_mesh_hdr' at /home/robimarko/Building/AX3600/ipq807x-5.15/build_dir/target-aarch64_cortex-a53_musl/linux-ipq807x_generic/backports-6.1.24/net/wireless/util.c:590:3:
./include/linux/fortify-string.h:404:25: error: call to '__write_overflow_field' declared with attribute warning: detected write beyond size of field (1st parameter); maybe use struct_group()? [-Werror=attribute-warning]
404 | __write_overflow_field(p_size_field, size);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
cc1: all warnings being treated as errors
This issue was fixed in the final version of
("wifi: mac80211: fix receiving A-MSDU frames on mesh interfaces") that was
merged upstream but we have a older version that is using:
memcpy(&payload.eth.h_dest, mesh_addr, 2 * ETH_ALEN);
instead of:
memcpy(&payload.eth, mesh_addr, 2 * ETH_ALEN);
So, lets just backport the merged version of patch to fix the issue.
Signed-off-by: Robert Marko <robimarko@gmail.com>
That was a workaround for OpenWrt generation of config files. This patch
was used to postpone returning from probe function until loading
firmware and calling register_wiphy().
All of that is not needed anymore thanks to the ieee80211 hotplug.d
script introduced in the commit 5f8f8a3661 ("base-files, mac80211,
broadcom-wl: wifi detection and configuration"). That takes care of
generating /etc/config/wireless entries even if wireless device appears
late in the booting process.
Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
If CPTCFG_BRCMFMAC_SDIO is not used brcmf_of_fwnames is defined but not
used in the case of CONFIG_OF not compiled.
Restrict brcmf_of_fwnames only with CPTCFG_BRCMFMAC_SDIO selected.
Fix compilation warning:
/__w/openwrt/openwrt/openwrt/build_dir/target-x86_64-openwrt-linux-musl_musl/linux-x86_64/backports-6.1.24/drivers/net/wireless/broadcom/brcm80211/brcmfmac/of.h:16:1: error: 'brcmf_of_fwnames' defined but not used [-Werror=unused-function]
16 | brcmf_of_fwnames(struct device *dev, u32 *map_count)
| ^~~~~~~~~~~~~~~~
cc1: all warnings being treated as errors
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Handle error from copy_to_user in read_file_eeprom.
Fix compilarion warning:
/__w/openwrt/openwrt/openwrt/build_dir/target-x86_64-openwrt-linux-musl_musl/linux-x86_64/backports-6.1.24/drivers/net/wireless/ath/ath9k/debug.c: In function 'read_file_eeprom':
/__w/openwrt/openwrt/openwrt/build_dir/target-x86_64-openwrt-linux-musl_musl/linux-x86_64/backports-6.1.24/drivers/net/wireless/ath/ath9k/debug.c:1451:17: error: ignoring return value of 'copy_to_user' declared with attribute 'warn_unused_result' [-Werror=unused-result]
1451 | copy_to_user(user_buf, from, bytes);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
cc1: all warnings being treated as errors
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Synchronize the ath11k backports with the current ath-next tree.
This replaces the 160MHz with the upstreamed one, fixes 6GHz only WIPHY
registration, allows SAR usage on WCN6750 and plenty of REO fixes.
Signed-off-by: Robert Marko <robimarko@gmail.com>
By default both kmod-bcma and kmod-ssb are selected by kmod-b43.
However, only one of both modules is needed for bmips subtargets:
- bcma: bcm6318, bcm6328, bcm6362, bcm63268
- ssb: bcm6358, bcm6368
Signed-off-by: Álvaro Fernández Rojas <noltari@gmail.com>
QCA has finally sent a proper fixup for the 160MHz regression upstream,
so lets use the pending fix which also properly sets center frequency 2
in case 80+80 MHz is used.
Signed-off-by: Robert Marko <robimarko@gmail.com>
Synchronize the ath11k backports with the current ath-next tree.
This replaces the management TLV pending fix with the upstreamed one,
fixes traffic flooding when AP and monitor modes are used at the same time,
fixes QCN9074 always showing -95 dBm for station RSSI in dumps,
fixes potential crash on boot if spectral scan is enabled due to writing to
unitialized memory and adds 11d scan offloading for WCN6750 and WCN6855.
Signed-off-by: Robert Marko <robimarko@gmail.com>
Currently, during initialization ath11k will receive a regulatory event
from the firmware in which it will receive the default regulatory domain
code and accompanying rules list and report those to the kernel.
Then if you try to change the regulatory domain to a different country code
it will do a weird thing in which it will send that to the FW and after
receiving the appropriate regulatory event it will parse the rules.
However, while its parsing there is a weird thing being done, and that is
that new raw rules from FW get intersected with the rules from the default
domain.
This is creating a big issue as the default domain is almost always set to
"US" or just "00" aka world so ath11k will unfairly limit you to the most
restrictive combination of rules based on the default domain and your
desired domain.
For example, in ETSI countries this is causing channels 12 and 13 on 2.4GHz
to not be usable since "US" limits 2.4GHz to 2472MHz instead of 2482MHz
like ETSI countries do.
So, lets do what TIP and even QCA do in their ath11k downstream tree and
completely get rid of the interesection code in ath11k.
Signed-off-by: Robert Marko <robimarko@gmail.com>
Recent ath11k sync introduced a regression causing 80+80 and 160MHz to
stop being advertised and thus not selectable due to the respective feature
flags being cleared.
So, until we get answers upstream to what was the reasoning behind this and
it gets fixed, lets just remove the flag clearing to reanable 160MHz.
Fixes: 789a0bac35 ("mac80211: ath11k: sync with ath-next")
Signed-off-by: Robert Marko <robimarko@gmail.com>
When forwarding is set to 0, frames are typically sent with ttl=1.
Move the ttl decrement check below the check for local receive in order to
fix packet drops.
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Synchronize the ath11k backports with the current ath-next tree.
This brings in actually setting the MU-MIMO parameters in HW and 6GHz
regulatory support along with some minor resource handling fixes.
This allows to easily backport further fixes as cherry picking them has
started requiring manual conflict resolution.
Signed-off-by: Robert Marko <robimarko@gmail.com>
in kernel 5.17, fcd09c90c3c5254b18ef34e30c57c65d34290a84 integrated it
better with thee random framework.
Gives boot time randomness on supported devices.
Signed-off-by: Rosen Penev <rosenp@gmail.com>
The last mac80211 commits did not refresh the patches.
Refresh:
- ath/402-ath_regd_optional.patch
- ath10k/080-ath10k_thermal_config.patch
- ath10k/974-ath10k_add-LED-and-GPIO-controlling-support-for-various-chipsets.patch
- ath9k/551-ath9k_ubnt_uap_plus_hsr.patch
- rt2x00/602-rt2x00-introduce-rt2x00eeprom.patch
Signed-off-by: Nick Hainke <vincent@systemli.org>
This helps bring down rx CPU usage by avoiding calls to the rx handlers in
the slow path. Supports forwarding and local rx, including A-MSDU.
Signed-off-by: Felix Fietkau <nbd@nbd.name>
If a packet has reached its intended destination, it was bumped to the code
that accepts it, without first checking if a mesh_path needs to be created
based on the discovered source.
Fix this by moving the destination address check further down
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Synchronize the ath11k backports with the current ath-next tree.
This backports several memory leak issues, PCI IRQ fixup, peer add locking
fix as well as IPQ5018 support, though IPQ5018 support is unused for now.
This allows to easily backport further fixes as cherry picking them has
started requiring manual conflict resolution.
Signed-off-by: Robert Marko <robimarko@gmail.com>
The standard defines the A-MSDU header length field differently for mesh
compared to other modes. Deal with this accordingly and work around broken
implementations (e.g. ath10k, ath11k).
Signed-off-by: Felix Fietkau <nbd@nbd.name>
This adds missing HE modes to mac80211_prepare_ht_modes.
Previously mesh without wpa_supplicant would be initialized with 802.11g
/NO-HT only, as this method did not parse channel bandwidth for HE
operation.
Signed-off-by: David Bauer <mail@david-bauer.net>
This is the follow up to the PCI support commit now providing support for
AHB variant as well, though currently only for ipq807x as that is only
OpenWrt supported SoC ath11k supports as well.
Currently, we are disabling coldboot calibration on ipq807x as it does not
work, there is a remoteproc bug that makes it come late out of reset so
disable coldboot until that is fixed.
Also, as ath11k is quite memory hungry, we are introducing a config option
to use the limits for 512MB of RAM, similar to what QCA does downstream but
in way simpler and cleaner way so that 512MB save some RAM.
512MB profile is also set as the default for now.
Signed-off-by: Robert Marko <robimarko@gmail.com>
This is a temporary workaround for supporting multiple cards or AHB+PCI.
There is ongoing upstream work to properly support this based of
advertised FW features, but that is still ongoing.
This is only supported on QCN9074 cards due to FW limitation, so HW ID
is checked in order to prevent breaking QCA6390 and other popular cards.
Signed-off-by: Robert Marko <robimarko@gmail.com>
Currently, ath11k will crash the crash if we try to bringup the monitor
mode interface.
Luckily, it has already been fixed upstream, so backport the patches
fixing it.
Fixes: 93ae4353cd ("mac80211: add ath11k PCI support")
Signed-off-by: Robert Marko <robimarko@gmail.com>
brcmsmac needs bcma. bcma is build into the kernel for the other bcm47xx
subtargets, but not for the legacy target because it only uses ssb. We
could build bcma as a module for bcm47xx_legacy, but none of these old
devices uses a wifi card supported by brcsmac.
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
ath11k is the upstream driver for Qualcomm 802.11ax radios, both for the
internal AHB and PCI based cards.
This commit does however only provide PCI support while AHB will follow
but its SoC specific so it will require an OpenWrt target first.
It differs a bit from ath10k as it requires stuff like QRTR, MHI and QMI
helpers.
PCI variant requires qrtr-mhi and mhi-bus which backports do provide,
however we are dropping those in a patch as they will conflict with
support for the AHB variant as that one requires qrtr-smd which in turn
requires RPMSG and GLINK and its not feasable to provide those in
backports as they are really SoC specific.
QRTR and MHI in kernel 5.10 are not usable and backporting the changes
is not easy as they have changed drastically from 5.10 to 5.15 ath11k will
only be available on targets that use kernel 5.15.
Signed-off-by: Robert Marko <robimarko@gmail.com>
When reloading modules and running wifi, a phy can sometimes be renamed
while in the middle of a hotplug call that tries to detect new phys
This can lead to bogus wifi-device sections being created
Signed-off-by: Felix Fietkau <nbd@nbd.name>
hostapd's compile time option CONFIG_IEEE80211N was removed almost 3 years
ago, 80.211n/HT is always included since then.
Noticed because `hostapd -v11n` confusingly returned an error.
See hostapd's commit:
f3bcd69603 "Remove CONFIG_IEEE80211N build option"
Signed-off-by: Andre Heider <a.heider@gmail.com>
Get rid of drivers that are either limited to 802.11b/g or don't even support
cfg80211/mac80211. Most of these are either limited to boards that we don't even
support anymore because of firmware size, or were only used for custom hacks by
a really small number of users in the past.
Let's get rid of those to reduce the maintenance effort and the number of useless
packages
Signed-off-by: Felix Fietkau <nbd@nbd.name>
CONFIG_MAC80211_MESH isn't defined for this package, rendering the patch
useless. Match protecting the access of sta_info.mesh with the very same
define declaring it.
Fixes 45109f69a6 "mac80211: fix compile error when mesh is disabled"
Signed-off-by: Andre Heider <a.heider@gmail.com>
This updates mac80211 to version 5.15.74-1 which is based on kernel
5.15.74.
The removed patches were applied upstream.
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
This makes it clear, which phy a wlan device belongs to and also helps with
telling them apart by including the mode in the ifname.
Preparation for automatically renaming PHYs
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Reported-by: Chad Monroe <chad.monroe@smartrg.com>
Fixes: 590eaaeed5 ("mac80211: fix issues in HE capabilities")
Signed-off-by: Felix Fietkau <nbd@nbd.name>
This mainly affects scanning and beacon parsing, especially with MBSSID enabled
Fixes: CVE-2022-41674
Fixes: CVE-2022-42719
Fixes: CVE-2022-42720
Fixes: CVE-2022-42721
Fixes: CVE-2022-42722
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Enable HE SU beamformee by default
Fix spatial reuse configuration:
- he_spr_sr_control is not a bool for enabling, it contains multiple bits
which disable features that should be disabled by default
- one of the features (PSR) can be enabled through he_spr_psr_enabled
- add option to disable bss color / spatial reuse
Signed-off-by: Felix Fietkau <nbd@nbd.name>
This fixes following compile error seen when
building mac80211 with mesh disabled:
.../backports-5.15.58-1/net/mac80211/agg-rx.c: In function 'ieee80211_send_addba_resp':
...backports-5.15.58-1/net/mac80211/agg-rx.c:255:17: error: 'struct sta_info' has no member named 'mesh'
255 | if (!sta->mesh)
| ^~
sta_info.h shows this item as being optional based on flags:
struct mesh_sta *mesh;
Guard the check to fix this.
Fixes: f96744ba6b ("mac80211: mask nested A-MSDU support for mesh")
Signed-off-by: Koen Vandeputte <koen.vandeputte@citymesh.com>
mac80211 incorrectly processes A-MSDUs contained in A-MPDU frames. This
results in dropped packets and severely impacted throughput.
As a workaround, don't indicate support for A-MSDUs contained in
A-MPDUs. This improves throughput over mesh links by factor 10.
Ref: https://github.com/openwrt/mt76/issues/450
Signed-off-by: David Bauer <mail@david-bauer.net>
The "tx_burst" option which should control the value was
expecting more of a list and hence tx_queue_data2_burst
value wasn't updated.
Yes, it would make sense to have a list for this, the
existing code only updates tx_queue_data2_burst and
not the other tx_queue_data[0134]_burst values.
Signed-off-by: Alberto Martinez-Alvarez <amteza@gmail.com>
(formatted commit message, wrote extra information into commit,
moved tx_burst to existing json_get_vars)
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>
Prevents build errors by ensuring that it is only selected when a wext based
driver that needs it is also selected
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Serge Vasilugin reports:
To improve mt7620 built-in wifi performance some changes:
1. Correct BW20/BW40 switching (see comments with mark (1))
2. Correct TX_SW_CFG1 MAC reg from v3 of vendor driver see
https://gitlab.com/dm38/padavan-ng/-/blob/master/trunk/proprietary/rt_wifi/rtpci/3.0.X.X/mt76x2/chips/rt6352.c#L531
3. Set bbp66 for all chains.
4. US_CYC_CNT init based on Programming guide, default value was 33 (pci),
set chipset bus clock with fallback to cpu clock/3.
5. Don't overwrite default values for mt7620.
6. Correct some typos.
7. Add support for external LNA:
a) RF and BBP regs never be corrected for this mode
b) eLNA is driven the same way as ePA with mt7620's pin PA
but vendor driver explicitly pin PA to gpio mode (for forrect calibration?)
so I'm not sure that request for pa_pin in dts-file will be enough
First 5 changes (really 2) improve performance for boards w/o eLNA/ePA.
Changes 7 add support for eLNA
Configuration w/o eLAN/ePA and with eLNA show results
tx/rx (from router point of view) for each stream:
35-40/30-35 Mbps for HT20
65-70/60-65 Mbps for HT40
Yes. Max results for 2T2R client is 140-145/135-140
with peaks 160/150, It correspond to mediatek driver results.
Boards with ePA untested.
Reported-by: Serge Vasilugin <vasilugin@yandex.ru>
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
Prepare patches for sending upstream by adding patch descriptions
generated from the original OpenWrt commits adding each patch.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
It is common for 802.11ax NICs to support more than just AP mode, which
results in there being a distinct set of HE capabilities for each mode. As
(bad) luck would have it, iw prints out info for each HE mode in sequential
order according to `enum nl80211_iftype`, and AP mode isn't always first.
As a result, the wrong set of HE capabilities can be parsed if an AP NIC
supports station (managed) mode or any other mode preceding AP mode, since
only the first set of HE capabilities printed by iw is parsed from awk's
output.
This has a noticeable impact on beamforming for example, since managed mode
usually doesn't have beamformer capabilities enabled, while AP mode does.
Hostapd won't be set up with the configs to enable beamformer capabilities
in this scenario, causing hostapd to disable beamforming to HE stations
even when it's supported by the AP.
Always parse the correct set of HE capabilities for AP mode to fix this.
This is achieved by trimming all of iw's output prior to the AP mode
capabilities, which ensures that the first set of HE capabilities are
always for AP mode.
Signed-off-by: Sultan Alsawaf <sultan@kerneltoast.com>
Add support for randomly generating a MAC address for a wifi-iface
instance by setting `macaddr` to `random`
When set to `random`, a new locally administered unicast MAC address
is generated and assigned to the iface everytime it is (re-)configured
Signed-off-by: Manas Sambhus <manas.sambhus+github@gmail.com>
Backports upstream fix from 5.19
lockdep complains use of uninitialized spinlock at ieee80211_do_stop() [1],
for commit f856373e2f31ffd3 ("wifi: mac80211: do not wake queues on a vif
that is being stopped") guards clear_bit() using fq.lock even before
fq_init() from ieee80211_txq_setup_flows() initializes this spinlock.
According to discussion [2], Toke was not happy with expanding usage of
fq.lock. Since __ieee80211_wake_txqs() is called under RCU read lock, we
can instead use synchronize_rcu() for flushing ieee80211_wake_txqs().
Signed-off-by: Koen Vandeputte <koen.vandeputte@ncentric.com>
This updates mac80211 to version 5.15.58-1 which is based on kernel
5.15.58.
The removed patches were applied upstream.
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
TechNexion PICO-PI-IMX7D uses BCM4339 Wi-Fi interface in SDIO mode.
Enable SDIO support for imx/cortexa7 to fully support it in images.
Signed-off-by: Lech Perczak <lech.perczak@gmail.com>
The mac80211-hwsim and the Intel iwlwifi driver support ieee80211ax, add
the missing DRIVER_11AX_SUPPORT dependency too.
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
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>
Introduce a new option background_radar to toggle hostapd's background
radar feature. Enabling this allows DFS CAC to run on dedicated radio RF
chains while the radio(s) are otherwise running normal AP activities on
other channels.
As OpenWrt configures hostapd to use a channel list even when a single
channel is configured, using this feature requires a list of channels in
/etc/config/wireless. Alternatively, channel can be set to auto.
Signed-off-by: Stijn Tintel <stijn@linux-ipv6.be>
Acked-by: David Bauer <mail@david-bauer.net>
Enable ath10k offload by default. This improves wireless performance
without requiring user configuration.
This adds ath10k_core to the AUTOLOAD section so that the frame_mode
paramter can be added to /etc/modules.d and passed to the driver.
The frame_mode 2 enables ethernet mode on the firmware/driver.
This parameter is set by passing a different value to the frame_mode
value on kmod insmod.
Link to the original patchset:
https://patchwork.kernel.org/project/linux-wireless/cover/20220516032519.29831-1-ryazanov.s.a@gmail.com/
Signed-off-by: Tiago Gaspar <tiagogaspar8@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>
In case no specific BSS color is configured, set it to a random value.
Signed-off-by: David Bauer <mail@david-bauer.net>
Tested-by: Stijn Tintel <stijn@linux-ipv6.be>
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>
This commit adds the following package compile options.
CONFIG_PACKAGE_RTW88_DEBGUG:
Compile the driver with additional debug logging output
CONFIG_PACKAGE_RTW88_DEBGUGFS:
Add the possibility to map information about the driver rtw88 into
debugfs.
Signed-off-by: Florian Eckert <fe@dev.tdt.de>
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>
When compiling with CONFIG_USE_RFKILL=y, the build fails and mentions that
dependency on kmod-rfkill is missing, which is correct [1]. Add this
dependency to the Makefile.
Depend on +USE_RFKILL and not PACKAGE_kmod-rfkill, because it forces
selection of kmod-rfkill package. Other combinations in DEPENDS like
USE_RFKILL:kmod-rfkill or (+)PACKAGE_kmod-rfkill:kmod-rfkill do not force
selection of kmod-rfkill package.
The kmod-rfkill package itself depends on USE_RFKILL, so with +USE_RFKILL
in kmod-cfg80211 package it is not possible to select wrong combination of
packages.
[1] https://linux-wireless.vger.kernel.narkive.com/m8JY9Iks/cfg80211-depends-on-rfkill-or-not
Signed-off-by: Oldřich Jedlička <oldium.pro@gmail.com>
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>
On systems using brmcfmac (e.g. Raspberry Pi Zero W) without this fix,
the final setup-call:
iw dev wlan0 ibss join ...
fails with returncode 161 and message:
"command failed: Not supported (-95)"
So this patch calls an explicit:
iw dev wlan0 set type ibss
just prior to the 'ibss join' command.
I have tested several ath9k and mt76xx devices
with different revisions: this patch does not harm.
please also apply to stable branch.
Signed-off-by: Bastian Bittorf <bb@npl.de>
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>
