Changes include:
* Higher maximum transmit power in the 5170-5250 band of the BG
regdomain
* Introduction of the CU regdomain
* Introduction of the 5725-5875 band (short-range devices) in the DE
regdomain
* Introduction of 60 GHz channels 1-4 in the KR regdomain
* Introduction of the 5725-5875 band (short-range devices) in the NL
regdomain
Signed-off-by: Petko Bordjukov <bordjukov@gmail.com>
This reverts commit 31e5ed4152.
I've noticed some weird powersave related issues with this commit.
Revert until they've been fixed.
Signed-off-by: Felix Fietkau <nbd@nbd.name>
To work correctly hostapd requires wireless driver to allow interfaces
removal. It was working with brcmfmac only partially. Firmware for
BCM43602 got some special hack (feature?) that allowed removing all
interfaces by disabling mbss mode. It wasn't working with BCM4366
firmware and remaining interfaces were preventing hostapd from starting
again.
Those patches add support for "interface_remove" firmware method which
works with BCM4366 firmware and they make it finally possible to use
BCM4366 & brcmfmac & multiple interfaces.
Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
This allows gpiolib to re-use ath9k's devicetree node as GPIO
controller.
Example:
ath9k: ath9k@0 {
#gpio-cells = <2>;
gpio-controller;
}
Now the ath9k node can be used just like any other GPIO controller:
gpios = <&ath9k 1 GPIO_ACTIVE_HIGH>;
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
This enables ath9k's built-in GPIO controller for all chip versions
(instead of an explicit whitelist). This also allows us to get rid of
some duplicate code between hw.c and gpio.c because hw.c already
determines the number of GPIOs.
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
This folds 550-ath9k_add_ar9280_gpio_chip.patch into
548-ath9k_enable_gpio_chip.patch because the former patch only extends
code which is introduced in the latter.
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
The PDU length of incoming LLC frames is set to the total skb payload size
in __ieee80211_data_to_8023() of net/wireless/util.c which incorrectly
includes the length of the IEEE 802.11 header.
The resulting LLC frame header has a too large PDU length, causing the
llc_fixup_skb() function of net/llc/llc_input.c to reject the incoming
skb, effectively breaking STP.
Solve the problem by properly substracting the IEEE 802.11 frame header size
from the PDU length, allowing the LLC processor to pick up the incoming
control messages.
Special thanks to Gerry Rozema for tracking down the regression and proposing
a suitable patch.
Fixes FS#24.
References:
https://bugs.lede-project.org/index.php?do=details&task_id=24
Reported-by: Gerry Rozema <gerryr@rozeware.com>
Signed-off-by: Jo-Philipp Wich <jo@mein.io>
- Fix calculation of `$vht_cap` bit field
- Replace wrong reference to `$tx_stbc` variable with proper `$tx_stbc_2by1` one
- Emit proper `RX-STBC-{1,12,123,1234}` tokens for the VHT capability list
See https://dev.openwrt.org/ticket/22535 for reference.
Signed-off-by: Scott Shambarger <devel@shambarger.net>
It turns out most device vendors don't set the correct country code
in their devices' on-flash-EEPROM sections as they apparently rather
provide a complete per-target-market firmware with patched drivers
instead of just setting the country code.
This results in the driver to incorrectly assume the value stored in
the on-flash-EERPOM (usually US or China) being the regulatory domain
inside which the device is being used.
To work around this issue, OpenWrt introduced the ATH_USER_REGD config
variable to decide during build whether or not to allow the user to
override the regulatory domain setting. This option, however, is not
enabled by default and thus ends up being disabled for snapshots builds
and released binaries.
As we know for a long time that most devices got borked regulatory
domain values set in their EEPROMs we should allow our users to respect
their local law (instead of just assume US or China laws).
Note that also the current default has great potential of users not
ever setting their regulatory domain and thus using inapproriate and
potentially illegal frequencies and/or tx-power settings
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
This makes brcmfmac compatible with mac80211 which uses dev_alloc_name
(and so returns -ENFILE on error).
Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
LEDE project seems to be using "LEDE" as its acronym everywhere. To keep
things consistent adjust default wireless SSID.
Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
Acked-by: Jo-Philipp Wich <jo@mein.io>
Acked-by: John Crispin <john@phrozen.org>
Acked-by: Alexander Couzens <lynxis@fe80.eu>
