The following command was run on the configuration:
./scripts/kconfig.pl target/linux/generic/config-4.4 > target/linux/generic/config-4.4-new
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
In kernel v4.4.179 the structure of the scripts/mod/file2alias.c file
changed, this adapts the patch to the changes done in the stable
kernel.
This fixes the following compile problem:
HOSTCC scripts/mod/file2alias.o
scripts/mod/file2alias.c:1199:17: error: expected declaration specifiers or '...' before string constant
ADD_TO_DEVTABLE("fslmc", fsl_mc_device_id, do_fsl_mc_entry);
^
scripts/mod/file2alias.c:1199:26: error: unknown type name 'fsl_mc_device_id'
ADD_TO_DEVTABLE("fslmc", fsl_mc_device_id, do_fsl_mc_entry);
^
scripts/mod/file2alias.c:1199:44: error: expected declaration specifiers or '...' before 'do_fsl_mc_entry'
ADD_TO_DEVTABLE("fslmc", fsl_mc_device_id, do_fsl_mc_entry);
^
scripts/mod/file2alias.c:1190:12: warning: 'do_fsl_mc_entry' defined but not used [-Wunused-function]
static int do_fsl_mc_entry(const char *filename, void *symval,
^
SHIPPED scripts/dtc/dtc-parser.tab.h
Fixes: 6c5c3a2edc ("kernel: Update to version 4.4.182")
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
This reverts a commit added in kernel v4.4.179 which breaks compilation
on the apm821xx target.
This fixes the following compile problem:
drivers/crypto/amcc/crypto4xx_core.c: In function 'crypto4xx_ablkcipher_done':
drivers/crypto/amcc/crypto4xx_core.c:650:21: warning: dereferencing 'void *' pointer
if (pd_uinfo->sa_va->sa_command_0.bf.save_iv == SA_SAVE_IV) {
^
drivers/crypto/amcc/crypto4xx_core.c:650:21: error: request for member 'sa_command_0' in something not a structure or union
drivers/crypto/amcc/crypto4xx_core.c:651:38: error: implicit declaration of function 'crypto_skcipher_reqtfm' [-Werror=implicit-function-declaration]
struct crypto_skcipher *skcipher = crypto_skcipher_reqtfm(req);
^
drivers/crypto/amcc/crypto4xx_core.c:651:61: error: 'req' undeclared (first use in this function)
struct crypto_skcipher *skcipher = crypto_skcipher_reqtfm(req);
^
drivers/crypto/amcc/crypto4xx_core.c:651:61: note: each undeclared identifier is reported only once for each function it appears in
drivers/crypto/amcc/crypto4xx_core.c:653:3: error: implicit declaration of function 'crypto4xx_memcpy_from_le32' [-Werror=implicit-function-declaration]
crypto4xx_memcpy_from_le32((u32 *)req->iv,
^
drivers/crypto/amcc/crypto4xx_core.c:654:19: warning: dereferencing 'void *' pointer
pd_uinfo->sr_va->save_iv,
^
drivers/crypto/amcc/crypto4xx_core.c:654:19: error: request for member 'save_iv' in something not a structure or union
drivers/crypto/amcc/crypto4xx_core.c:655:4: error: implicit declaration of function 'crypto_skcipher_ivsize' [-Werror=implicit-function-declaration]
crypto_skcipher_ivsize(skcipher));
^
cc1: some warnings being treated as errors
Fixes: 6c5c3a2edc ("kernel: Update to version 4.4.182")
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
In kernel 4.4.182 get_user_pages() does not get the write and force
parameter any more, but one flags parameter with WRITE and FORCE
attributes. This adapts the patches to use the changed API and fixes
the compile problems with the brcm2708 target.
This fixes the following compile problem:
drivers/misc/vc04_services/interface/vchiq_arm/vchiq_arm.c: In function 'dump_phys_mem':
drivers/misc/vc04_services/interface/vchiq_arm/vchiq_arm.c:1501:3: warning: passing argument 7 of 'get_user_pages' from incompatible pointer type [-Wincompatible-pointer-types]
pages, /* pages (array of page pointers) */
^
In file included from drivers/misc/vc04_services/interface/vchiq_arm/vchiq_arm.c:42:0:
include/linux/mm.h:1200:6: note: expected 'struct vm_area_struct **' but argument is of type 'struct page **'
long get_user_pages(struct task_struct *tsk, struct mm_struct *mm,
^
drivers/misc/vc04_services/interface/vchiq_arm/vchiq_arm.c:1495:7: error: too many arguments to function 'get_user_pages'
rc = get_user_pages(current, /* task */
^
In file included from drivers/misc/vc04_services/interface/vchiq_arm/vchiq_arm.c:42:0:
include/linux/mm.h:1200:6: note: declared here
long get_user_pages(struct task_struct *tsk, struct mm_struct *mm,
^
scripts/Makefile.build:277: recipe for target 'drivers/misc/vc04_services/interface/vchiq_arm/vchiq_arm.o' failed
Fixes: 6c5c3a2edc ("kernel: Update to version 4.4.182")
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
RTC (the legacy driver) should not really be used, but seems to crop up
after the kernel update. Fix this by disabling it in the generic config.
Fixes the following build issue seen in arm64 or powerpc64:
ARM JTAG DCC console (HVC_DCC) [N/y/?] n
Virtio console (VIRTIO_CONSOLE) [N/m/y/?] n
Enhanced Real Time Clock Support (legacy PC RTC driver) (RTC) [N/m/y/?] (NEW) aborted!
Console input/output is redirected. Run 'make oldconfig' to update configuration.
scripts/kconfig/Makefile:37: recipe for target 'silentoldconfig' failed
This should fix the build on the arm64/generic and the layerscape/64b
targets.
Fixes: 6c5c3a2edc ("kernel: Update to version 4.4.182")
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
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>
(cherry picked from commit eea538204b)
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>
In the past, the MX60(W)'s recovery images always had problems
with the size restriction and never really worked without manual
intervention. This patch reworks the initramfs, which allows the
device to ease up on the impossible tight kernel size requirements
for the initramfs image.
This new initramfs can be loaded through the MX60(W) U-boot
in the following way:
=> setenv bootargs console=ttyS0,$baudrate
=> tftpboot $meraki_loadaddr meraki_mx60-initramfs-kernel.bin
[...]
Load address: 0x800000
Loading: ################################################ [...]
done
[...]
=> bootm $fileaddr
\## Booting kernel from Legacy Image at 00800000 ...
...
For more information and the latest flashing guide:
please visit the OpenWrt Wiki Page for the MX60(W):
<https://openwrt.org/toh/meraki/mx60#flashing>
Signed-off-by: Chris Blake <chrisrblake93@gmail.com>
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>
(cherry picked from commit 36c19c9f0b)
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>
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 following patch was integrated upstream:
* target/linux/generic/patches-4.4/005-ext4-fix-check-to-prevent-initializing-reserved-inod.patch
This fixes tries to work around the following security problems:
* CVE-2018-3620 L1 Terminal Fault OS, SMM related aspects
* CVE-2018-3646 L1 Terminal Fault Virtualization related aspects
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
This fixes kernel hang when booting on BCM4718A1 (& probably BCM4717A1).
Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
(cherry picked from commit 4c1aa64b4d)
Fixes: aaecfecdcd ("kernel: bump kernel 4.4 to version 4.4.139")
The broken check would detect a newly generated root filesystem as corrupt
under certain circumstances, in some cases actually currupting the it while
trying to handle the error condition.
This is a regression introduced in kernel 4.4.140. The 4.14.y stable series
has already received this fix, while it is still pending for 4.4.y and
4.9.y.
Signed-off-by: Matthias Schiffer <mschiffer@universe-factory.net>
target/linux/ar71xx/patches-4.4/103-MIPS-ath79-fix-register-address-in-ath79_ddr_wb_flus.patch
has been applied upstream; the two deleted brcm2708 patches have been
useless even before (as the second one only reverted the first one).
Signed-off-by: Matthias Schiffer <mschiffer@universe-factory.net>
The WDR4900v1 uses the P1040 SoC, so the device tree pulls in the
definition for the related P1010 SoC. However, the P1040 lacks the
CAAM/SEC4 hardware crypto accelerator which the P1010 device tree
defines. If left defined, this causes the CAAM drivers (if present) to
attempt to use the non-existent device, making various crypto-related
operations (e.g. macsec and ipsec) fail.
This commit overrides the incorrect dt node definition in the included
file.
See also:
- https://bugs.openwrt.org/index.php?do=details&task_id=1262
- https://community.nxp.com/thread/338432#comment-474107
Signed-off-by: Tim Small <tim@seoss.co.uk>
Signed-off-by: Yousong Zhou <yszhou4tech@gmail.com>
(cherry picked from commit e97aaf483c)
The original vendor's driver programmed the dma controller's
AHB HPROT values to enable bufferable, privileged mode. This
along with the "same priorty for both channels" fixes the
freezes according to @takimata, @And.short, that have been
reported on the forum by @ticerex.
Furtheremore, @takimata reported that the patch also improved
the performance of the HDDs considerably:
|<https://forum.lede-project.org/t/wd-mybook-live-duo-two-disks/16195/55>
|It seems your patch unleashed the full power of the SATA port.
|Where I was previously hitting a really hard limit at around
|82 MB/s for reading and 27 MB/s for writing, I am now getting this:
|
|root@OpenWrt:/mnt# time dd if=/dev/zero of=tempfile bs=1M count=1024
|1024+0 records in
|1024+0 records out
|real 0m 13.65s
|user 0m 0.01s
|sys 0m 11.89s
|
|root@OpenWrt:/mnt# time dd if=tempfile of=/dev/null bs=1M count=1024
|1024+0 records in
|1024+0 records out
|real 0m 8.41s
|user 0m 0.01s
|sys 0m 4.70s
|
|This means: 121 MB/s reading and 75 MB/s writing!
|
|[...]
|
|The drive is a WD Green WD10EARX taken from an older MBL Single.
|I repeated the test a few times with even larger files to rule out
|any caching, I'm still seeing the same great performance. OpenWrt is
|now completely on par with the original MBL firmware's performance.
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>
These two patches:
target/linux/ar71xx/patches-4.4/403-mtd_fix_cfi_cmdset_0002_status_check.patch
target/linux/ramips/patches-4.4/0036-mtd-fix-cfi-cmdset-0002-erase-status-check.patch
are replaced by upstream commit 242dbd2b3df ("mtd: cfi_cmdset_0002:
Change erase functions to check chip good only")
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Some NBG6716 do not have ath10k calibration data in flash, only in chip
OTP. To determine if flash has a valid calibration data, the first two
bytes telling the length of the calibration data are checked against the
requested length. If the lengths match, calibration data is valid and
read from flash.
Signed-off-by: Matti Laakso <matti.laakso@outlook.com>
This devices always looses the settings after power loss, nothing is
been saved.
Deactivate building this image till this problem is fixed.
See FS#672
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Newer Linksys boards might come with a Winbond W29N02GV which can be
configured in different ways. Make sure we configure it the same way as
the older chips so everything keeps working.
Signed-off-by: Imre Kaloz <kaloz@openwrt.org>
Switch ports 0..3 are connected to external ports LAN{1..4} in sequence,
switch port 4 is not used, and switch port 5 is connected to the CPU.
The WAN port is attached to the CPU's second network interface; it has no
connection to the internal switch.
Reuse the "Dell TrueMobile 2300" entry, which describes the same mapping.
Signed-off-by: Mirko Parthey <mirko.parthey@web.de>
This moves core router packages to the NAND target, to ensure they are
applied to all images. This change is being done due to an issue found
when flashing the MX60W image, which came without these when built as a
multi image.
Signed-off-by: Chris Blake <chrisrblake93@gmail.com>
(cherry picked from commit d1c3a9485a)
Fix ART offset (make it universal for 8/16 MB versions of the board) and
while at it, include also GPIO setup for h/w watchdog (EM6324QYSP5B).
Fixes: FS#1532
Signed-off-by: Piotr Dymacz <pepe2k@gmail.com>
Fixes "unregister_netdevice: waiting for lo to become free. Usage count = 1"
messages which started appearing since the update to 4.4.103. That
problem was exposed by upstream commit 76da0704507bb ("ipv6: only call
ip6_route_dev_notify() once for NETDEV_UNREGISTER") backported to 4.4.x
branch in 2417da3f4d6bc.
Fixes: 2b664499cd ("kernel: bump 4.4 to 4.4.103 for 17.01")
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
(cherry picked from commit 58f7b5b96c)
Some Ubiquiti U-boot versions, in particular the "U-Boot 1.1.4.2-s956
(Jun 10 2015 - 10:54:50)" found with AirOS 5.6, do not correctly flush the
caches for the whole kernel address range after decompressing the kernel
image, leading to hard to debug boot failures, depending on kernel version
and configuration.
As a workaround, prepend the relocate-kernels loader, which will invalidate
the caches after moving the kernel to the correct load address.
Reported-by: Andreas Ziegler <dev@andreas-ziegler.de>
Signed-off-by: Matthias Schiffer <mschiffer@universe-factory.net>
This is important fix for flash parsing in some corner cases. In case
of TRX subpartition with rootfs being aligned to the flash block size it
was incorrectly registered twice. Detecting & registering it as a
standalone partition was resulting in an incorrect "firmware" partition
size and possibly broken sysupgrade.
It wasn't noticed before because "rootfs" alignment depends on a kernel
size. It can happen though - depending on the configuration and the
kernel size.
Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
(cherry picked from commit f5195e72c0)
Previously, tplink_pharos_check_image() would accept any image with ELF
magic and only non-printable data in the support-list, as in this case the
while-read loop would not run at all. Add the new support-list offset and
ensure an image is only accepted when the model string is actually found.
Signed-off-by: Matthias Schiffer <mschiffer@universe-factory.net>
Switching from kernel 4.4.120 to 4.4.124 introduced a regression in
the genirq code. It was caused by a commit 9d0273bb1c4b6 ("genirq: Use
irqd_get_trigger_type to compare the trigger type for shared IRQs").
On bcm53xx it breaks serial console and results in a flood of:
[ 22.078829] genirq: Flags mismatch irq 18. 00000080 (serial) vs. 00000080 (gpio)
[ 22.086432] genirq: Flags mismatch irq 18. 00000080 (serial) vs. 00000080 (gpio)
[ 22.601150] genirq: Flags mismatch irq 18. 00000080 (serial) vs. 00000080 (gpio)
[ 22.608845] genirq: Flags mismatch irq 18. 00000080 (serial) vs. 00000080 (gpio)
Later in the upstream "linux-4.4.y" branch that commit was reverted and
it was followed by a 4.4.126 release. Until we switch from 4.4.124 to
4.4.126 (or newer), let's backport that reverting commit.
Fixes: bed0ee7cbf ("Kernel: bump 4.4 to 4.4.124 for 17.01")
Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
At least on some devices, LEDs don't work anymore since kernel 4.4.120.
Revert the broken change.
See also: https://www.spinics.net/lists/stable/msg223656.html
Signed-off-by: Matthias Schiffer <mschiffer@universe-factory.net>
Hauke Mehrtens
Rafał Miłecki
Koen Vandeputte
Christian Lamparter
Freddy Leitner
Matthias Schiffer
Tim Small
Matti Laakso
Imre Kaloz
Mirko Parthey
Chris Blake
Etienne Haarsma
Piotr Dymacz
Felix Fietkau
Stijn Segers