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>
WNDR3400v3 needs GPIO 21 pulled high to enable power to USB ports. Add a
kernel patch to do that.
Signed-off-by: Tuomas Tynkkynen <tuomas.tynkkynen@iki.fi>
(backported from 5dd745588e)
This makes it possible to use the MCP23S08 i/o expander
on x86_64 platforms with linux 4.14.
Signed-off-by: Martin Schiller <ms@dev.tdt.de>
(backported from 17f30bfcf7)
This adds a configuration options which is needed now.
Without this patch the geode build will fail.
Fixes: 4eda2fddf2 ("x86/geode: enable X86_INTEL_LPSS to select PINCTRL")
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
(backported from 0f2787b9ff)
This makes it possible to use the MCP23S08 i/o expander
on geode platforms with linux 4.14.
Signed-off-by: Martin Schiller <ms@dev.tdt.de>
(backported from 4eda2fddf2)
Without UHCI a non-trivial number of machines will have no keyboard
without BIOS assistance.
Add XHCI as well in case there are chipsets which don't support legacy
interfaces, and support PCI OHCI controllers also.
Signed-off-by: Alex Maclean <monkeh@monkeh.net>
(backported from 894a95fa2d)
This really simplifies debugging, if a package is not found or a feed is
not reachable, a proper stderr is printed. Currently it would only say
`_call_manifest` failed.
Signed-off-by: Paul Spooren <mail@aparcar.org>
(backported from ad5c2897ec)
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)
The order of the Ethernet ports were mixed up.
This commit fixes the order to be aligned with the physical layout.
Signed-off-by: Lev <leventelist@gmail.com>
(backported from 3d6f57f3c6)
Since kernel 4.10 commit 61e84623ace3 ("net: centralize net_device
min/max MTU checking"), the range of mtu is [min_mtu, max_mtu], which
is [68, 1500] by default.
It's necessary to set a max_mtu if a mtu > 1500 is supported.
Signed-off-by: Mathias Kresin <dev@kresin.me>
(backported from 5da2c68d00)
Some board vendors actually changed the loader to expect the chip
to come up in 4-address-mode and flipped the ADP bit in the flash
chip's configuration register which makes it come up in 4-address-mode.
Hence it doesn't make sense to avoid switching to 4-address-mode on
those boards but the opposite as otherwise reboot hangs eg. on the
WrtNode2 boards. Fix this by checking the ADP register and only using
SPI_NOR_4B_READ_OP on chips which have ADP==0 (come up in 3-byte mode).
See also datasheet section 7.1.11 Power Up Address Mode (ADP)
Fixes: 22d982ea0 ("ramips: add support for switching between 3-byte and 4-byte addressing on w25q256 flash")
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
(backported from 8796680277)
This adds the build option for UniFi AC Mesh Pro as well as
model detection for it.
The device is a hardware clone of the AC Pro.
- SoC: QCA9563-AL3A (775Mhz)
- RAM: 128MiB
- Flash: 16MiB - dual firmware partitions!
- LAN: 2x 1000M - POE+
- Wireless:
2.4G: QCA9563
5G: UniFi Chip, QCA988X compatible
Signed-off-by: Christoph Krapp <achterin@googlemail.com>
(cherry picked from commit 987b961537)
The WAN LED now shows the link state. It's color is green,
not blue.
Signed-off-by: Martin Weinelt <hexa@darmstadt.ccc.de>
(cherry picked from commit 0411813c6f)
The tar extraction depends on the order in which the files
are added to the tar file. Since the order is not guaranteed
and depends on the host system, the combined mtd write fails
with sysupgrade images built on some systems.
Fix by changing to tar file order independent mtd write.
Fixes: 86e18f6706 ("ipq806x: add support for OpenMesh A42")
Signed-off-by: Marek Lindner <mareklindner@neomailbox.ch>
Signed-off-by: Sven Eckelmann <sven@narfation.org>
The find statement would not return any results if the KDIR_BASE pointed to a
symlink. Ran into this issue due to a custom Kernel/Prepare that was installing
a symlink to the kernel directory.
The extra slash at the end fixes this scenario and does no harm for targets that
have a proper KDIR.
Signed-off-by: Karl Vogel <karl.vogel@gmail.com>
(cherry picked from commit ae980458ab)
This remedies an issue with the MBL Duo if both disks are inserted
and contain OpenWrt. kernel and dtb would be loaded from SATA 1:1
while rootfs (/dev/sda2) would be mounted on SATA 0:1.
Such a mix&match would obviously only work if both OpenWrt versions/
builds are identical, and especially fail after sysupgrade upgraded
the system disk on SATA 0:1.
The fallback to SATA 1:1 needs to be kept for MBL Single (only has
SATA 1:1) and MBL Duo with one disk inserted on SATA 1:1. To speed
up booting in those cases, the unneccesarily doubled "sata init"
will only be called once. (In theory it could be omitted completely
since the on-flash boot script already initializes SATA to load the
on-disk boot script.)
Tested on MBL Duo (all possible combination of disks) and MBL Single
Signed-off-by: Freddy Leitner <hello@square.wf>
Acked-by: Christian Lamparter <chunkeey@gmail.com>
This was not converted to the new, dt-based board name.
Fixes: e90dc8d272 ("apm821xx: convert to device-tree board detection")
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>
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)
This target has been on 4.14 for a long time now.
Remove these leftovers as it interferes with kernel bumping.
Signed-off-by: Koen Vandeputte <koen.vandeputte@ncentric.com>
It's needed to support new devices that use specific pin functions.
Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
(cherry picked from commit 0cf32de17c)
It's required to support devices using adjustable SoC pins for some
specific purpose (e.g. I2C, PWM, UART1).
Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
(cherry picked from commit f00cb94f7c)
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>