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>
The patch 300-ath9k-force-rx_clear-when-disabling-rx.patch broke TX99 support
in ath9k. Fix the patch by only applying rx_clear if TX99 mode is not used.
Signed-off-by: Helmut Schaa <helmut.schaa@googlemail.com>
Enable access to GPIO on Atheros wireless chip AR9280.
Support for 9280 is added to existing 9285/9287 subsystem
because these 3 chips differ only in number of GPIO pins.
Signed-off-by: Michal Cieslakiewicz <michal.cieslakiewicz@wp.pl>
SVN-Revision: 49251
airo requires ISA_DMA_API and
that symbol is only set on some ppc,malta,x86
x86 is probably only platform where that driver is used
fixes buildbot errors on ar71xx,lantiq ...:
airo.ko is missing
Signed-off-by: Dirk Neukirchen <dirkneukirchen@web.de>
SVN-Revision: 49073
The UML target does not have spi support.
This fixes a build problem found by the build bot.
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
SVN-Revision: 49034
This prepares brcmfmac for better country handling and fixes BCM4360
support which was always failing with:
[ 13.249195] brcmfmac: brcmf_pcie_download_fw_nvram: FW failed to initialize
Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
SVN-Revision: 48959
Enable access to GPIO chip and its pins for Atheros AR92xx
wireless devices. For now AR9285 and AR9287 are supported.
Signed-off-by: Michal Cieslakiewicz <michal.cieslakiewicz@wp.pl>
Acked-by: Hartmut Knaack <knaack.h@gmx.de>
SVN-Revision: 48881
Support default state for platform LEDs connected to ath9k device.
Now LEDs are correctly set on or off at ath9k module initialization.
Signed-off-by: Michal Cieslakiewicz <michal.cieslakiewicz@wp.pl>
Acked-by: Hartmut Knaack <knaack.h@gmx.de>
SVN-Revision: 48880
Enable platform-supplied WLAN LED name for ath9k device.
Signed-off-by: Michal Cieslakiewicz <michal.cieslakiewicz@wp.pl>
Acked-by: Hartmut Knaack <knaack.h@gmx.de>
SVN-Revision: 48879
This adds option to build kernel module and firmware packages
for a Marvell 8686 SPI Wireless device
Signed-off-by: Joseph Honold <mozzwald@gmail.com>
SVN-Revision: 48750
It's not really supported yet as it still fails with:
brcmfmac: brcmf_pcie_download_fw_nvram: FW failed to initialize
Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
SVN-Revision: 48640
OpenWrt is often used to develop or test new devices
Some users might want to test and help to improve
this new driver
upstream commit notice 26f1fad29ad973b0fb26a9ca3dcb2a73dde781aa
New driver: rtl8xxxu (mac80211)
This is an alternate driver for a number of Realtek WiFi USB devices,
including RTL8723AU, RTL8188CU, RTL8188RU, RTL8191CU, and RTL8192CU.
It was written from scratch utilizing the Linux mac80211 stack.
After spending months cleaning up the vendor provided rtl8723au
driver, which comes with it's own 802.11 stack included, I decided to
rewrite this driver from the bottom up.
Many thanks to Johannes Berg for 802.11 insights and help and Larry
Finger for help with the vendor driver.
The full git log for the development of this driver can be found here:
git git://git.kernel.org/pub/scm/linux/kernel/git/jes/linux.git
branch rtl8723au-mac80211
This driver is still under development, but has proven to be very
stable for me. It currently supports station mode only. It has support
for OFDM and CCK rates. It does lack certain features found in the
staging driver, such as power management, AMPDU, and 40MHz channel
support. In addition it does not support AD-HOC, AP, and monitor mode
support at this point.
The driver is known to work with the following devices:
Lenovo Yoga (rtl8723au)
TP-Link TL-WN823N (rtl8192cu)
Etekcity 6R (rtl8188cu)
Daffodil LAN03 (rtl8188cu)
Alfa AWUS036NHR (rtl8188ru)
Compile tested only
Signed-off-by: Dirk Neukirchen <dirkneukirchen@web.de>
SVN-Revision: 48104
We don't use Kernel drivers but ucode -16 is
usable on Kernel 4.3+ - with backports and mac80211
this should work on older Kernel versions too.
Intel does not provide a changelog.
Signed-off-by: Dirk Neukirchen <dirkneukirchen@web.de>
SVN-Revision: 48103
The "iw" utility expects the VHT80 to be specified as uppercase "80MHZ",
change the script to reflect that.
Signed-off-by: Jo-Philipp Wich <jow@openwrt.org>
SVN-Revision: 47814
Update dependencies for linux 4.4 and mark as broken where source code
needs updating.
Signed-off-by: Jonas Gorski <jogo@openwrt.org>
SVN-Revision: 47700
compat-wireless/backports now contains a bcm47xx_nvram.h file to
backport some of the functions in it which are used by the bcmfmac
driver. This file just checks for the kernel versions and provide an
empty implementations on older kernel versions. This is OK on most
systems, but on bcm47xx / bcm53xx systems we want to call the real
functions here. This commit removes the file from backports in our
build process like we do it with the bcma and ssb header files. Instead
we add a recent version into our kernel so all code uses only one
header file. On bcm47xx / bcm53xx the real implementations of this code
will be used.
Reported-by: Hante Meuleman <meuleman@broadcom.com>
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
SVN-Revision: 47467
Add a new config option "channels" for mac80211 wifi devices. It's only
valid if automatic channel selection is used and restricts the channel
selection to one of the given channels.
config wifi-device
list channels 1
list channels 6
list channels 11
Signed-off-by: Helmut Schaa <helmut.schaa@googlemail.com>
SVN-Revision: 47427
In order to set the multicast rate for mesh point interfaces the "mesh join"
was made explicit and moved to mac80211_setup_vif(), similar to how it is
done for IBSS interfaces.
Previously, the mesh join was made implicit in case authentication (i.e.
$key) was not used when creating the interface in mac80211_prepare_vif(),
while using authentication would create the interface first, then join
later in mac80211_setup_vif() by starting authsae.
Signed-off-by: Nils Schneider <nils@nilsschneider.net>
SVN-Revision: 47408
llid_in_use needs to be limited to stations of the same VIF, otherwise it
will cause a NULL deref as the sta_info of non-mesh-VIFs don't have
sta->mesh set.
Steps to reproduce:
modprobe mac80211_hwsim channels=2
iw phy phy0 interface add ibss0 type ibss
iw phy phy0 interface add mesh0 type mp
iw phy phy1 interface add ibss1 type ibss
iw phy phy1 interface add mesh1 type mp
ip link set ibss0 up
ip link set mesh0 up
ip link set ibss1 up
ip link set mesh1 up
iw dev ibss0 ibss join foo 2412
iw dev ibss1 ibss join foo 2412
# Ensure that ibss0 and ibss1 are actually associated; I often need to
# leave and join the cell on ibss1 a second time.
iw dev mesh0 mesh join bar
iw dev mesh1 mesh join bar # crash
Signed-off-by: Matthias Schiffer <mschiffer@universe-factory.net>
SVN-Revision: 47364
