aboutsummaryrefslogtreecommitdiffstats
path: root/target/linux
Commit message (Collapse)AuthorAgeFilesLines
* lantiq: fritz7320: enable USB power supplyMathias Kresin2021-02-181-0/+46
| | | | | | | | | | | | | The USB ports if a FRIZZ!Box 7320 do not supply power to connected devices. Add the GPIOs enabling USB power as regulator, to enable USB power supply as soon as the USB driver is loaded. Fixes FS#3624 Signed-off-by: Mathias Kresin <dev@kresin.me> (cherry picked from commit 6e4e97b2256327bb380ee2a83da9a1ddf657e395)
* kernel: bump 4.14 to 4.14.221Koen Vandeputte2021-02-157-29/+20
| | | | | | | | | | | | Refreshed all patches. Remove upstreamed hunk in: - 302-dts-support-layerscape.patch Compile-tested on: ar71xx, cns3xxx, imx6, x86_64 Runtime-tested on: ar71xx, cns3xxx, imx6 Signed-off-by: Koen Vandeputte <koen.vandeputte@ncentric.com>
* ramips: ethernet: Disable TSO support to improve stabilityBaptiste Jonglez2021-02-151-2/+1
| | | | | | | | | | | | | | | | | | | | | | | Stability of this Ethernet driver has been a long-standing issue, with many people reporting frequent "transmit queue timeouts" and even occasional crashes. Disabling TSO in the driver helps with stability, although it is likely a workaround and might not fix the issue completely. There is a slight slowdown in forwarding performance for TCP packets (75 kpps vs. 80 kpps with comparable CPU utilization), but this is still enough to forward close to 1 Gbit/s of full-sized packets across multiple flows. Master is using a different ethernet driver, so this is not a backport. Because of this different driver, the upcoming 21.02 release does not seem to be affected by these stability issues. Thanks to mrakotiq for the initial patch. Fixes: FS#2628 Signed-off-by: Baptiste Jonglez <git@bitsofnetworks.org>
* ramips: mark toggle input on EX6150 as a switchKurt Roeckx2021-02-151-0/+1
| | | | | | | | | | The Netgear EX6150 has an Access Point/Extender switch. Set it as an EV_SW. Otherwise when it's set to Access Point, it will trigger failsafe mode during boot. Fixes: FS#3590 Signed-off-by: Kurt Roeckx <kurt@roeckx.be> (cherry picked from commit 539966554d6d0686dc8ce62e39ff9e8f4e2d4e74)
* ramips: remove factory image for TP-Link Archer C2 v1Stijn Segers2021-02-141-1/+0
| | | | | | | | | | | | | | | | | | | | Initial commit 8375623a0640 ("ramips: add support for TP-Link Archer C2") contains detailed installation instructions, which do not mention a factory image. From what I can see, no support to install OpenWrt through the vendor web interface has been added since. The factory image is also conspicuously absent from the device page in the wiki. Yet, it is available for download. I bricked my Archer C2 loading the factory image through the web UI. Serial showed this error during bootloop: Uncompressing Kernel Image ... LZMA ERROR 1 - must RESET board to recover This patch disables the undocumented factory image so users won't get tricked into thinking easy web UI flashing actually works. Signed-off-by: Stijn Segers <foss@volatilesystems.org> (backported from commit ad5e29d38a48ce6ffbcabaf5d83bc76a64dfbe56)
* ath79: fix USB power GPIO for TP-Link TL-WR810N v1Adrian Schmutzler2021-02-121-1/+1
| | | | | | | | | | | | | | | | | | | The TP-Link TL-WR810N v1 is known to cause soft-brick on ath79 and work fine for ar71xx [1]. On closer inspection, the only apparent difference is the GPIO used for the USB regulator, which deviates between the two targets. This applies the value from ar71xx to ath79. Tested successfully by a forum user. [1] https://forum.openwrt.org/t/tp-link-tl-wr810n-v1-ath79/48267 Fixes: cdbf2de77768 ("ath79: Add support for TP-Link WR810N") Fixes: FS#3522 Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de> (cherry picked from commit 6934d30cf8d95bc8652b4dcd8180d14e5e8e2417)
* bcm63xx: sprom: override the PCI device IDDaniel González Cabanelas2021-02-072-1/+79
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The PCI device ID detected by the wifi drivers on devices using a fallback SPROM is wrong. Currently the chipnum is used for this parameter. Most SSB based Broadcom wifi chips are 2.4 and 5GHz capable. But on devices without a physical SPROM, the only one way to detect if the device suports both bands or only the 5GHz band, is by reading the device ID from the fallback SPROM. In some devices, this may lead to a non working wifi on a 5GHz-only card, or in the best case a working 2.4GHz-only in a dual band wifi card. The offset for the deviceid in SSB SPROMs is 0x0008, whereas in BCMA is 0x0060. This is true for any SPROM version. Override the PCI device ID with the one defined at the fallback SPROM, to detect the correct wifi card model and allow using the 5GHz band if supported. The patch has been tested with the following wifi radios: BCM43222: b43: both 2.4/5GHz working brcm-wl: both 2.4/5GHz working BCM43225: b43: 2.4GHz, working brcmsmac: working brcm-wl: it lacks support BCM43217: b43: 2.4GHz, working brcmsmac: it lacks support brcm-wl: it lacks support Signed-off-by: Daniel González Cabanelas <dgcbueu@gmail.com> Signed-off-by: Álvaro Fernández Rojas <noltari@gmail.com> Backported from a0e0e621ca
* kernel: bump 4.14 to 4.14.219Koen Vandeputte2021-02-052-2/+2
| | | | | | | | | Refreshed all patches. Compile-tested on: ar71xx, cns3xxx, imx6, x86_64 Runtime-tested on: ar71xx, cns3xxx, imx6 Signed-off-by: Koen Vandeputte <koen.vandeputte@ncentric.com>
* bcm63xx: R5010UNv2: fix flash partitions for 16MB flashDaniel González Cabanelas2021-02-041-5/+5
| | | | | | | | | | | | The router Nucom R5010UN v2 has the partitions defined for a 8MB flash, but the flash chip is 16MB size. We are wasting half of the flash. Fix it and use generic names for partitions. Fixes: 474cde61234c ("brcm63xx: probe SPI flash through DT") Signed-off-by: Daniel González Cabanelas <dgcbueu@gmail.com> (cherry picked from commit cef9e5a49f496b64449fca6814fc1b66a45601c3)
* kernel: bump 4.14 to 4.14.218Koen Vandeputte2021-02-025-9/+9
| | | | | | | | | Refreshed all patches. Compile-tested on: ar71xx, cns3xxx, imx6, x86_64 Runtime-tested on: ar71xx, cns3xxx, imx6 Signed-off-by: Koen Vandeputte <koen.vandeputte@ncentric.com>
* mvebu: omnia: make initramfs image usable out of the boxPetr Štetiar2021-02-021-2/+2
| | | | | | | | | | | | | | | | Currently it's not possible to boot the device with just initramfs image without additional effort as the initramfs image doesn't contain device tree. Fix it by producing FIT based image which could be booted with following commands: setenv bootargs earlyprintk console=ttyS0,115200 tftpboot ${kernel_addr_r} openwrt-mvebu-cortexa9-cznic_turris-omnia-initramfs-kernel.bin bootm ${kernel_addr_r} Acked-by: Klaus Kudielka <klaus.kudielka@gmail.com> Reviewed-by: Tomasz Maciej Nowak <tmn505@gmail.com> Signed-off-by: Petr Štetiar <ynezz@true.cz> (cherry-picked from commit 337ff74894110b35b61118918b7eb30bb6e60756)
* kernel: bump 4.14 to 4.14.217Hauke Mehrtens2021-01-255-11/+11
| | | | | | | | | Refreshed all patches. 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>
* kernel: bump 4.14 to 4.14.216Koen Vandeputte2021-01-212-3/+3
| | | | | | | | | Refreshed all patches. Compile-tested on: ar71xx, cns3xxx, imx6, x86_64 Runtime-tested on: ar71xx, cns3xxx, imx6 Signed-off-by: Koen Vandeputte <koen.vandeputte@ncentric.com>
* kernel: bump 4.14 to 4.14.215Hauke Mehrtens2021-01-172-7/+7
| | | | | | | | | Refreshed all patches. 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>
* kernel: bump 4.14 to 4.14.214Hauke Mehrtens2021-01-1216-176/+30
| | | | | | | | | | | | | 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>
* ath79: image: fix initramfs for safeloader devicesPetr Štetiar2020-12-171-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently it's not possible to tftpboot initramfs image on archer-c7-v5 as the image contains tplink-v1-header which leads to: ath> bootm ## Booting image at 81000000 ... Bad Magic Number as U-Boot expects uImage wrapped image. This is caused by following inheritance issue: define Device/Init KERNEL_INITRAMFS = $$(KERNEL) define Device/tplink-v1 KERNEL := kernel-bin | append-dtb | lzma KERNEL_INITRAMFS := kernel-bin | append-dtb | lzma | tplink-v1-header define Device/tplink-safeloader $(Device/tplink-v1) define Device/tplink-safeloader-uimage $(Device/tplink-safeloader) KERNEL := kernel-bin | append-dtb | lzma | uImageArcher lzma define Device/tplink_archer-c7-v5 $(Device/tplink-safeloader-uimage) where tplink-v1 defines KERNEL_INITRAMFS with tplink-v1-header and it's then used by all devices inheriting from tplink-safeloader. Fix this by overriding KERNEL_INITRAMFS to KERNEL variable again. Signed-off-by: Petr Štetiar <ynezz@true.cz> (cherry picked from commit ceeece9ffaa5a3a336505332c39794d76c08b2ca)
* kernel: bump 4.14 to 4.14.212Hauke Mehrtens2020-12-1616-84/+40
| | | | | | | | | | | | 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>
* ramips: enable LED VCC for Asus RT-AC51UDavide Fioravanti2020-12-101-11/+9
| | | | | | | | | | Previously only the power LED was working. With this patch all leds except 5GHz are working. Signed-off-by: Davide Fioravanti <pantanastyle@gmail.com> [rephrased commit title, drop status property] Signed-off-by: David Bauer <mail@david-bauer.net> (cherry picked from commit 67d019ac94015707926235a3ac0aa6bb12cee8c2)
* generic: ipeth: fix iOS 14 tetheringDavid Bauer2020-12-071-0/+44
| | | | | | | | | 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)
* mvebu: fixup Turris Omnia U-Boot environmentKlaus Kudielka2020-12-041-0/+44
| | | | | | | | | | | | | | | | Fixup dfa357a3de "mvebu: base-files: Update Turris Omnia U-Boot environment" which should have included this file as well. By rebasing the initial patch this file somehow disappeared. Signed-off-by: Klaus Kudielka <klaus.kudielka@gmail.com> Reviewed-by: Tomasz Maciej Nowak <tomek_n@o2.pl> Tested-by: W. Michael Petullo <mike@flyn.org> (Turris Omnia "2020") Tested-by: Klaus Kudielka <klaus.kudielka@gmail.com> (Turris Omnia) [explain fixup in commit message] Signed-off-by: Paul Spooren <mail@aparcar.org> (backported from commit 485ce5bbe5cc33526e56817694a79a7d94160e01) Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
* mvebu: base-files: Update Turris Omnia U-Boot environmentKlaus Kudielka2020-12-041-9/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Move the update procedure from sysupgrade to first boot, which is much more convenient in the sysupgrade case (otherwise the environment is always one generation behind). Check whether we have an old U-Boot release installed, and update the environment only if necessary. Some notes on the U-Boot environment: The first 9 lines are a copy of the default environment of the old U-Boot release - only modified, to run "distro_bootcmd", in case "mmcboot" fails to boot the factory OS. The remaining 16 lines are a backport of the default environment of the new U-Boot release (shipped with CZ11NIC23). The main entry point is "distro_bootcmd", which eventually sources boot.scr. This way, we have a unified boot protocol for all Turris Omnia revisions so far. This commit also fixes a shortcoming of previous Turris Omnia support: Users may install OpenWrt with the Turris Omnia in factory state (i.e. invalid environment store). In that case, neither fw_setenv, nor U-Boot itself, would import the default environment from the image - screwing up the rescue system, at least! Signed-off-by: Klaus Kudielka <klaus.kudielka@gmail.com> Reviewed-by: Tomasz Maciej Nowak <tomek_n@o2.pl> Tested-by: W. Michael Petullo <mike@flyn.org> (Turris Omnia "2020") Tested-by: Klaus Kudielka <klaus.kudielka@gmail.com> (Turris Omnia) (cherry picked from commit dfa357a3def512c13f22371d24138b6e8093be18)
* mvebu: Add turris-omnia.bootscriptKlaus Kudielka2020-12-042-1/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | In contrast to the U-Boot version shipped with older versions of Turris Omnia (CZ11NIC13, CZ11NIC20), the version shipped with Turris Omnia 2019 (CZ11NIC23) relies on the existence of /boot.scr. Consequently, add a suitable boot script to the sysupgrade image. Flash instructions for Turris Omnia 2019: - Download openwrt-...-sysupgrade.img.gz, gunzip it, and copy the resulting .img file to the root of a USB flash drive (FAT32 or ext2/3/4). - Enter a rescue shell: Either via 5-LED reset and ssh root@192.168.1.1 on LAN port 4, or via 7-LED reset and the serial console. - Insert the USB drive and mount it: mkdir /mnt; mount /dev/sda1 /mnt - Flash the OpenWrt image to eMMC: dd if=/mnt/openwrt-...-sysupgrade.img of=/dev/mmcblk0 bs=4096 conv=fsync - Reboot. Flash instructions using a temporary "medkit" installation were written for the older versions of Turris Omnia, and will *not* work on the Turris Omnia 2019. Signed-off-by: Klaus Kudielka <klaus.kudielka@gmail.com> Reviewed-by: Tomasz Maciej Nowak <tomek_n@o2.pl> Tested-by: W. Michael Petullo <mike@flyn.org> (Turris Omnia "2020") (cherry picked from commit afd4375a33840fa949c898fb6bc603e8645edd61)
* kernel: backport GD25Q256 support from 4.15Kuan-Yi Li2020-12-0123-52/+134
| | | | | | | | | | | | | | | | | | | | | | | | | | | Backport below changes for GigaDevice GD25Q256 support from v4.15: e27072851bf7 mtd: spi-nor: add a quad_enable callback in struct flash_info 65153846b18c mtd: spi-nor: add support for GD25Q256 This chip is used on newer Quad-E4G boards. Before: [ 2.366493] m25p80 spi0.0: unrecognized JEDEC id bytes: c8, 40, 19 [ 2.372853] m25p80: probe of spi0.0 failed with error -2 After: [ 2.371722] m25p80 spi0.0: gd25q256 (32768 Kbytes) [ 2.376694] 5 fixed-partitions partitions found on MTD device spi0.0 [ 2.383043] Creating 5 MTD partitions on "spi0.0": [ 2.387824] 0x000000000000-0x000000030000 : "u-boot" [ 2.394138] 0x000000030000-0x000000031000 : "u-boot-env" [ 2.400608] 0x000000031000-0x000000040000 : "config" [ 2.406830] 0x000000040000-0x000000050000 : "factory" [ 2.413169] 0x000000050000-0x000002000000 : "firmware" Signed-off-by: Kuan-Yi Li <kyli@abysm.org>
* kernel: bump 4.14 to 4.14.209Hauke Mehrtens2020-12-015-57/+37
| | | | | | | | | | | | Refreshed all patches. Altered patches: - 804-i2c-support-layerscape.patch Compile-tested on: ipq40xx, ath79, layerscape/armv8_64b Runtime-tested on: ipq40xx, ath79 Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
* ipq40xx: disable double-tagging for PSGMII devicesDavid Bauer2020-11-301-128/+0
| | | | | | | | | | | | | This commit disables the double tagging recently backported to 19.07. Operating the switch on the S-Tag had the advantage of being able to have separate VLANs for the same C-VID on LAN and WAN. However, this broke the ability to configure C-TAG modifications on the switch. Also performance took a significant toll. Fixes: commit 8c191712558c ("ipq40xx: fix ethernet vlan double tagging") Signed-off-by: David Bauer <mail@david-bauer.net>
* kernel: mtd: parser: cmdline: Fix parsing of part-names with colonsSven Eckelmann2020-11-241-0/+63
| | | | | | | | | | | | | | | | | | | | | | | 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: 9c718b5478ac ("kernel: bump 4.14 to 4.14.200") Signed-off-by: Sven Eckelmann <sven@narfation.org> (backported from commit 223eec7e81f8506592fc89cf79a2f14360f5c57b)
* ar71xx,ath79: refresh 910-unaligned_access_hacks.patchPetr Štetiar2020-11-242-2/+2
| | | | | | | | | Commit c9c7b4b3945c ("kernel: add netfilter-actual-sk patch") has touched net/ipv6/netfilter/ip6table_mangle.c which in turn has affected 910-unaligned_access_hacks.patch so the patch needs to be refreshed. Fixes: c9c7b4b3945c ("kernel: add netfilter-actual-sk patch") Signed-off-by: Petr Štetiar <ynezz@true.cz>
* kernel: add netfilter-actual-sk patchAaron Goodman2020-11-231-0/+234
| | | | | | | | 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>
* layerscape: Fix check after kernel updateHauke Mehrtens2020-11-161-2/+7
| | | | | | | | The fsl_destroy_mc_io() function was moved, add the new checks to the moved copy and not just remove it. Fixes: ac5297340e64 ("kernel: bump 4.14 to 4.14.206") Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
* kernel: bump 4.14 to 4.14.206Koen Vandeputte2020-11-1631-47/+52
| | | | | | | | | | | | | | | | Refreshed all patches. Altered patches: - 210-dwc2_defaults.patch - 708-mc-bus-support-layerscape.patch Fixes: - CVE-2020-25656 Compile-tested on: ar71xx, cns3xxx, imx6, x86_64 Runtime-tested on: ar71xx, cns3xxx, imx6 Signed-off-by: Koen Vandeputte <koen.vandeputte@ncentric.com>
* ath79: remove wmac mtd-mac-address for UniFi AC familyRoger Pueyo Centelles2020-11-121-1/+1
| | | | | | | | | | | | | | | | | The MAC address for the wmac 2.4 GHz radio of the Ubiquiti UniFi AC family of devices is actually embedded in the mtd-cal-data, so there is no need for mtd-mac-address (which was incorrectly forcing wmac to have the same MAC as eth0). This makes it coherent with the stock firmware and the ar71xx target: · XX:XX:XX:X0:XX:XX eth0 · XX:XX:XX:X1:XX:XX ath0/wlan1 (2.4 GHz) · XX:XX:XX:X2:XX:XX ath1/wlan0 (5 GHz) Checked on a UniFi AC Mesh, a UniFi AC LR and a UniFi Lite. Signed-off-by: Roger Pueyo Centelles <roger.pueyo@guifi.net> (cherry picked from commit 20ace70db65c3f1cb6a842d3092ac2eb7be81b5a)
* ath79: use correct firmware name for UniFi APDavid Bauer2020-11-111-4/+2
| | | | | | | | | | | The Ubiquiti UniFi AP does not have a AHB connected radio but a PCI one. Also the EEPROM ist only 0x440 bytes of length. Reported-by: Martin Weinelt <martin@darmstadt.freifunk.net> Tested-by: Martin Weinelt <martin@darmstadt.freifunk.net> Signed-off-by: David Bauer <mail@david-bauer.net> (backported from commit 4c5eb1040f94871626f6a533242c3a9c068d5bb6) Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
* ramips: fix logic level for DIR-645 buttonsDavid Bauer2020-11-111-2/+2
| | | | | | | | | | | | The D-Link DIR-645 currently uses an incorrect logic level for its buttons. Correct them in order to prevent unintentional activation of failsafe mode. Reported-by: Perry Melange <isprotejesvalkata@gmail.com> Signed-off-by: David Bauer <mail@david-bauer.net> (cherry picked from commit 929e8f0f553637076f2612fb1c2225c5cee1f7ab)
* ath79: fix LED labels for PowerCloud CAP324Adrian Schmutzler2020-11-113-3/+6
| | | | | | | | | | The order of function and color in the labels in inverted for the LAN LEDs. Fix it. Fixes: 915966d86121 ("ath79: Port PowerCloud Systems CAP324 support") Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de> (cherry picked from commit 96023cd4ba66c33e77d9df562dda44b0a1ba1ac9)
* mvebu: Add bootscript for espressobin to support mainline firmwareAndre Heider2020-10-282-0/+38
| | | | | | | | | | | | | | | | | The generic bootscript is tailored around a downstream firmware and doesn't work on a firmware built from mainline components. Add a bootscript which: * sets $console since mainline u-boot doesn't do that * uses distro boot variables, so OpenWRT can be booted off any supported device when using a mainline firmware * sets missing distro boot variables for the downstream firmware Booting with a downstream firmware is unchanged. Booting with a mainline firmware now works. Signed-off-by: Andre Heider <a.heider@gmail.com> (cherry picked from commit c43b45863e38fb18a486601c1601f1485d649c0b)
* kernel: bump 4.14 to 4.14.202Koen Vandeputte2020-10-211-1/+1
| | | | | | | | | Refreshed all patches. Compile-tested on: ar71xx, cns3xxx, imx6, x86_64 Runtime-tested on: ar71xx, cns3xxx, imx6, x86_64 Signed-off-by: Koen Vandeputte <koen.vandeputte@ncentric.com>
* kernel: bump 4.14 to 4.14.201Koen Vandeputte2020-10-149-19/+19
| | | | | | | | | | | | Refreshed all patches. Fixes: - CVE-2020-14386 Compile-tested on: ar71xx, cns3xxx, imx6, x86_64 Runtime-tested on: ar71xx, cns3xxx, imx6 Signed-off-by: Koen Vandeputte <koen.vandeputte@ncentric.com>
* oxnas: fix qc_prep return in sata driver after kernel 4.14.200Adrian Schmutzler2020-10-121-1/+3
| | | | | | | | | | | | | | | | | | | | | | | This fixes a regression after a kernel change in 4.14.200 [1] that led to build failure on oxnas/ox820: drivers/ata/sata_oxnas.c:2238:13: error: initialization of 'enum ata_completion_errors (*)(struct ata_queued_cmd *)' from incompatible pointer type 'void (*)(struct ata_queued_cmd *)' [-Werror=incompatible-pointer-types] .qc_prep = sata_oxnas_qc_prep, ^~~~~~~~~~~~~~~~~~ drivers/ata/sata_oxnas.c:2238:13: note: (near initialization for 'sata_oxnas_ops.qc_prep') Our local driver is changed the same way as prototyped in the kernel patch, i.e. return type is changed and AC_ERR_OK return value is added. [1] https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=306a1c5b5683c1d37565e575386139a64bdbec6f Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de> (cherry picked from commit f6ca57e4f40528a8a0103c9f0e9647a2e11d10c3)
* kernel: bump 4.14 to 4.14.200Koen Vandeputte2020-10-1219-46/+46
| | | | | | | | | Refreshed all patches. Compile-tested on: ar71xx, cns3xxx, imx6, x86_64 Runtime-tested on: ar71xx, cns3xxx, imx6 Signed-off-by: Koen Vandeputte <koen.vandeputte@ncentric.com>
* ath79: ar8216: make switch register access atomicChuanhong Guo2020-10-111-0/+59
| | | | | | | | | | | | | | | | | | | | reg accesses on integrated ar8229 sometimes fails. As a result, phy read got incorrect port status and wan link goes down and up mysteriously. After comparing ar8216 with the old driver, these local_irq_save/restore calls are the only meaningful differences I could find and it does fix the issue. The same changes were added in svn r26856 by Gabor Juhos: ar71xx: ag71xx: make switch register access atomic As I can't find the underlying problem either, this hack is broght back to fix the unstable link issue. This hack is only suitable for ath79 mdio and may easily break the driver on other platform. Limit it to ath79-only as a target patch. Fixes: FS#2216 Fixes: FS#3226 Signed-off-by: Chuanhong Guo <gch981213@gmail.com> (cherry picked from commit 86fdc8abed5992a74078b000b5ff9da723b6f46b)
* ath79: fix rssi-low LED for My Net Range ExtenderAdrian Schmutzler2020-09-281-1/+1
| | | | | | | | | | The LED color was missing in 01_leds. Fixes: 745dee11ac78 ("ath79: add support for WD My Net Wi-Fi Range Extender") Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de> (cherry picked from commit d232a8ac7d1679f7ff97cbc66b4c49c940bd009f)
* kernel: Update to version 4.14.199Hauke Mehrtens2020-09-2842-201/+201
| | | | | | Compile and runtime tested on lantiq/xrx200 + ath79/generic. Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
* Revert "ramips: ethernet: fix to interrupt handling"Jo-Philipp Wich2020-09-181-5/+6
| | | | | | | | | This reverts commit 7ac454014a11347887323a131415ac7032d53546. The change reportedly causes regressions in ethernet performance. Fixes: FS#3332 Signed-off-by: Jo-Philipp Wich <jo@mein.io>
* ramips: ethernet: fix to interrupt handlingNeilBrown2020-09-061-6/+5
| | | | | | | | | | | | | The current code acknowledged interrupts *after* polling. This is the wrong way around, and could cause an interrupt to be missed. This is not likely to be fatal as another packet, and so another interrupt, should come along soon. But maybe it is causing problems, so let's fix it anyway. Signed-off-by: NeilBrown <neil@brown.name> (Note that this matches the upstream driver.) Signed-off-by: Rosen Penev <rosenp@gmail.com>
* oxnas: reduce size of ATA DMA descriptor spaceDaniel Golle2020-08-291-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | After years of trying to find the reason for random kernel crashes while both CPU and SATA are under load it has been found. Some odd commented-out #defines in kref's single-port driver [1] which were copied from the vendor driver made me develop a theory: The IO-mapped memory area for DMA descriptors apparetly got some holes just before the alignment boundaries. This feels like an off-by-one bug in the hardware or maybe those fields are used internally by the SATA controller's firmware. Whatever the cause is: they cannot be used and trying to use them results in reading back unexpected stuff and ends up with oopsing Unable to handle kernel paging request at virtual address d085c004 Work around the issue by reducing the area used for bmdma descriptors. This reduces SATA performance (iops) quite a bit, but finally makes things work reliably. Possibly one could optimize this much more by really just skipping the holes in that memory area -- however, that seems to be non-trivial with the driver and libata in it's current form (suggestions are welcome). The 'proper' way to have good SATA performance would be to make use of the hardware RAID features (one can use the JBOD mode to access even just a single disc transparently through the RAID controller integrated in the SATA host instead of accessing the SATA ports 'raw' as we do now). [1]: https://github.com/kref/linux-oxnas/blob/master/drivers/ata/sata_oxnas.c#L25 Signed-off-by: Daniel Golle <daniel@makrotopia.org> (cherry picked from commit 5793112f751ee3d9f841af4846d68e6b1ff1bff4, including fixup commit d75e75306301852a848824cf268d8b58eda28a8a)
* kernel: Update kernel 4.14 to version 4.14.195Hauke Mehrtens2020-08-2742-102/+102
| | | | | | Compile and runtime tested on lantiq/xrx200 and x86/64. Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
* ath79: add support for TP-Link TL-WR710N v2.1Adrian Schmutzler2020-08-245-118/+152
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This adds support for the TP-Link TL-WR710N v2.1. It is basically a re-issue of the v1.2. Specifications: SoC: Atheros AR9331 CPU: 400 MHz Flash: 8 MiB RAM: 32 MiB WiFi: 2.4 GHz b/g/n Ethernet: 2x 100M ports USB: 1x 2.0 The only difference from the v1 is the TP-Link hardware ID/revision. Attention: The TL-WR710N v2.0 (!) has only 4 MB flash and cannot be flashed with this image. It has a different TPLINK_HWREV, so accidental flashing of the factory image should be impossible without additional measures. Unfortunately, the v2.0 in ar71xx has the same board name, so sysupgrade from ar71xx v2.0 into ath79 v1/v2.1 will not be prevented, but will brick the device. Flashing instruction: Upload the factory image via the OEM firmware GUI upgrade mechanism. Further notes: To make implementation easier if somebody desires to port the 4M v2.0, this already creates two DTSI files. Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de> Tested-by: Fabian Eppig <fabian@eppig.de> (backported from eb531337a779a48a2d17bc66f0d222325d6c1563)
* generic: platform/mikrotik: fix incorrect testThibaut VARÈNE2020-08-181-1/+1
| | | | | | | 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)
* ath79: enable gpio on ar933x by defaultAdrian Schmutzler2020-08-1812-46/+0
| | | | | | | | | | | | | | | | All other SoC DTSI files have gpio enabled by default, only ar9330/ar9331 disable it by default, only to have it enabled again afterwards for each individual device. So, do not disable it in the first place, and drop all device-specific status statements afterwards. Though this is a cosmetic commit, it might be a pitfall for device-support backporters if missing. Since backporting it is trivial, let's just do it. Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de> (cherry picked from commit dc1280ef652c6522269c7a864810c19362d33dc4)
* ath79: fix syntax error in ar7240_tplink_tl-wa.dtsiAdrian Schmutzler2020-08-171-1/+1
| | | | | | | | | | The node needs to be terminated by a semicolon. Fixes: 8484a764df20 ("ath79: ar724x: make sure builtin-switch is enabled in DT") Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de> (cherry picked from commit e329e71c6915ffdf7fe99efc323a6de7867d0cbe)
generated by cgit v1.2.3 (git 2.25.1) at 2024-12-26 05:32:01 +0000