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>
Support for the nct6775/6776 hwmon chips, and other compatibles
in the family as well as the Intel on-chip thermal sensors.
Signed-off-by: Philip Prindeville <philipp@redfish-solutions.com>
Intel(R) 82576 is an adapter which supports SR-IOV. Thus the host can
assign Virtual Functions (VFs) to different VMs by the PCI-E Passthrough
(e.g. VFIO for KVM), to gain different advantages (performance, VF to VF
communications, host kernel offload, etc.).
The driver of the passthroughed VFs is the igbvf (igb is NOT
compatible).
This is essential for VM guests, to enable them to utilize this feature.
Signed-off-by: Ye Tao <tydus@hongo.wide.ad.jp>
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>
This is a 3rd party chipset which is not present on all Intel
reference designs, so make it a module rather than baked in (this
will also alleviate conflicts with drivers which also detect some
of the same chipsets).
Signed-off-by: Philip Prindeville <philipp@redfish-solutions.com>
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>
- remove unused code within 500-ar9_vr9.patch
- fixed return of IFX_ERROR (solves SIGSEGV in asterisk at failure)
- align it a bit with 400-falcon.patch
- remove 600-kernel-4.9.patch since changed parts
are removed during cleanup
Signed-off-by: Stefan Koch <stefan.koch10@gmail.com>
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>
This is the standard way we handle this. Please note (it seems) I could
drop few symbols as they are hidden under (disabled) DRM_LEGACY now.
Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
For targets with i2c not built-in this fixes following error:
Package kmod-drm is missing dependencies for the following libraries:
i2c-core.ko
Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
9f02db7 mt76x2: fall back to software crypto for IBSS/Mesh per-sta GTK
4a54ab3 mt7603: fall back to software crypto for IBSS/Mesh per-sta GTK
712b8e8 mac80211: claim RSN IBSS support
Signed-off-by: Felix Fietkau <nbd@nbd.name>
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>
03e44dc mt76x2: remove unnecessary headroom check
cc70498 mt76x2: clarify queue selection field
b056a78 dma: fix endian issue in mt76_dma_get_buf
f020a60 mt7603: support loading the entire EEPROM from OTP
29b08d3 mt7603: fix endian issue in mt7603_mcu_set_timing
dce8aac mt7603: fix endian issue in mt7603_mac_fill_rx
f22273b mt7603: init WTBL entry before setting capabilities
da8e796 mt7603: check wtbl busy status and stop/start tx queues when clearing sta entry
e54add5 mt7603: move napi/tasklet enable/disable outside of the locked section
59ce2b4 mt7603: set tx vif own MAC index (needed for beacons)
93ce124 mt7603: enable beacons for other virtual interfaces
c91e660 mt7603: set secondary beacon time offsets
Signed-off-by: Felix Fietkau <nbd@nbd.name>
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>
Open-code usb_phy_generic_register instead of calling it, since it is
really trivial. Avoid pulling CONFIG_NOP_USB_XCEIV into the kernel
config and add a proper dependency instead
Signed-off-by: Felix Fietkau <nbd@nbd.name>
If ehci platform driver is loaded before the chipidea controller driver,
both are competing for the same IO resources and the generic driver gets
used for the hardware. This results in USB device mode being
unavailable.
Split generic EHCI support code out of kmod-usb2, so that the chipidea
driver can be included without also pulling in the generic one. Also
rework the load order, so that the chipidea driver gets loaded first, in
case both are installed
Signed-off-by: Felix Fietkau <nbd@nbd.name>
