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>
