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>
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>
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>
This fixes a patch for the ARC architecture.
This was found by the build bot.
Fixes: 810ee3b84a ("kernel: bump 4.14 to 4.14.104")
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
This fixes a patch for the ARC architecture.
This was found by the build bot.
Fixes: 5183df0dbf ("kernel: bump 4.9 to 4.9.161")
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Refreshed all patches.
New symbols:
- CONFIG_PPC_BARRIER_NOSPEC
- CONFIG_LDISC_AUTOLOAD
Compile-tested on: ar71xx
Runtime-tested on: ar71xx
Signed-off-by: Koen Vandeputte <koen.vandeputte@ncentric.com>
Renaming a netdev-trigger-tracked interface was resulting in an
unbalanced dev_hold().
Example:
> iw phy phy0 interface add foo type __ap
> echo netdev > trigger
> echo foo > device_name
> ip link set foo name bar
> iw dev bar del
[ 237.355366] unregister_netdevice: waiting for bar to become free. Usage count = 1
[ 247.435362] unregister_netdevice: waiting for bar to become free. Usage count = 1
[ 257.545366] unregister_netdevice: waiting for bar to become free. Usage count = 1
Above problem was caused by trigger checking a dev->name which obviously
changes after renaming an interface. It meant missing all further events
including the NETDEV_UNREGISTER which is required for calling dev_put().
This change fixes that by:
1) Comparing device struct *address* for notification-filtering purposes
2) Dropping unneeded NETDEV_CHANGENAME code (no behavior change)
Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
Refreshed all patches.
New symbol added:
- CONFIG_CIFS_ALLOW_INSECURE_LEGACY
Compile-tested on: cns3xxx, imx6
Runtime-tested on: cns3xxx, imx6
Signed-off-by: Koen Vandeputte <koen.vandeputte@ncentric.com>
upstream commit 802b7c06adc7 ("ARM: cns3xxx: Convert PCI to use generic config accessors")
reimplemented cns3xxx_pci_read_config() using pci_generic_config_read32(),
which preserved the property of only doing 32-bit reads.
It also replaced cns3xxx_pci_write_config() with pci_generic_config_write(),
so it changed writes from always being 32 bits to being the actual size,
which works just fine.
Due to:
- The documentation does not mention that only 32 bit access is allowed.
- Writes are already executed using the actual size
- Extensive testing shows that 8b, 16b and 32b reads work as intended
It makes perfectly sense to also swap 32 bit reading in favor of actual size.
Signed-off-by: Koen Vandeputte <koen.vandeputte@ncentric.com>
The WD MyBook Live SquashFS images didn't work anymore due to
a upstream regression in f2fs commit: 0cfe75c5b01199
("f2fs: enhance sanity_check_raw_super() to avoid potential overflows")
that got backported to 4.14.86 and 4.9.144.
by Martin Blumenstingl:
|Treat "block_count" from struct f2fs_super_block as 64-bit little endian
|value in sanity_check_raw_super() because struct f2fs_super_block
|declares "block_count" as "__le64".
|
|This fixes a bug where the superblock validation fails on big endian
|devices with the following error:
| F2FS-fs (sda1): Wrong segment_count / block_count (61439 > 0)
| F2FS-fs (sda1): Can't find valid F2FS filesystem in 1th superblock
| F2FS-fs (sda1): Wrong segment_count / block_count (61439 > 0)
| F2FS-fs (sda1): Can't find valid F2FS filesystem in 2th superblock
|As result of this the partition cannot be mounted.
|
|With this patch applied the superblock validation works fine and the
|partition can be mounted again:
| F2FS-fs (sda1): Mounted with checkpoint version = 7c84
|
|My little endian x86-64 hardware was able to mount the partition without
|this fix.
|To confirm that mounting f2fs filesystems works on big endian machines
|again I tested this on a 32-bit MIPS big endian (lantiq) device.
Hopefully, this will do until Martin's patch moved through upstream
to -stable.
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>
Optimized inlining was disabled by default when gcc 4 was still
relatively new. By now, all gcc versions handle this well and there
seems to be no real reason to keep it x86-only.
Signed-off-by: Felix Fietkau <nbd@nbd.name>
(backported from 1e8882585c)
(rebased patches)
Signed-off-by: Jo-Philipp Wich <jo@mein.io>
Originally, cns3xxx used it's own functions for mapping, reading and writing registers.
Upstream commit 802b7c06adc7 ("ARM: cns3xxx: Convert PCI to use generic config accessors")
removed the internal PCI config write function in favor of the generic one:
cns3xxx_pci_write_config() --> pci_generic_config_write()
cns3xxx_pci_write_config() expected aligned addresses, being produced by cns3xxx_pci_map_bus()
while the generic one pci_generic_config_write() actually expects the real address
as both the function and hardware are capable of byte-aligned writes.
This currently leads to pci_generic_config_write() writing
to the wrong registers on some ocasions.
First issue seen due to this:
- driver ath9k gets loaded
- The driver wants to write value 0xA8 to register PCI_LATENCY_TIMER, located at 0x0D
- cns3xxx_pci_map_bus() aligns the address to 0x0C
- pci_generic_config_write() effectively writes 0xA8 into register 0x0C (CACHE_LINE_SIZE)
This seems to cause some slight instability when certain PCI devices are used.
Another issue example caused by this this is the PCI bus numbering,
where the primary bus is higher than the secondary, which is impossible.
Before:
00:00.0 PCI bridge: Cavium, Inc. Device 3400 (rev 01) (prog-if 00 [Normal decode])
Flags: bus master, fast devsel, latency 0, IRQ 255
Bus: primary=02, secondary=01, subordinate=ff, sec-latency=0
After fix:
00:00.0 PCI bridge: Cavium, Inc. Device 3400 (rev 01) (prog-if 00 [Normal decode])
Flags: bus master, fast devsel, latency 0, IRQ 255
Bus: primary=00, secondary=01, subordinate=02, sec-latency=0
And very likely some more ..
Fix all by omitting the alignment being done in the mapping function.
Signed-off-by: Koen Vandeputte <koen.vandeputte@ncentric.com>
The cache coloring problem on MIPS CPUs was fixed with kernel 4.9.129 of
the kernel 4.9 branch. Activate VDSO support for MIPS again.
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
(backported from 91a71804f8)
kernel upstream commit 9efcaa7c4afba5628f2650a76f69c798f47eeb18 to 4.14
itself a backport of 0f02cfbc3d9e413d450d8d0fd660077c23f67eff has
resolved the cache line issues that led to us disabling VDSO by default
on MIPS.
Remove our force disable patch:
pending-4.14/206-mips-disable-vdso.patch
Signed-off-by: Kevin Darbyshire-Bryant <ldir@darbyshire-bryant.me.uk>
Acked-by: Hauke Mehrtens <hauke@hauke-m.de>
(backported from 8ee7a80d19)
Backport an additional patch from 4.16 for nftables.
This fixes a build problem recently introduced.
Fixes: f57806b56e ("kernel: generic: Fix nftables inet table breakage")
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
(backported from efffba3409)
Commit b7265c59ab ("kernel: backport a series of netfilter cleanup
patches to 4.14") added patch 302-netfilter-nf_tables_inet-don-t-use-
multihook-infrast.patch. That patch switches the netfilter core in the
kernel to use the new native NFPROTO_INET support. Unfortunately, the
new native NFPROTO_INET support does not exist in 4.14 and was not
backported along with this patchset. As such, nftables inet tables never
see any traffic.
As an example the following nft counter rule should increment for every
packet coming into the box, but never will:
nft add table inet foo
nft add chain inet foo bar { type filter hook input priority 0\; }
nft add rule inet foo bar counter
This commit pulls in the required backport patches to add the new
native NFPROTO_INET support, and thus restore nftables inet table
functionality.
Tested on Turris Omnia (mvebu)
Fixes: b7265c59ab ("kernel: backport a series of netfilter cleanup ...")
Signed-off-by: Brett Mastbergen <bmastbergen@untangle.com>
(backported from f57806b56e)
(rebased patches)
Signed-off-by: Jo-Philipp Wich <jo@mein.io>
With a10a204aab ("kernel: make ubi auto-attach check for a tar file
magic") the check for the magic was added without considering a failing
mtd_read(). If the read fails, no check is done and the mount code is
called straight away.
Failing with an error message for such cases seems to me the cleaner way,
as it would allow to spot hidden/workaround issues.
Signed-off-by: Mathias Kresin <dev@kresin.me>
(backported from 3716b5e4e6)
(rebased patches)
Signed-off-by: Jo-Philipp Wich <jo@mein.io>
The first block(s) of the ubi mtd device might be bad. We need to take
care on our own to skip the bad block(s) and read the next one(s).
Don't treat recoverable read errors as fatal and check for the UBI magic
if the data of a block could be recovered using ECC or similar.
Signed-off-by: Mathias Kresin <dev@kresin.me>
(backported from 0ac91d82ed)
(rebased patches)
Signed-off-by: Jo-Philipp Wich <jo@mein.io>
Move the put_mtd_device() called on multiple error conditions to a goto
label to use it later for more error conditions.
The early return on failed open of the mtd device and mismatching mtd
type allows to get rid of one level of indentation. By jumping to the
cleanup code, a refcount bug is fixed for the wrong flash type condition.
While at it, make clear that we only check for the UBI magic if the read
from flash was successful.
Signed-off-by: Mathias Kresin <dev@kresin.me>
(backported from fdf6760cda)
(rebased patches)
Signed-off-by: Jo-Philipp Wich <jo@mein.io>
Newer kernels have a patch that implements compatible functionality
directly. Adjust the attribute of our own patch in preparation for
dropping it later
Signed-off-by: Felix Fietkau <nbd@nbd.name>
(backported from 41a1c1af4b)
There was a bug in ubifs related to the O_TMPFILE. When reapplying
changes after power cut data could be lost. This problem was exposed by
overlayfs and the upstream commit 3a1e819b4e80 ("ovl: store file handle
of lower inode on copy up").
This fixes a regression introduced when switching from 4.9 to 4.14.
Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
(cherry picked from commit c6a1bcac16)
Newer batches of several Mikrotik boards contain this yet-unsupported
flash chip, for instance:
- rb941-2nd (hAP lite)
- rb952ui-5ac2nd (hAP ac lite)
- RBM33G
and probably other Mikrotik boards need this patch as well.
The patch was submitted upstream by Robert Marko: https://patchwork.ozlabs.org/patch/934181/
Closes: FS#1715
Signed-off-by: Baptiste Jonglez <git@bitsofnetworks.org>
Cc: Robert Marko <robimarko@gmail.com>
[Rebased + refreshed on current kernels]
Signed-off-by: Koen Vandeputte <koen.vandeputte@ncentric.com>
