If both interrupts are set in the current implementation
only the 1st will be handled and the 2nd will be skipped
due to the "if else" condition.
Fix this by using the same approach as done for QCA955x
just below it.
Signed-off-by: Koen Vandeputte <koen.vandeputte@ncentric.com>
If both interrupts are set in the current implementation
only the 1st will be handled and the 2nd will be skipped
due to the "if else" condition.
Fix this by using the same approach as done for QCA955x
just below it.
Signed-off-by: Koen Vandeputte <koen.vandeputte@ncentric.com>
In 555ca422d1 ("ramips: fix D-Link DIR-615 H1 switch port
mapping"), port setup for dir-615-h1 was changed without removing
the old one. This was working as the new one was triggered earlier
than the old one.
(In the meantine, changed sorting during ramips rename patches
actually inversed that order.)
Anyway, just remove the wrong case now.
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
(cherry picked from commit e35e4a996e)
Reuse a device-specific switch port mapping which also applies to the
D-Link DIR-615 H1.
Signed-off-by: Mirko Parthey <mirko.parthey@web.de>
[cherry-pick/rebase]
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
(cherry picked from commit 555ca422d1)
ARC FreeStation5 is present twice in MAC address setup.
>From older commits/changes, it is not possible to reconstruct
the correct choice only by reading the annotations.
Thus, remove the second case and keep the first one, so behavior
stays the same (as nobody seems to have complained about it).
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
(cherry picked from commit ad4eb2241b)
Without this patch, an extra entry appears for AR9287 GPIO
that duplicates WLAN LED but in fact drives nothing:
gpiochip1: GPIOs 502-511, ath9k-phy0:
gpio-502 ( |netgear:blue:wlan ) out hi
gpio-503 ( |netgear:amber:test ) out hi
gpio-504 ( |netgear:green:power ) out lo
gpio-505 ( |rfkill ) in hi
gpio-507 ( |wps ) in hi
gpio-508 ( |reset ) in hi
gpio-510 ( |ath9k-phy0 ) out hi <===!
The pin pointed above is default LED GPIO (8) for AR9287.
For WNR2200 it is not connected anywhere - pin 0 drives blue WLAN
LED instead - but initialization code is missing that information.
This fix calls ap9x_pci_setup_wmac_led_pin() function at device
setup, forcing WLAN LED pin to be 0 and removing redundant entry.
Signed-off-by: Michal Cieslakiewicz <michal.cieslakiewicz@wp.pl>
Refreshed all patches.
Also add a missing symbol for x86 which got used now in this bump.
- ISCSI_IBFT
Compile-tested on: cns3xxx
Runtime-tested on: cns3xxx
Signed-off-by: Koen Vandeputte <koen.vandeputte@ncentric.com>
In commit 6c937df749 ("ar71xx: wpj531: fix GPIOs for LED") wrong GPIO
13 for SIG1/RSS1 LED was commited, the correct GPIO number for this LED
is 12.
It's listed in "Hardware Guide - wpj531 7A06 (02/07/2019)" as GPIO12/RSS1
on the LED header and same GPIO 12 is used in the vendor's SDK as well.
Fixes: 6c937df749 ("ar71xx: wpj531: fix GPIOs for LED")
Signed-off-by: Leon M. George <leon@georgemail.eu>
[commit subject/message facelift]
Signed-off-by: Petr Štetiar <ynezz@true.cz>
(cherry picked from commit c070662980)
The Aerohive HiveAP 121 has the wrong PLL value set for Gigabit speeds,
leading to packet-loss. 10M and 100M work fine.
This commit sets the Gigabit Ethernet PLL value to the correct value,
fixing packet loss.
Confirmed with iperf and floodping.
Signed-off-by: David Bauer <mail@david-bauer.net>
(cherry picked from commit cb49e46a8a)
- add uart rom script address in header of sdma firmware to support
the uart driver of latest kernel working well while old firmware
assume ram script used for uart driver as NXP internal legacy
kernel.
- add multi-fifo SAI/PDM scripts.
Signed-off-by: Koen Vandeputte <koen.vandeputte@ncentric.com>
(cherry picked from commit 819b6345a206ad182dd3c2d786a3d7f04e33f751)
The mt7620 doesn't have a pinmux group named spi_cs1. The cs1 is part
of the "spi refclk" group. The function "spi refclk" enables the second
chip select.
On reset, the pins of the "spi refclk" group are used as reference
clock and GPIO.
Signed-off-by: Mathias Kresin <dev@kresin.me>
(cherry picked from commit 3601c3de23)
The bump to 4.9.181 broke build for bcm2708 and bcm2709. Revert the
offending patch.
The same revert is also queued for the next upstream 4.9.y release.
Signed-off-by: Matthias Schiffer <mschiffer@universe-factory.net>
It's a simple typo in the DNS file, which was pretty serious.
No scripts were working properly. Fix it up.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>
[integrate into openwrt target]
There is a problem with the EA8500, the switch will not work after soft
reboot, the only way to get it working again is to power cycle it
manually.
There are probably several issues in the play, it's quite hard to fix it
without having access to the actual device, so I don't see any other
option now, then revert the offending commit.
Ref: PR#2047
Fixes: FS#2168 ("Switch no longer work after restart on Linksys EA8500")
Reported-by: Adam <424778940z@gmail.com>
Signed-off-by: Petr Štetiar <ynezz@true.cz>
err_free_stats has been deprecated. Replace with err_netdev.
Compile-tested on: mvebu
Runtime-tested on: mvebu
Fixes: f63a1caf22 ("kernel: bump 4.14 to 4.14.125")
Signed-off-by: George Amanakis <gamanakis@gmail.com>
[altered hashes]
Signed-off-by: Koen Vandeputte <koen.vandeputte@ncentric.com>
It's needed for applying some hardware quirks. This fixes:
drivers/net/wireless/broadcom/brcm80211/brcmfmac/dmi.c:60:20: error: 'DMI_PRODUCT_SKU' undeclared here (not in a function); did you mean 'DMI_PRODUCT_UUID'?
DMI_EXACT_MATCH(DMI_PRODUCT_SKU, "T8"),
Fixes: 2cd234d96b ("mac80211: brcm: backport remaining brcmfmac 5.2 patches")
Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
(cherry picked from commit 4d11c4c378)
Memory is allocated with devm_kzalloc() on every page program
and leaks until device is closed (which never happens).
Convert to kzalloc() and handle error paths manually.
Signed-off-by: Mantas Pucka <mantas@8devices.com>
The "bridge allow reception on disabled port" implementation
was broken after these commits:
b765f4be40 ("kernel: bump 4.14 to 4.14.114")
456f486b53 ("kernel: bump 4.9 to 4.9.171")
This leads to issues when for example WDS is used, tied to a bridge:
[ 96.503771] wlan1: send auth to d4:5f:25:eb:09:82 (try 1/3)
[ 96.517956] wlan1: authenticated
[ 96.526209] wlan1: associate with d4:5f:25:eb:09:82 (try 1/3)
[ 97.086156] wlan1: associate with d4:5f:25:eb:09:82 (try 2/3)
[ 97.200919] wlan1: RX AssocResp from d4:5f:25:eb:09:82 (capab=0x11 status=0 aid=1)
[ 97.208706] wlan1: associated
[ 101.312913] wlan1: deauthenticated from d4:5f:25:eb:09:82 (Reason: 2=PREV_AUTH_NOT_VALID)
It seems upstream introduced a new patch, [1]
so we have to reimplement these patches properly:
target/linux/generic/pending-4.9/150-bridge_allow_receiption_on_disabled_port.patch
target/linux/generic/pending-4.14/150-bridge_allow_receiption_on_disabled_port.patch
[1] https://lkml.org/lkml/2019/4/24/1228
Fixes: b765f4be40 ("kernel: bump 4.14 to 4.14.114")
Fixes: 456f486b53 ("kernel: bump 4.9 to 4.9.171")
Signed-off-by: Chen Minqiang <ptpt52@gmail.com>
[updated commit message and title]
Signed-off-by: Koen Vandeputte <koen.vandeputte@ncentric.com>
Rather than wait until the patches hit vanilla and
get backported via the stable kernel, this patch
patches the crypto4xx driver with the latest fixes
from the upstream linux-crypto tree.
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>
