Including linux/interrupt.h in linux/hrtimer.h causes this error message
on PowerPC builds on x86, ARM and MIPS it works:
CC [M] /backports-4.14-rc2-1/compat/main.o
In file included from /backports-4.14-rc2-1/backport-include/linux/printk.h:5:0,
from ./include/linux/kernel.h:13,
from /backports-4.14-rc2-1/backport-include/linux/kernel.h:3,
from ./include/linux/list.h:8,
from /backports-4.14-rc2-1/backport-include/linux/list.h:3,
from ./include/linux/module.h:9,
from /backports-4.14-rc2-1/backport-include/linux/module.h:3,
from /backports-4.14-rc2-1/compat/main.c:1:
./include/linux/ratelimit.h: In function 'ratelimit_state_exit':
./include/linux/ratelimit.h:62:11: error: dereferencing pointer to incomplete type 'struct task_struct'
current->comm, rs->missed);
^
./include/linux/printk.h:279:37: note: in definition of macro 'pr_warning'
printk(KERN_WARNING pr_fmt(fmt), ##__VA_ARGS__)
^
./include/linux/ratelimit.h:61:3: note: in expansion of macro 'pr_warn'
pr_warn("%s: %d output lines suppressed due to ratelimiting\n",
^
The backport of the hrtimer_start() functions needs the
linux/interrupt.h because some parts are defined there. Fix this by
moving the hrtimer_start() backport to the linux/interrupt.h backport
header file.
Fixes: a8f63a0717: ("mac80211: update to backports-4.14-rc2")
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
This updates mac80211 to backprots-4.14-rc2.
This was compile and runtime tested with ath9k, ath10k and b43
with multiple stations and ieee80211w and in different scenarios by many
other people.
To create the backports-4.14-rc2-1.tar.xz use this repository:
https://git.kernel.org/pub/scm/linux/kernel/git/backports/backports.git
from tag v4.14-rc2-1
Then run this:
./gentree.py --git-revision v4.14-rc2 --clean <path to linux repo> ../backports-4.14-rc2-1
This also adapts the ath10k-ct and mt76 driver to the changed cfg80211
APIs and syncs the nl80211.h file in iw with the new version from
backports-4.14-rc2.
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
dev_coredumpm() was added with kernel 4.7, but it is used by iwlwifi.
When the dev coredump framework form compat-wireless is used this is not
a problem because it already contains this, but this is deactivated if
the build system finds out that it is already included in the kernel we
compile against. This option was now activated by the bluetooth driver
btmrvl. Having dev coredump in the kernel adds about 400 bytes to the
lzma compressed kernel for brcm47xx.
This is copied from a more recent backports version to add the
dev_coredumpm() function when the internal core devdump is not used.
Fixes: a5922f6 ("kernel: bluetooth: add marvell sdio bluetooth module")
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
The upstream ath10k driver disables the intermediate softqueues for some
devices. This patch reverts that behaviour and always enables the
softqueues (and associated bufferbloat fixes). We have had reports of people
running this with good results:
https://lists.bufferbloat.net/pipermail/make-wifi-fast/2017-September/001497.html
This also refreshes mac80211 patches.
Signed-off-by: Toke Høiland-Jørgensen <toke@toke.dk>
The flag needs to be cleared for the last packet in the list, not the
first one. Fixes some issues with multicast packet loss for powersave
clients connected to an ath9k AP.
Signed-off-by: Felix Fietkau <nbd@nbd.name>
FCC regulatory rules allow for up to 3 dBi antenna gain. Account for
this in the EEPROM based tx power reduction code.
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Use chanreg and dccal helpers to reduce the size of ePA code.
Signed-off-by: Tomislav Požega <pozega.tomislav@gmail.com>
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
[daniel@makrotopia.org: fixed white-space so patch applies]
Merged upstream in https://patchwork.kernel.org/patch/9572541/, this
patch fixes the OTP offset used by the AR934x and AR955X to properly
enable reading from the OTP.
Signed-off-by: Christian Lamparter <chunkeey@googlemail.com>
Signed-off-by: Chris Blake <chrisrblake93@gmail.com>
Do as the vendor driver does -- however, some devices apparently
patched support for external PA into the driver similar to how it was
done on Rt3352, using EEPROM_NIC_CONF1 rather than EEPROM_NIC_CONF2,
hence we check for both fields. Somehow the vendor driver also no
longer offers the option of only one of the TX paths having an external
PA (which was probably to weird to ever be implemented in practise,
though it doesn't seem like a particularly bad idea to me). Do the same
in rt2x00 and enable support for external PA on both TX paths whenever
it is set for TX0 in EEPROM.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
Import change to make external PA capability consistent with the
vendor driver instead of having the logic inverted.
While at it, apply patches in the same order as they got merged
upstream.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
update RF register 47 and 54 values according to vendor driver
Signed-off-by: Tomislav Požega <pozega.tomislav@gmail.com>
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
[daniel@makrotopia.org: moved changes into a separate patch]
Use register values from init LNA function instead of the ones from
restore LNA function. Apply register values based on rx path
configuration.
Signed-off-by: Tomislav Požega <pozega.tomislav@gmail.com>
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
[daniel@makrotopia.org: moved changes into a separate patch]
Don't setup the default led pin if the ath9k GPIO controller is used
via device tree to prevent collision. In case any of the pins exposed
by the ath9k is used, the phyNtpt trigger needs to be set in userspace.
Signed-off-by: Mathias Kresin <dev@kresin.me>
In case that the atheros device tree binding is used, enable access to
the GPIO chip only if the gpio-controller device tree parameter is used
for the ath9k node.
Signed-off-by: Mathias Kresin <dev@kresin.me>
Unset the default LED gpio pin if the same gpio pin is used by a LED
defined via platform LED. This prevents that the default led trigger
gets assigned to this LED and the GPIO value gets changed on
wifi up/down in case the led is not used for signaling the wifi state.
Signed-off-by: Mathias Kresin <dev@kresin.me>
Some of our local patches have been accepted upstream. And there are
some more relevant changes (mostly for rt2800usb). Import them and
rebase our remaining local patches on top.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
ath10k tries to fetch board id via otp, but that fails for many chips
like QCA988x, QCA9984 etc. Recent commit cc189c0b7f removed the earlier
hack that had allowed QCA radios to work, as that hack was incompatible
with the new wifi chips being introduced to the source tree.
Restore functionality for the existing wifi chips by modifying the
return value of the 'board id via otp' function to a value that is recognised
as a harmless error, so that name evaluation continues by using the board file.
Patch originally suggested by Christian Lamparter in forum discussion.
Signed-off-by: Hannu Nyman <hannu.nyman@iki.fi>
The tx power applied by set_txpower is limited by the CTL (conformance
test limit) entries in the EEPROM. These can change based on the user
configured regulatory domain.
Depending on the EEPROM data this can cause the tx power to become too
limited, if the original regdomain CTLs impose lowr limits than the CTLs
of the user configured regdomain.
To fix this issue, set the initial channel limits without any CTL
restrictions and only apply the CTL at run time when setting the channel
and the real tx power.
Signed-off-by: Felix Fietkau <nbd@nbd.name>
If a device uses the default EEPROM code, typically only the main CTLs
are valid, and they do not apply properly when switching to a different
regulatory domain. If the regdomain deviates from the EEPROM one, force
the world roaming regdomain to ensure that power limits are sane
Signed-off-by: Felix Fietkau <nbd@nbd.name>
This patch enables the ATH10K_AHB support for the QCA4019
devices on the AHB bus.
This patch also removes 936-ath10k_skip_otp_check.patch
because it breaks the AHB device identification.
"Patch is wrong. I find it frustrating OpenWRT/LEDE doesn't
try to work with upstream on ixing these things right."
[1] <https://www.mail-archive.com/ath10k@lists.infradead.org/msg05896.html>
It also limits ath10k memory hunger (This is a problem with 128MiB RAM)
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>
Introduce RT6352 instead of matching against RF7620.
Clean up channel setting rfvals.
Port bandwidth filter calibration.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
So here is another round of improvements for MT7620 WiFi.
This commit fixes a few significant issues related to TX_PWR_CFG_x and
TX_ALC and also makes the code more readable by adding register
descriptions for things added for MT7620 and use the usual bit-field
access macros and the now defined macros instead of plain bit-ops and
magic numbers.
Properly describe EEPROM_TARGET_POWER at word 0x68 (== byte 0xD0) and
thereby fix internal TXALC which would otherwise just read
out-of-bounds of the EEPROM map.
Split-out tx-power/ALC related stuff into an additional function.
Fix VCO calibration, it was carried out properly in the channel
switching but incomplete in the actual VCO calibration function.
Also there is no need to trigger VCO calibration in channel switching,
the VCO calibration function is already being called at this point.
Remove it from channel switching function to avoid redundant code.
The TX power calibration differs significantly from all other
Mediatek/Ralink chips: They finally allow 0.5dB steps stored as 8-bit
values for (almost) each bitrate -- and promptly ran out of space and
for some reason didn't want to change the EEPROM layout. The hence
opted for a scheme of sharing values for some adjecent bitrates and
a highly over-complicated (or obfuscated?) way to populate the
TX_PWR_CFG_x registers with the values stored in the EEPROM.
The code here now looks much less complicated than what you see in the
vendor's driver, however, it does the exact same thing:
bGpwrdeltaMinus is a constant and always TRUE, hence half of the
code was dead. Gpwrdelta is always 0 (rather than using the value read
from the EEPROM). What remains is some very grotesque effort to avoid
0x20, probably some hardware bug related to some misunderstanding of
what a singed 8-bit value is (imagine: if it was a signed 6-bit value
then someone could believe that 0x20 == 0x0). And then they didn't
clean it up once they later on anandonned that whole story of having a
constant offset for 40 MHz channels and just set the offset to be
constant 0 -- there is no effort for avoiding 0x20 for the 20 MHz
values stored in the EEPROM, hence that's probably just a forbidden
value in the EEPROM specs and won't appear anyway...
Anyway, the whole thing felt like solving some college math test
where in the end everything cancels out and the result equals 0 ;)
To make sure that channel bandwidth power compensation really doesn't
need to be taken care of, output a warning when the corresponding
value stored in the EEPROM is non-zero.
Also there is no apparent reason to refrain from initializing RFCSR
register 13, it doesn't fail what-so-ever.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
Effects of the bugs could include memory corruption, tx hangs, kernel
crahes, possibly other things as well
Signed-off-by: Felix Fietkau <nbd@nbd.name>
This commit combines all the changes I've made on my staging tree
into a single commit fixing many issues with our patch for MT7620.
First of all, checkpatch.pl revealed numerous code style issues with
the patch, so fix all the white-space and commets. Also use
usleep_range instead of legacy timing and relax timing for VCO
calibration just like the vendor driver does.
Several line programming registers were commented out in the patch.
Originally this came from the features present but disabled by default
in the vendor's driver (RTMP_TEMPERATURE_CALIBRATION and
ADJUST_POWER_CONSUMPTION_SUPPORT). Remove the dead code for now, it can
easily be re-added if we actually intend to support those features.
Move values from mt7620_freqconfig type into the existing rf_channel
struct, this shouldn't be a new typedef and it is possible to use the
existing struct because rf_channel got 4 32-bit fields, so two of the
8-bit values from mt7620_freqconfig can easily be stored in the same
32-bit field.
Map values such that
Rdiv -> rf1
N -> rf2
K -> rf3[0:7]
D -> rf3[8:15]
Ksd -> rf4
This makes the channel switching logic already look a bit more like
what we are used to in rt2x00... Probably many of the read-modify-write
calls could still be replaced by macros intended for that.
iq calibration seems to be identical to RT5592, so just enable it.
Test shows that this improves things quite a lot, datarates went up
by a couple of megabits when running iperf, signal quality seems jumpy
in the first few seconds once a station connencts, the stabelizes on a
value significantly better than what it was before.
Add description to the patch and reference the original OpenWrt commit
by which it was added.
The patch now passes checkpatch.pl and can thus be discussed with the
upstream authors of the rt2x00 driver.
Funded-by: https://www.kickstarter.com/projects/1327597961/better-support-for-mt7620a-n-in-openwrt-lede/
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
I needed a moment to figure out relation between this patchset and the
nl80211: fix validation of scheduled scan info for wowlan netdetect
It appears nl80211 commit will go on top of brcmfmac changes so it's
safe to backport these patches.
One patch that was excluded is commit 2a2a5d1835b6 ("brcmfmac: add
.update_connect_params() callback") as it depends on missing commit
088e8df82f91 ("cfg80211: Add support to update connection parameters").
Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
The radio would stop communicating completely. This issue was easiest to
trigger on AR913x devices, e.g. the TP-Link TL-WR1043ND, but other
hardware was occasionally affected as well.
The most critical issue was a race condition in disabling/enabling IRQs
between the IRQ handler and the IRQ processing tasklet
Signed-off-by: Felix Fietkau <nbd@nbd.name>
There was a bug in brcmfmac patch that could result in treating random
memory as source of country codes.
Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
This reverts commit c296ba834d.
According to several reports, the issues with the airtime fairness
changes are gone in current versions.
It's time to re-apply the patch now.
Signed-off-by: Felix Fietkau <nbd@nbd.name>
This allows some basic region switching on Netgear R8000. More devices &
codes may be added. Ideally it should be converted into DT info & patch.
Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
This makes use of cfg80211 feature backported & described in
188626f17c ("mac80211: backport cfg80211 support for
ieee80211-freq-limit DT property").
Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
Most mac80211 drivers leave the SMPS field in the HT capabilities
uninitialized (unfortunately defaults to static SMPS), which leads to
some devices limiting themselves to single-stream rates in some modes
(mostly mesh and IBSS).
Signed-off-by: Felix Fietkau <nbd@nbd.name>
This property allows specifying extra limits for wireless device in DT.
For a full documentation see upstream commit b330b25eaabd ("dt-bindings:
document common IEEE 802.11 frequency limit property").
Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
This reverts commit 528f46d082.
After this commit, several users reported stability issues. Revert it
now so it doesn't cause issues for the upcoming release
Signed-off-by: Felix Fietkau <nbd@nbd.name>
An external reset patch for AR955x accidentally led to external reset
being issued twice on AR913x, once before the RTC reset and once after.
This may be causing some stability issues.
Signed-off-by: Felix Fietkau <nbd@nbd.name>
This commit was added to improve reset time on old SoC devices that run
into chip hangs more frequently. However with the more recent addition
of full WMAC reset on these chips, it could be problematic.
Drop this patch to ensure that DMA activity is really stopped before the
chip reset is issued
Signed-off-by: Felix Fietkau <nbd@nbd.name>
This adds a patch that introduces airtime fairness scheduling to ath9k,
which can significantly improve network efficiency in mixed-rate
environments.
Signed-off-by: Toke Høiland-Jørgensen <toke@toke.dk>
Signed-off-by: Felix Fietkau <nbd@nbd.name>
This adds a patch that introduces airtime fairness scheduling to ath9k,
which can significantly improve network efficiency in mixed-rate
environments.
Signed-off-by: Toke Høiland-Jørgensen <toke@toke.dk>
Signed-off-by: Felix Fietkau <nbd@nbd.name>
The patch commit states:
"It's possible to make scanning consume almost arbitrary amounts
of memory, e.g. by sending beacon frames with random BSSIDs at
high rates while somebody is scanning.
Limit the number of BSS table entries we're willing to cache to
1000, limiting maximum memory usage to maybe 4-5MB, but lower
in practice - that would be the case for having both full-sized
beacon and probe response frames for each entry; this seems not
possible in practice, so a limit of 1000 entries will likely be
closer to 0.5 MB."
Signed-off-by: Johannes Berg <johannes.berg@intel.com>"
This patch was added in 4.4.36. But because LEDE backports
cfg80211, mac80211 and the wifi drivers separately, it needs
to be added manually for now. It can be dropped later as it
will be part of the next mac80211 refresh.
Signed-off-by: Christian Lamparter <chunkeey@googlemail.com>
These properties allow overriding the settings from the EEPROM
which indicate whether a band is enabled or not.
Setting this property is only needed when the RF circuit does not
support the 2.4GHz or 5GHz band while it is enabled nevertheless in the
EEPROM.
These patches will be replaced with a future upstream version which
will introduces an ieee80211 device tree property to disable bands.
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
There are two types of swapping the EEPROM data in the ath9k driver.
Before this series one type of swapping could not be used without the
other.
The first type of swapping looks at the "magic bytes" at the start of
the EEPROM data and performs swab16 on the EEPROM contents if needed.
The second type of swapping is EEPROM format specific and swaps
specific fields within the EEPROM itself (swab16, swab32 - depends on
the EEPROM format).
With this series the second part now looks at the EEPMISC register
inside the EEPROM, which uses a bit to indicate if the EEPROM data
is Big Endian (this is also done by the FreeBSD kernel).
This has a nice advantage: currently there are some out-of-tree hacks
(in OpenWrt and LEDE) where the EEPROM has a Big Endian header on a
Big Endian system (= no swab16 is performed) but the EEPROM itself
indicates that it's data is Little Endian. Until now the out-of-tree
code simply did a swab16 before passing the data to ath9k, so ath9k
first did the swab16 - this also enabled the format specific swapping.
These out-of-tree hacks are still working with the new logic, but it
is recommended to remove them. This implementation is based on a
discussion with Arnd Bergmann who raised concerns about the
robustness and portability of the swapping logic in the original OF
support patch review, see [0].
After a second round of patches (= v1 of this series) neither Arnd
Bergmann nor I were really happy with the complexity of the EEPROM
swapping logic. Based on a discussion (see [1] and [2]) we decided
that ath9k should use a defined format (specifying the endianness
of the data - I went with __le16 and __le32) when accessing the
EEPROM fields. A benefit of this is that we enable the EEPMISC based
swapping logic by default, just like the FreeBSD driver, see [3]. On
the devices which I have tested (see below) ath9k now works without
having to specify the "endian_check" field in ath9k_platform_data (or
a similar logic which could provide this via devicetree) as ath9k now
detects the endianness automatically. Only EEPROMs which are mangled
by some out-of-tree code still need the endian_check flag (or one can
simply remove that mangling from the out-of-tree code).
[0] http://www.spinics.net/lists/linux-wireless/msg152634.html
[1] https://marc.info/?l=linux-wireless&m=147250597503174&w=2
[2] https://marc.info/?l=linux-wireless&m=147254388611344&w=2
[3] 50719b56d9/sys/dev/ath/ath_hal/ah_eeprom_9287.c (L351)
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
These patches add support for configuring ath9k based devices via
devicetree. This was tested on PCI(e) based devices. This should work
for AHB based devices as well (adding more AHB specific properties may
still be needed) as soon as the ath79 platform is ready to populate the
ath9k wmac via devicetree.
This patchset was accepted upstream, more information can be found on
the linux-wireless list:
https://www.spinics.net/lists/linux-wireless/msg155474.html
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Without setting the HSR to the selected channel, the WLAN of the UAP
Outdoor+ will exhibit high packet loss in RX.
Based-on-patch-by: Stefan Rompf <stefan@loplof.de>
Signed-off-by: Matthias Schiffer <mschiffer@universe-factory.net>
Backport upstream accepted patch which allows to override the EEPROM
mac address with one from device tree.
Signed-off-by: Mathias Kresin <dev@kresin.me>
The patch 615-rt2x00-fix_20mhz_clk.patch fixes code introduced by
611-rt2x00-rf_vals-rt3352-xtal20.patch and makes the the platform data
property clk_is_20mhz obsolete.
Signed-off-by: Mathias Kresin <dev@kresin.me>
Most of the lantiq devices with ralink wifi have the EEPROM stored
in big endian byte order in flash, but the driver expects the EEPROM to
be in little endian.
Signed-off-by: Mathias Kresin <dev@kresin.me>
The ralink,mtd-eeprom device tree property doesn't require the
ralink,eeprom property to work.
Rework the error handling and user notification as well. Do not log an
error if the mtd-eeprom parameter isn't used. It could be intentional
and should not scare the user.
Check if the number of bytes read from the mtd devices matches the
requested number of bytes.
In case of an mtd read error, give a hint to the user which partition
was tried to read from.
In case everything is fine, notify the user as well.
Signed-off-by: Mathias Kresin <dev@kresin.me>
Call the rt2x00lib_get_eeprom_file_name only once and from the function
where the EEPROM filename is required.
Error only out if an EEPROM file is mandatory. Use the
REQUIRE_EEPROM_FILE bit to determine if it is mandatory.
Do not set the REQUIRE_EEPROM_FILE bit while requesting an EEPROM file.
It should be (and is) set before requesting an EEPROM file.
Do not redirect users to upstream while using a function of a custom
patch.
Signed-off-by: Mathias Kresin <dev@kresin.me>
This reverts commit efd9dec319.
ath10k can take a long time to probe, long enough for netifd to fail to
initialize already configured wireless devices
Signed-off-by: Felix Fietkau <nbd@nbd.name>
LEDE no longer requires all PHYs to be initialized to
create the configuration files during bootup. This patch
removes the now obsolete ath10k patch.
Signed-off-by: Mathias Kresin <dev@kresin.me>
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>
Adds the latest patches from Jes Sorensen for rtl8xxxu, which improve
rtl8732bu, rtl8192eu and rtl8188eu support.
Signed-off-by: Álvaro Fernández Rojas <noltari@gmail.com>
This fixes bug that could cause WARNING on every add_key/del_key call.
It also replaces WARNING with a simple message. They may still occur
e.g. on station going out of range and A-MPDU stall in the firmware.
Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
All these patches are in wireless-drirvers-next. There is support for
hidden SSID, few new devices and many fixes.
Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
power save response frames can go through the old tx path, and the tid
needs to be set for sequence numbers to be assigned correctly.
Signed-off-by: Felix Fietkau <nbd@nbd.name>
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>
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>
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
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
