If no mcast_rate is set for the wifi-iface then there is no rate_idx (0)
set for the bss. This breaks for example 5GHz meshpoint interfaces because
0 maps to a CCK rate (11Mbit/s).
It must also be avoided that the ath10k-ct internal state for the rates is
not synced with the mac80211 rates state. Otherwise, the user specified
rate (e.g. a wifi-iface mcast_rate for a meshpoint interface) will only be
set on startup. And a short while after that, ath10k-ct specific code in
ath10k_check_apply_special_rates is missing a valid rate in its own
structures and is then recalculating a new default rate. This default rate
is in most situations not the requested rate.
Fixes: a399b60735 ("ath10k/ath10k-ct: support multicast and management rate control")
Drivers with software rate control can directly use the selected multicast
rate for multicast/broadcast frames and the minimal basic rate for
management frames. But drivers with offloaded rate control algorithms must
be informed about such upper layer decisions to configure the
hardware/firmware.
A new BSS_CHANGED_MCAST_RATE is introduced in mac80211 to automatically
inform all drivers. ath10k can detect this event and forward it via WMI to
the driver. The already existing BSS_CHANGED_BASIC_RATES can be used to
select the management rate.
Without the WMI commands, a low rate (not necessarily one from the basic
rates) is used for bcast/mcast/management frames. This means that the
/etc/config/wireless settings basic_rate and mcast_rate would have no
effect on the rates selected by this driver for the mentioned frames.
This backports the TP-Link Archer C50 v4.
We are dropping the following upstream commits. They add support for the
TP-Link recovery-flag which enabled the web-recovery. As they are not
needed for the router to work, we drop them for now.
28cd2ca base-files: sysupgrade: support additional mtd options
1e06482 mtd: add logic for TP-Link ramips recovery magic
6e16dd1234 mt76: update to the latest version
76037756d0 kernel: bump 4.14 to 4.14.94
455bfd1065 kernel: bump 4.9 to 4.9.151
fafd7691e6 opkg: update to latest Git head
e789bd2243 opkg: drop argument from check_signature in opkg.conf
3603c2321d ramips: mt7621: fix 5GHz WiFi LED on ZBT WG3526
7f98cd8d50 odhcpd: fix onlink IA check (FS#2060)
abd0f7995e kmod-sched-cake: bump to latest cake
Compile-tested: ar71xx-{tiny,generic}, ramips-mt7621, x86-64
6f74e269c8 kernel: bump 4.14 to 4.14.87
b2f243394e kernel: bump 4.9 to 4.9.144
2213b20aee kernel: bump 4.14 to 4.14.86
bcd7644007 kernel: bump 4.9 to 4.9.143
d5afaa4114 openvpn: re-add option comp_lzo
629073e86d rpcd: update to latest Git head
1cd945ea22 ramips: fix leds on GL.iNet GL-MT300N-V2
fbadfecbb5 ipq40xx: fix openmesh sysupgrade with tar content out of order
06a20afb34 rules.mk: fix syntax error
d40e90986c rules.mk: add INSTALL_SUID macro
d40de11d1b base-files: fix prerm return value, align with postinst code
cc8e875039 sdk: find kernel modules when KDIR is a symlink
a8b292afe6 uhttpd: update to latest Git head
7a8b75375c uhttpd: support multiple Lua prefixes
fede6df09e uhttpd: update to latest Git head
9671a2d2c8 apm821xx: MBL: load kernel/dtb from SATA 0:1 first
26ebcc88e3 apm821xx: wndr4700: restore sd-card media detection
5337319bdf uclient: update to latest Git head
Compile-tested: ar71xx, ipq40xx, x86-64
Runtime-tested: ar71xx
ath10k-ct uses a rather high number of buffers to communicate with the
QCA/Candelatech firmware. Especially the HTC (host-target-communication)
and HTT (host-target-transport) can take up a lot of memory when data is
transferred over a ath10k wifi link.
Even a 256MB device with three radios can go OOM (while sending to three
devices using UDP unicast/multicast packets) with the default buffer
limits. Unfortunately, this also reduced the maximum 5GHz throughput on an
IPQ40xx device from 494/432 Mbit/s for TCP transfers (download/upload) to
438/343 Mbit/s. These throughput values should still be good enough for a
Freifunk installation. And these changes are already used by ath10k in
OpenWrt 18.06.
bc7abe8729f3 include/kernel-build.mk: fix kernel rebuild on backport patch changes
c99c70e05303 kernel: backport page fragment API changes from 4.10+ to 4.9
ath10k has to switch the regulatory domain when switching the default
country when ATH_USER_REGD is enabled. This is for example important when
switching from country US (FCC) to DE (ETSI). The ath implementation will
use ath_reg_dyn_country_user_allow to check if this is allowed.
Unfortunately, this function always seems to return false to
ath_reg_notifier_apply even when ATH_USER_REGD is enabled. But it must
actually always accept the requests from the user (when ATH_USER_REGD is
enabled) to correctly set the conformance test limits in the ath10k binary
blob.
Not doing it will sometimes allow too high transmit powers on edge channels
for correctly calibrated devices outside their default regulatory domain.
Signed-off-by: Sven Eckelmann <sven.eckelmann@open-mesh.com>
The assignment of the gpio_count and reg_base in ath79_gpio_output_select
takes care that only supported platforms can use ath79_gpio_output_select.
But the rebase of the patches after the last OpenWrt base update
accidentally added an extra check for the SoC which was missing support
soc_is_qca955x().
Boots on QCA955X devices which were using ath79_gpio_output_select stopped
with
Kernel bug detected[#1]:
[...]
Call Trace:
[<803e6174>] ath79_gpio_output_select+0x30/0xe8
[<803ed590>] om5p_acv2_setup+0x24/0x200
[<803e4dc0>] ath79_setup+0x28/0x38
[<80069ac8>] do_one_initcall+0x148/0x1ec
[<803e2cc4>] kernel_init_freeable+0x150/0x208
[<80065218>] kernel_init+0x10/0x114
[<80060878>] ret_from_kernel_thread+0x14/0x1c
Fixes: a22c1d5670 ("Update OpenWrt base")
Signed-off-by: Sven Eckelmann <sven@narfation.org>
Some (possibly broken) bootloaders incorrectly initialize the at8033 phy.
This breaks auto-negotation on these SGMII devices. The mode has therefore
to be set back in to a valid configuration by Linux.
Fixes#911
Using HTTPS breaks the download on Debian Wheezy. The switch was an
unintended side effect of the backport from LEDE.
Also, fix the commit message of the backport patch (mwlwifi is not updated
anymore since the last OpenWrt base upgrade).
Fixes#919
