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]
Gracefully handle cases where the to-be-created wireless interface already
exists on the system which might commonly happen with non-multi-SSID capable
wireless drivers.
This fixes commit 8301e61365 which caused
previously ignored "Too many open files in system (-23)" errors to fail the
wireless setup procedure.
With the updated approach we'll still try recreating the vif after one
second if the first attempt to do so failed with ENFILE but we will now
consider the operation successfull if a second attempt still yields ENFILE
with the requested ifname already existing on the system.
Fixes FS#664, FS#704.
Suggested-by: Vittorio Gambaletta <openwrt@vittgam.net>
Signed-off-by: Jo-Philipp Wich <jo@mein.io>
One of the latest mac80211 updates added sanity checks, requiring the
beacon intervals of all VIFs of the same radio to match. This often broke
AP+11s setups, as these modes use different default intervals, at least in
some configurations (observed on ath9k).
Instead of relying on driver or hostapd defaults, change the scripts to
always explicitly set the beacon interval, defaulting to 100. This also
applies the beacon interval to 11s interfaces, which had been forgotten
before. VIF-specific beacon_int setting is removed from hostapd.sh.
Fixes FS#619.
Signed-off-by: Matthias Schiffer <mschiffer@universe-factory.net>
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]
Make brcmfmac depend on !TARGET_uml.
Technically, brcmfmac could be built for uml because only SDIO support
won't work on that target. However, selectively avoiding the dependency
propagation of !TARGET_uml from kmod-mmc to avoid including a reference
to BRCMFMAC_SDIO doesn't work.
In practice, brcmfmac is completely useless on uml, so let's just
disable it there.
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Apply the !UML dependency to both the symbol and the DEPENDS so there is
no recursive dependency anymore.
Signed-off-by: Jonas Gorski <jonas.gorski@gmail.com>
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>
In the drv_mac80211_setup function, mac80211_interface_cleanup
is called to ask the kernel to delete all existing interfaces
for the phy that is being configured via netlink.
Later in the first function, mac80211_prepare_vif is called to
set up the new interfaces as required.
But sometimes, when mac80211_prepare_vif (and so the relevant
`iw phy x interface add y` command) runs, the kernel might still
be cleaning up the old interface with the same ifname. It usually
takes very few time to do that; possibly a few milliseconds of
sleep in the script after detecting this error condition could be
enough, but the busybox sh does not support sub-second sleep
intervals.
When this happens, iw obviously fails to create the new interface;
and the following message is printed in the system log, followed by
subsequent failure messages from hostapd in case this would have been
an AP interface.
Tue Mar 14 04:21:57 2017 daemon.notice netifd: radio1 (2767): command failed: Too many open files in system (-23)
This was a long-standing issue existing since at least OpenWrt Backfire,
and today I finally managed to debug and (hopefully) solve it.
It was happening very few times on most devices; but it was happening
a lot more frequently on fast platforms with multiple radios, such as
the powerpc-based dual-ath9k-radio tl-wdr4900-v1.
Signed-off-by: Vittorio Gambaletta <openwrt@vittgam.net>
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>
The short log of changes since the 2016-06-10 release is below.
Jouni Malinen (1):
wireless-regdb: Remove DFS requirement for India (IN)
Ryan Mounce (1):
wireless-regdb: Update rules for Australia (AU) and add 60GHz rules
Seth Forshee (2):
wireless-regdb: Update 5 GHz rules for Canada
wireless-regdb: update regulatory.bin based on preceding changes
Signed-off-by: Ryan Mounce <ryan@mounce.com.au>
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>
This is required for default wireless configuration of malta target to
work out of the box again. Fixes "77ece30e: hostapd: Add ability to
specify that that wireless driver supports 802.11ac"
Signed-off-by: Yousong Zhou <yszhou4tech@gmail.com>
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>
Lots of users try random stuff when they encounter any kind of
difficulty. I've had to debug a number of cases where people had enabled
this option for no reason. Hopefully this warning will reduce the number
of useless support cases.
Signed-off-by: Felix Fietkau <nbd@nbd.name>
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>
Some debugging/error messages are printed using wpa_printf and this
change allows finally reading them out of the syslog.
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>
TI wl18xx and wl12xx are Wi-Fi/Bluetooth combo modules
that could be found on different existing boards.
But it is possible to get those modules as a separate
component and use with existing boards as well as
new boards equipped with either module may appear so we
remove dependency on OMAP instead we add dependency on MMC
because this Wi-Fi module uses SDIO interface.
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
Cc: Jo-Philipp Wich <jo@mein.io>
Cc: Felix Fietkau <nbd@nbd.name>
Cc: Imre Kaloz <kaloz@openwrt.org>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.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>
Currently, the wifi detection script is executed as part of
the (early) boot process. Pluggable wifi USB devices, which
are inserted at a later time are not automatically
detected and therefore they don't show up in LuCI.
A user has to deal with wifi detection manually, or restart
the router.
However, the current "sleep 1" window - which the boot
process waits for wifi devices to "settle down" - is too
short to detect wifi devices for some routers anyway.
For example, this can happen with USB WLAN devices on the
WNDR4700. This is because the usb controller needs to load
its firmware from UBI and initialize, before it can operate.
The issue can be seen on a BT HomeHub 5A as well as soon as
the caldata are on an ubi volume. This is because the ath9k
card has to be initialized by owl-loader first. Which has to
wait for the firmware extraction script to retrieve the pci
initialization values inside the caldata.
This patch moves the wifi configuration to hotplug scripts.
For mac80211, the wifi configuration will now automatically
run any time a "ieee80211" device is added. Likewise
broadcom-wl's script checks for new "net" devices which
have the "wl$NUMBER" moniker.
Issues with spawning multiple interface configuration - in
case the detection script is run concurrently - have been
resolved by using a named section for the initial
configuration. Concurrent configuration scripts will now
simply overwrite the same existing configuration.
A workaround which preserves the "sleep 1" window for just
the first boot has been added. This allows the existing
brcm47xx boot and mvebu uci-default scripts to correctly
setup the initial mac addresses and regulatory domain.
And finally, the patch renames the "wifi detect" into
"wifi config". As the script no longer produces any output
that has to be redirected or appended to the configuration
file.
Thanks to Martin Blumenstingl for helping with the implementation
and testing of the patch.
Acked-by: Jo-Philipp Wich <jo@mein.io>
Signed-off-by: Mathias Kresin <dev@kresin.me>
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Previously, wifi detect simply dumped its generated wireless
configuration to STDOUT. A second step was needed to append
the configuration to /etc/config/wireless (or create it, if
it didn't exist).
With this patch, The wifi detection script will now use uci
to update the wireless configuration directly.
This patch also makes the initially created wifi-iface a
named section ('default_radio$X' for mac80211 and
'default_wl$X' for broadcom). With this change, uci will
not print the cfgHASH to STDOUT (which would now corrupt
the wireless configuration). It will also prevent adding
duplicated wifi interface configurations, if the wifi
configuration is run concurrently.
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>
Now that we have firmwares separated and brcm2708 being the only target that
actually selects SDIO support, avoid selecting all firmwares by default.
sunxi should select the proper firmwares once SDIO support is enabled and
tested.
Signed-off-by: Álvaro Fernández Rojas <noltari@gmail.com>
Using few packages will allow saving some space by decreasing rootfs
size.
Moreover there are more firmware files that may require packaging and
even more to come later.
This can especially useful now, with per device rootfs.
Signed-off-by: Álvaro Fernández Rojas <noltari@gmail.com>
Now we have firmwares separated and bcm53xx selecting required ones make
use of it to actually save that rootfs space.
Other targets using brcmfmac (brcm2708 and sunxi) use SDIO interface and
firmware so they don't won't be affected.
Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
Using few packages will allow saving some space by decreasing rootfs
size. Dropping 43602a1 firmware saves 316 580 B. Dropping 4366b1 saves
468 188 B.
Moreover there are more firmware files that may require packaging and
even more to come later (e.g. 4366c0).
This can especially useful now, with per device rootfs.
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>
The ATH9K_STATION_STATISTICS kernel config variable enables some extra
statistics that are useful for debugging (in particular with the airtime
fairness patches enabled). This adds that kernel config when selecting
ath9k debugging.
Signed-off-by: Toke Høiland-Jørgensen <toke@toke.dk>
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
