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>
starting from upstream commit 577b4eb23811 ("ubi: Reject MLC NAND")
it is not allowed to use UBI and UBIFS on a MLC flavoured NAND flash chip. [1]
According to David Oberhollenzer [2]:
The real problem is that on MLC NAND, pages come in pairs.
Multiple voltage levels inside a single, physical memory cell are used to
encode more than one bit. Instead of just having pages that are twice as big,
the flash exposes them as two different pages. Those pages are usually not
ordered sequentially either, but according to a vendor/device specific
pairing scheme.
Within OpenWrt, devices utilizing this type of flash,
combined with UBI(fs) will be bricked when a user upgrades
from 17.01.4 to a newer version as the MLC will be refused.
As these devices are currently advertised as supported by OpenWrt,
we should at least maintain the original state during the lifecycle
of the current releases.
Support can be gracefully ended when a new release-branch is created.
Signed-off-by: Koen Vandeputte <koen.vandeputte@ncentric.com>
Acked-by: Hauke Mehrtens <hauke@hauke-m.e>
[1] https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=v4.14.77&id=577b4eb23811dfc8e38924dc476dbc866be74253
[2] https://lore.kernel.org/patchwork/patch/920344/
Refreshed all patches.
Altered patches:
- 666-Add-support-for-MAP-E-FMRs-mesh-mode.patch
New symbol for arm targets:
- HARDEN_BRANCH_PREDICTOR
Compile-tested on: cns3xxx, imx6, x86_64
Runtime-tested on: cns3xxx, imx6, x86_64
Signed-off-by: Koen Vandeputte <koen.vandeputte@ncentric.com>
Tested-by: Stijn Tintel <stijn@linux-ipv6.be>
Compaction is the only memory management component to form high order (larger
physically contiguous) memory blocks reliably. The page allocator relies on
compaction heavily and the lack of the feature can lead to unexpected OOM
killer invocations for high order memory requests. You shouldn't disable this
option unless there really is a strong reason for it.
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Signed-off-by: Michal Hrusecky <michal.hrusecky@nic.cz>
This fixes regression introduced in kernel 4.14 and makes bcm53xx revert
obsolete.
Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
(cherry picked from commit 43d36606d6)
