Refreshed all patches.
Removed patches because included in upstream:
- 499-mtd-parser-cmdline-Fix-parsing-of-part-names-with-co.patch
- 0071-2-PCI-qcom-Fixed-IPQ806x-PCIE-reset-changes.patch
Compile-tested on: ipq40xx, lantiq/xrx200, x86/64, ipq806x
Runtime-tested on: ipq40xx, lantiq/xrx200, x86/64
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Refreshed all patches.
Removed patches because included in upstream:
- 315-v5.10-usbnet-ipeth-fix-connectivity-with-ios-14.patch
Compile-tested on: ipq40xx, ath79, x86/64
Runtime-tested on: ipq40xx, ath79
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
This fixes tethering with devices using iOS 14. Prior to this patch,
connections to remote endpoints were not possible while data transfers
between the OpenWrt device and the iOS endpoints worked fine.
Signed-off-by: David Bauer <mail@david-bauer.net>
(cherry picked from commit f64496f30f2ef97124dc4e13a48ee0de9d51832e)
Some devices (especially QCA ones) are already using hardcoded partition
names with colons in it. The OpenMesh A62 for example provides following
mtd relevant information via cmdline:
root=31:11 mtdparts=spi0.0:256k(0:SBL1),128k(0:MIBIB),384k(0:QSEE),64k(0:CDT),64k(0:DDRPARAMS),64k(0:APPSBLENV),512k(0:APPSBL),64k(0:ART),64k(custom),64k(0:KEYS),0x002b0000(kernel),0x00c80000(rootfs),15552k(inactive) rootfsname=rootfs rootwait
The change to split only on the last colon between mtd-id and partitions
will cause newpart to see following string for the first partition:
KEYS),0x002b0000(kernel),0x00c80000(rootfs),15552k(inactive)
Such a partition list cannot be parsed and thus the device fails to boot.
Avoid this behavior by making sure that the start of the first part-name
("(") will also be the last byte the mtd-id split algorithm is using for
its colon search.
Fixes: 9c718b5478 ("kernel: bump 4.14 to 4.14.200")
Signed-off-by: Sven Eckelmann <sven@narfation.org>
(backported from commit 223eec7e81f8506592fc89cf79a2f14360f5c57b)
Backport of linux kernel commit 46d6c5a to 4.14 kernel.
netfilter: use actual socket sk rather than skb sk when routing harder
Signed-off-by: Aaron Goodman <aaronjg@stanford.edu>
The test is meant to check the result of the preceding kmalloc()
Signed-off-by: Thibaut VARÈNE <hacks@slashdirt.org>
(cherry picked from commit d0498872ff71a79f0676cfc6b6b547c499bff712)
Make the driver work with recent upstream changes.
Fixes: FS#2632
Ref: https://github.com/openwrt/openwrt/pull/2815
Signed-off-by: John Crispin <john@phrozen.org>
(cherry picked from commit 6786dc26a205da55ec2d9771693cdfb99e756e59)
I meant it to be GPL-2.0-only, as evidenced by the boilerplate.
Signed-off-by: Thibaut VARÈNE <hacks@slashdirt.org>
(cherry picked from commit 6934b20912d308854b7adf63a7098d38bf67d153)
31e99fe3da which introduced this code was unfortunately untested.
This commit fixes a number of issues and works around the fact that in
this particular scheme, the LZO payload may be padded at the end which
will trigger a harmless lzo decompression error.
This commit also disambiguates the debug printks.
Tested-by: Robert Marko <robimarko@gmail.com>
Signed-off-by: Thibaut VARÈNE <hacks@slashdirt.org>
Fixes: 31e99fe3da ("generic: platform/mikrotik: support LZOR encoding")
(cherry picked from commit 2ea481193c1654c9cb42aa0331cdbc4570783e26)
Some newer MikroTik RouterBOARD devices use a new encoding scheme
for their WLAN calibration data. This patch provides support for
decoding this new scheme.
Signed-off-by: Thibaut VARÈNE <hacks@slashdirt.org>
This driver exposes the data encoded in the "hard_config" flash segment
of MikroTik RouterBOARDs devices. It presents the data in a sysfs folder
named "hard_config". The WLAN calibration data is available on demand via
the 'wlan_data' sysfs file in that folder.
This driver permanently allocates a chunk of RAM as large as the
"hard_config" MTD partition (typically 4KB), although it is technically
possible to operate entirely from the MTD device without using a local
buffer (except when requesting WLAN calibration data), at the cost of a
performance penalty.
This driver does not reuse any of the existing code previously found in
routerboot.c.
This driver has been successfully tested on BE (ath79) and LE (ipq40xx
and ramips) hardware.
Tested-by: Roger Pueyo Centelles <roger.pueyo@guifi.net>
Tested-by: Baptiste Jonglez <git@bitsofnetworks.org>
Tested-by: Tobias Schramm <t.schramm@manjaro.org>
Tested-by: Christopher Hill <ch6574@gmail.com>
Signed-off-by: Thibaut VARÈNE <hacks@slashdirt.org>
ar8229 and ar8236 don't allow unknown unicast/multicast frames and
broadcast frames to be flooded to cpu port. This isn't desired behavior
for swconfig as we treat it as a standalone switch.
Current code doesn't enable unicast frame flooding for ar8229 and uses
wrong setup for ar8236. This commit fixes both of them by enabling port
0 flooding for all unknown frames.
Fixes: FS#2848
Signed-off-by: Chuanhong Guo <gch981213@gmail.com>
(cherry picked from commit 47f17b066259589b4a7b4181522321abf0660e18)
Upstream commit dda9f4b9ca ("f2fs: fix to skip verifying block address
for non-regular inode").
On 4.14, attempting to perform operations on a non-regular inode
residing on an f2fs filesystem, such rm-ing a device node, would fail
and lead to a warning / call trace in dmesg. This fix was already
applied to other kernels upstream - including 4.19, from which the patch
was taken.
More info at https://bugzilla.kernel.org/show_bug.cgi?id=202495.
Signed-off-by: Matt Merhar <mattmerhar@protonmail.com>
(cherry picked from commit ee500186a5617dfe80f4b762fd6bd0c38af93d49)
Refreshed all patches and removed upstreamed:
oxnas/001-irqchip-versatile-fpga-Handle-chained-IRQs-properly.patch
oxnas/002-irqchip-versatile-fpga-Apply-clear-mask-earlier.patch
Fixes: CVE-2020-12114 and CVE-2020-11669
Runtime-tested on: qemu-x86-64
Compile-tested on: ath79/generic, x86/64, imx6
Signed-off-by: Petr Štetiar <ynezz@true.cz>
Doing up & down on non-Ethernet devices (e.g. monitor mode interface)
was consuming memory.
Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
(cherry picked from commit ec8e8e2ef0826d82b4dfbd567a073b31dc27b764)
Fixes a significant amount of leaked memory with lots of connections
Ref: PR#2721
Tested-by: Jerome Benoit <jerome.benoit@sap.com> [WRT1900AC v1]
Signed-off-by: Felix Fietkau <nbd@nbd.name>
[removed 4.19 patch during cherry-pick]
Signed-off-by: Petr Štetiar <ynezz@true.cz>
(cherry picked from commit c6c4701def07cd01a1b077cee93f64a9b2e3b5be)
The Atheros AR8327 and AR8337 have (according to their datasheet) a
VLAN table with a maximum of 4096 entries.
Currently, there's a hard limit of 128 VLANs, which is the same as
for most other Atheros switches. Increase this limit only for the
AR83x7 series and modify some shared functions to allow them to work
with a variable max VLAN count.
Signed-off-by: David Bauer <mail@david-bauer.net>
(cherry picked from commit 3f79aaa2979793c054eae2c8b4058c8c7fccdbe7)
This was found by the build bot.
Fixes: db345220b4 ("kernel: bump 4.14 to 4.14.155")
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
(cherry picked from commit 103e49f62e72664ee0d5285007907a75960e8645)
Matthias Schiffer