aboutsummaryrefslogtreecommitdiffstats
path: root/target/linux
Commit message (Collapse)AuthorAgeFilesLines
* ipq40xx: essedma: Disable TCP segmentation offload for IPv6Sven Eckelmann2020-06-131-7/+4
| | | | | | | | | | | | | | | | | | | | | It was noticed that the the whole MAC can hang when transferring data from one ar40xx port (WAN ports) to the CPU and from the CPU back to another ar40xx port (LAN ports). The CPU was doing only NATing in that process. Usually, the problem first starts with a simple data corruption: $ wget https://cdimage.debian.org/debian-cd/current/amd64/iso-cd/debian-10.4.0-amd64-netinst.iso -O /dev/null ... Connecting to saimei.ftp.acc.umu.se (saimei.ftp.acc.umu.se)|2001:6b0:19::138|:443... connected. ... Read error at byte 48807936/352321536 (Decryption has failed.). Retrying. But after a short while, the whole MAC will stop to react. No traffic can be transported anymore from the CPU port from/to the AR40xx PHY/switch and the MAC has to be resetted. Signed-off-by: Sven Eckelmann <sven@narfation.org> Acked-by: John Crispin <john@phrozen.org>
* ramips: drop useless label-mac-device for RouterBOARD 750Gr3Adrian Schmutzler2020-06-131-1/+0
| | | | | | | | | | | | | | With the new driver, MAC addresses are not set up in DTS anymore, and therefore label-mac-device will be useless there. Setup is done properly in 02_network, so this just removes the obsolete alias. Fixes: 5e50515fa6b3 ("ramips/mt7621: mikrotik: don't use mtd-mac-address in DTS") Suggested-by: John Thomson <git@johnthomson.fastmail.com.au> Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
* bcm47xx: move device definitions to subfilesAdrian Schmutzler2020-06-124-852/+848
| | | | | | | | | With several subtargets, the image/Makefile becomes crowded after a while. Many targets have moved their device definitions to $subtarget.mk files to have them more organized, let's do this here as well. Cc: Rafał Miłecki <rafal@milecki.pl> Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
* ramips: fix port display for TRENDnet TEW-810DRJ. Scott Heppler2020-06-121-1/+1
| | | | | | | | | | This updates the display port order for the TEW-810DR to be in line with the DIR-810L. Both share the same board and pictures on the vendors' pages indicate the same external numbering scheme as well. Signed-off-by: J. Scott Heppler <shep971@centurylink.net> [replace commit message] Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
* ramips: mt7621: add support for NETGEAR WAC104Pawel Dembicki2020-06-124-1/+186
| | | | | | | | | | | | | | | | | | | | | | | | NETGEAR WAC104 is an AP based on castrated R6220, without WAN port and USB. SoC: MediaTek MT7621ST RAM: 128M DDR3 FLASH: 128M NAND WiFi: MediaTek MT7612EN an+ac MediaTek MT7603EN bgn ETH: MediaTek MT7621ST (4x LAN) BTN: 1x Connect (WPS), 1x WLAN, 1x Reset LED: 7x (3x GPIO controlled) Installation: Login to netgear webinterface and flash factory.img Back to stock: Use nmrpflash to revert stock image. Signed-off-by: Pawel Dembicki <paweldembicki@gmail.com>
* ath79: add support for D-Link DAP-2695-A1Stijn Tintel2020-06-117-0/+235
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Hardware: * SoC: Qualcomm Atheros QCA9558 * RAM: 256MB * Flash: 16MB SPI NOR * Ethernet: 2x 10/100/1000 (1x 802.3at PoE-PD) * WiFi 2.4GHz: Qualcomm Atheros QCA9558 * WiFi 5GHz: Qualcomm Ahteros QCA9880-2R4E * LEDS: 1x 5GHz, 1x 2.4GHz, 1x LAN1(POE), 1x LAN2, 1x POWER * Buttons: 1x RESET * UART: 1x RJ45 RS-232 Console port Installation via stock firmware: * Install the factory image via the stock firmware web interface Installation via bootloader Emergency Web Server: * Connect your PC to the LAN1(PoE) port * Configure your PC with IP address 192.168.0.90 * Open a serial console to the Console port (115200,8n1) * Press "q" within 2s when "press 'q' to stop autoboot" appears * Open http://192.168.0.50 in a browser * Upload either the factory or the sysupgrade image * Once you see "write image into flash...OK,dest addr=0x9f070000" you can power-cycle the device. Ignore "checksum bad" messages. Setting the MAC addresses for the ethernet interfaces via /etc/board.d/02_network adds the following snippets to /etc/config/network: config device 'lan_eth0_1_dev' option name 'eth0.1' option macaddr 'xx:xx:xx:xx:xx:xx' config device 'wan_eth1_2_dev' option name 'eth1.2' option macaddr 'xx:xx:xx:xx:xx:xx' This would result in the proper MAC addresses being set for the VLAN subinterfaces, but the parent interfaces would still have a random MAC address. Using untagged VLANs could solve this, but would still leave those extra snippets in /etc/config/network, and then the device VLAN setup would differ from the one used in ar71xx. Therefore, the MAC addresses of the ethernet interfaces are being set via preinit instead. The bdcfg partition contains 4 MAC address labels: - lanmac - wanmac - wlanmac - wlanmac_a The first 3 all contain the same MAC address, which is also the one on the label. Signed-off-by: Stijn Tintel <stijn@linux-ipv6.be> Reviewed-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
* ath79: enable wrgg MTD splitterStijn Tintel2020-06-112-0/+2
| | | | | | This is required for the D-Link DAP-2695-A1. Signed-off-by: Stijn Tintel <stijn@linux-ipv6.be>
* kernel: rtl8367b: fix external interface modesINAGAKI Hiroshi2020-06-112-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The interface mode number of RGMII_33V is 7 on RTL8367, but it's 9 on RTL8367B. the external interface modes for RTL8367 are follows: - 0, Disabled - 1, RGMII - 2, MII_MAC - 3, MII_PHY - 4, TMII_MAC - 5, TMII_PHY - 6, GMII - 7, RGMII_33V the external interface modes for RTL8367B are follows: - 0, Disabled - 1, RGMII - 2, MII_MAC - 3, MII_PHY - 4, TMII_MAC - 5, TMII_PHY - 6, GMII - 7, RMII_MAC - 8, RMII_PHY - 9, RGMII_33V But the driver in U-Boot of RT-N56U GPL tar blocks using RGMII_33V (9) mode and it seems to be unsupported on RTL8367B, so drop it from switch-case in rtl8367b_extif_set_mode. ref (RTL8367): - TL-WR2453ND v1 ref (RTL8367B): - ASUS RT-N56U - TP-Link Archer C2 v1 Signed-off-by: INAGAKI Hiroshi <musashino.open@gmail.com>
* ramips: fix port display for D-Link DIR-810LAdrian Schmutzler2020-06-111-5/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | The port order displayed in LuCI is currently inverted for this devices: LuCI - Device LAN1 - LAN4 LAN2 - LAN3 LAN3 - LAN2 LAN4 - LAN1 Fix it. Strangely, the owner of a TRENDnet TEW-810DR reports that the initial port order is correct, while both devices share the same board and look similar from the outside. Since I cannot investigate this without having any of the devices, this does only touch the DIR-810L for now. While at it, also merge in the case for zbtlink,zbt-we2026, as the display port specified for WAN there won't have any effect anyway. Reported-by: Roger Pueyo Centelles <roger.pueyo@guifi.net> Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
* bcm63xx: switch to upstream NAND patchesÁlvaro Fernández Rojas2020-06-119-35/+191
| | | | Signed-off-by: Álvaro Fernández Rojas <noltari@gmail.com>
* ramips: fix WAN LED for D-Link DIR-810L/TRENDnet TEW-810DRAdrian Schmutzler2020-06-114-20/+19
| | | | | | | | | | | | | | | | | | The WAN LED on DIR-810L was actually blinking on LAN1 port activity. This has already been improved for the TEW-810DR, where the GPIO has been set up explicitly rather than having it controlled by the switch. This patch also applies this setup to the DIR-810L. In addition, the trigger in 01_leds is set up with ucidef_set_led_switch for both devices now, so state changes should be displayed correctly as well. Reported-by: Roger Pueyo Centelles <roger.pueyo@guifi.net> Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de> Tested-by: Roger Pueyo Centelles <roger.pueyo@guifi.net> [DIR-810L] Tested-by: J. Scott Heppler <shep971@centurylink.net> [TEW-810DR]
* apm821xx: move device definitions to subfilesAdrian Schmutzler2020-06-113-158/+152
| | | | | | | | | | | | With several subtargets, the image/Makefile becomes crowded after a while. Many targets have moved their device definitions to $subtarget.mk files to have them more organized, let's do this here as well. While at it, also move subtarget-specific build recipes. Cc: Christian Lamparter <chunkeey@gmail.com> Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de> Acked-by: Christian Lamparter <chunkeey@gmail.com>
* treewide: simplify inclusion of subtarget image filesAdrian Schmutzler2020-06-1111-72/+15
| | | | | | | | | | | | | | Many target use a repetitive if-include scheme for their subtarget image files, though their names are consistent with the subtarget names. This patch removes these redundant conditions and just uses the variable for the include where the target setup allows it. For sunxi, this includes a trivial rename of the subtarget image Makefiles. Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
* ath79: add support for the Netgear WNDRMAC v1Renaud Lepage2020-06-114-0/+50
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The Netgear WNDRMAC v1 is a hardware variant of the Netgear WNDR3700 v2 Specifications ============== * SoC: Atheros AR7161 * RAM: 64mb * Flash on board: 16mb * WiFi: Atheros AR9220 (a/n), Atheros AR9223 (b/g/n) * Ethernet: RealTek RTL8366SR (1xWAN, 4xLAN, Gigabit) * Power: 12 VDC, 2.5 A * Full specs on [openwrt.org](https://openwrt.org/toh/hwdata/netgear/netgear_wndrmac_v1) Flash Instructions ================== It is possible to use the OEM Upgrade page to install the `factory` variant of the firmware. After the initial upgrade, you will need to telnet into the router (default IP 192.168.1.1) to install anything. You may install LuCI this way. At this point, you will have a web interface to configure OpenWRT on the WNDRMAC v1. Please use the `sysupgrade` variant for subsequent flashes. Recovery Instructions ===================== A TFTP-based recovery flash is possible if the need arises. Please refer to the WNDR3700 page on openwrt.org for details. https://openwrt.org/toh/netgear/wndr3700#troubleshooting_and_recovery Signed-off-by: Renaud Lepage <root@cybikbase.com> [update DTSI include name] Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
* ath79: add support for the Netgear WNDRMAC v2Renaud Lepage2020-06-114-4/+55
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The Netgear WNDRMAC v2 is a hardware variant of the Netgear WNDR3800 Specifications ============== * SoC: Atheros AR7161 * RAM: 128mb * Flash on board: 16mb * WiFi: Atheros AR9220 (a/n), Atheros AR9223 (b/g/n) * Ethernet: RealTek RTL8366SR (1xWAN, 4xLAN, Gigabit) * Serial console: Yes, 115200 / 8N1 (JTAG) * USB: 1x2.0 * Power: 12 VDC, 2.5 A * Full specs on [openwrt.org](https://openwrt.org/toh/hwdata/netgear/netgear_wndrmac_v2) Flash Instructions ================== It is possible to use the OEM Upgrade page to install the `factory` variant of the firmware. After the initial upgrade, you will need to telnet into the router (default IP 192.168.1.1) to install anything. You may install LuCI this way. At this point, you will have a web interface to configure OpenWRT on the WNDRMAC v2. Please use the `sysupgrade` variant for subsequent flashes. Recovery Instructions ===================== A TFTP-based recovery flash is possible if the need arises. Please refer to the WNDR3800 page on openwrt.org for details. https://openwrt.org/toh/netgear/wndr3800#recovery_flash_in_failsafe_mode Signed-off-by: Renaud Lepage <root@cybikbase.com> [do not add device to uboot-envtools, update DTSI name] Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
* ath79: rename DTSI for Netgear WNDR devices based on ar7161Adrian Schmutzler2020-06-115-4/+4
| | | | | | | This renames the DTSI for Netgear WNDR devices based on ar7161 to indicate that the file is not limited to WNDR3700 models. Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
* ramips: limit uci commit to the changed config fileAdrian Schmutzler2020-06-111-1/+1
| | | | | | | Since 01_enable_packet_steering only touches the network config, limit the uci commit to this as well. Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
* ramips: use amber LED for boot/failsafe on Netgear EX3700/EX6130Adrian Schmutzler2020-06-112-16/+16
| | | | | | | | | According to the manual, the amber power LED is used to indicate boot, while the green LED is meant to indicate a running system. While at it, also adjust the DT node names for all LEDs. Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
* ramips: add support for Netgear EX6120Adrian Schmutzler2020-06-116-2/+72
| | | | | | | | | | | | | | | | | | | | | | | | | | Specifications: * SoC: MT7620A * CPU: 580 MHz * RAM: 64 MB DDR * Flash: 8MB NOR SPI flash * WiFi: MT7612E (5GHz) and builtin MT7620A (2.4GHz) * LAN: 1x100M The device is identical to the EX6130 except for the mains socket and the hardware ID. Installation: The -factory images can be flashed from the device's web interface or via nmrpflash. Notes: MAC addresses were set up based on the EX6130 setup. This is based on prior work of Adam Serbinski and Mathias Buchwald. Tested by Mathias Buchwald. Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
* ramips: add mt7621 ethernet driver improvementsFelix Fietkau2020-06-102-0/+98
| | | | | | | - Speed up MDIO bus access - Improve performance on tx completion Signed-off-by: Felix Fietkau <nbd@nbd.name>
* kernel: backport upstream DSA GRO supportFelix Fietkau2020-06-101-0/+143
| | | | | | Should improve performance Signed-off-by: Felix Fietkau <nbd@nbd.name>
* ramips: enable packet steering by default on mt7621Felix Fietkau2020-06-101-0/+4
| | | | | | | It provides a significant performance boost, especially with flow offloading enabled Signed-off-by: Felix Fietkau <nbd@nbd.name>
* ath79: wndr3700 series: fix wifi range & throughputChristian Lamparter2020-06-092-0/+40
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch adds ar71xx's GPIO setup for the 2.4GHz and 5GHz antennae demultiplexer: | 158 /* 2.4 GHz uses the first fixed antenna group (1, 0, 1, 0) */ | 159 ap9x_pci_setup_wmac_gpio(0, (0xf << 6), (0xa << 6)); | 160 | 161 /* 5 GHz uses the second fixed antenna group (0, 1, 1, 0) */ | 162 ap9x_pci_setup_wmac_gpio(1, (0xf << 6), (0x6 << 6)); This should restore the range and throughput of the 2.4GHz radio on all the derived wndr3700 variants and versions with the AR7161 SoC. A special case is the 5GHz radio. The original wndr3700(v1) will benefit from this change. However the wndr3700v2 and later revisions were unaffected by the missing bits, as there is no demultiplexer present in the later designs. This patch uses gpio-hogs within the device-tree for all wndr3700/wndr3800/wndrmac variants. Notes: Based on the PCB pictures, the WNDR3700(v1) really had eight independent antennae. Four antennae for each radio and all of those were printed on the circut board. The WNDR3700v2 and later have just six antennae. Four of those are printed on the circuit board and serve the 2.4GHz radio. Whereas the remaining two are special 5GHz Rayspan Patch Antennae which are directly connected to the 5GHz radio. Hannu Nyman dug pretty deep and unearthed a treasure of information regarding the history of how these values came to be in the OpenWrt archives: <https://dev.archive.openwrt.org/ticket/6533.html>. Mark Mentovai came across the fixed antenna group when he was looking into the driver: fixed_antenna_group 1, (0, 1, 0, 1) fixed_antenna_group 2, (0, 1, 1, 0) fixed_antenna_group 3, (1, 0, 0, 1) fixed_antenna_group 4, (1, 0, 1, 0) Fixes: FS#3088 Reported-by: Luca Bensi Reported-by: Maciej Mazur Reported-by: Hannu Nyman <hannu.nyman@iki.fi> Debugged-by: Hannu Nyman <hannu.nyman@iki.fi> Signed-off-by: Christian Lamparter <chunkeey@gmail.com>
* oxnas: build with 8021Q VLAN supportDaniel Golle2020-06-091-1/+0
| | | | | | | | CONFIG_VLAN_8021Q was explicitely disabled in oxnas kernel config. Don't do that, so VLANs can be used on the target. Fixes: dcc34574ef ("oxnas: bring in new oxnas target") Signed-off-by: Daniel Golle <daniel@makrotopia.org>
* kernel: bump 5.4 to 5.4.45Petr Štetiar2020-06-0929-594/+350
| | | | | | | | | | | | | | | | | | | Fixes CVE-2020-10757 via upstream commit df4988aa1c96 ("mm: Fix mremap not considering huge pmd devmap"). Resolved merge conflict in the following patches: bcm27xx: 950-0128-gpiolib-Don-t-prevent-IRQ-usage-of-output-GPIOs.patch Refreshed patches, removed upstreamed patch: generic: 751-v5.8-net-dsa-mt7530-set-CPU-port-to-fallback-mode.patch generic: 754-v5.7-net-dsa-mt7530-fix-roaming-from-DSA-user-ports.patch Run tested: qemu-x86-64 Build tested: x86/64, imx6, sunxi/a53 Signed-off-by: Petr Štetiar <ynezz@true.cz>
* ramips: erx and erx-sfp: fix missing WAN interfacePerry Melange2020-06-091-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This partially reverts commit 5acd1ed0be0d ("ramips: mt7621: fix Ubiquiti ER-X ports names and MAC addresses"), this change was discussed in https://github.com/openwrt/openwrt/pull/2901#discussion_r407238452 With commit 5acd1ed0be0d ("ramips: mt7621: fix Ubiquiti ER-X ports names and MAC addresses"), all the ports were put into the LAN bridge, with the argument that the OEM firmware does not have a WAN port enabled. In the default OEM setup, all of the ports except eth0 are dead and eth0 is set to a static IP address without providing DHCP services when connected. It is only after the wizard has been run that eth0 becomes the WAN port and all the rest of the ports belong to LAN with DHCP enabled. Having all of the ports set to the LAN bridge does not mirror the default OEM setup. To accomplish that, then only eth0 would be in the LAN bridge. But this is not the expected behaviour of OpenWrt. Therefore this proposal to set eth0 to WAN and eth1-N to LAN provides the expected behaviour expected from OpenWrt, maintains the current documentation as up-to-date, and does not require the user to manually detach eth0 from the LAN bridge, create the WAN(6) interface(s), and set eth0 to the WAN(6) interface(s). Fixes: 5acd1ed0be0d ("ramips: mt7621: fix Ubiquiti ER-X ports names and MAC addresses") Signed-off-by: Perry Melange <isprotejesvalkata@gmail.com> [commit subject and description tweaks] Signed-off-by: Petr Štetiar <ynezz@true.cz>
* mediatek: fix image/mt7622.mkJohn Crispin2020-06-071-1/+1
| | | | Signed-off-by: John Crispin <john@phrozen.org>
* bcm63xx: bcm6328: switch to upstream boot sel patchÁlvaro Fernández Rojas2020-06-072-13/+30
| | | | | | BCM6328 boot selection fix has been upstreamed. Signed-off-by: Álvaro Fernández Rojas <noltari@gmail.com>
* bcm63xx: add support for the Sercomm H500-sDaniel González Cabanelas2020-06-078-3/+350
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Sercomm H500-s is an xDSL dual band wireless router based on Broadcom BCM63167 SoC. Hardware: SoC: Broadcom BCM63167 CPU: BMIPS4350 V8.0, 400 MHz, 2 cores Flash: NAND 128 MiB RAM: DDR3 128 MiB Ethernet: 4x 10/100/1000 Mbps Switch: BCM53134S Wireless: 802.11b/g/n: BCM435f (integrated) 802.11ac: Quantenna QT3740BC (onboard SoC) USB: 1x 2.0 LEDs/Buttons: 11x / 2x Flash instruction, web UI: 1. Reset to defaults using the reset button if the admin password is unknown 2. Login into the web UI as admin. Address: http://192.168.0.1 User: admin Password: VF-ESVodafone-H-500-s or l033i-h500s 3. Go to Settings -> Firmware Update, and select the Openwrt factory firmware 4. Update the firmware. 5. Wait until it finish, the device will reboot with Openwrt installed on the alternative image partitions keeping the stock firmware in the former. Notes: - The patch also adds support for the lowi version. Only the factory firmware is different. - The integrated Wifi in the Broadcom Soc isn't still supported. - The Quantenna 802.11ac wifi works ok, but needs to be configured with the Quantenna client application. It can't be configured with Luci nor any iw command since it's a separated subsystem linked via ethernet. - The BCM53134S external switch is managed via MDIO which isn't supported in this target. Therefore it will behave as a dumb switch. Signed-off-by: Daniel González Cabanelas <dgcbueu@gmail.com>
* bcm63xx: image: support device-specific load addressÁlvaro Fernández Rojas2020-06-071-12/+10
| | | | | | | Some CFEs are located at the address currently used for relocation and lzma loader load address, so we need to provide a way to override it. Signed-off-by: Álvaro Fernández Rojas <noltari@gmail.com>
* bcm63xx: image: don't add the CFE to the sercomm factoryDaniel González Cabanelas2020-06-071-12/+0
| | | | | | | | | | | | | | | There is no need to include the CFE bootloader in the Sercomm factory images. There might be a case when this could be useful: - We are running the stock firmware on the first Sercomm image - The second partition storing the botloader was erased (unlikely) Even in this case flashing an image without a bootlader is harmless. Don't include the bootloader in the factory image creation and rid of the risk of flashing factory images with an untested bootloader partition. Signed-off-by: Daniel González Cabanelas <dgcbueu@gmail.com>
* bcm63xx: kernel: add BCM63167 cpuid variantDaniel González Cabanelas2020-06-073-24/+28
| | | | | | | | | The BCM63167 is a BCM63268 SoC with a different physical packaging. Add the CPU ID to allow supporting routers with this SoC (i.e Sercomm H500-s) Signed-off-by: Daniel González Cabanelas <dgcbueu@gmail.com>
* bcm63xx: vr-3032u: add missing compatible propertyÁlvaro Fernández Rojas2020-06-071-1/+1
| | | | | | SoC is a BCM63168. Signed-off-by: Álvaro Fernández Rojas <noltari@gmail.com>
* bcm63xx: vg-8050: add missing compatible propertyÁlvaro Fernández Rojas2020-06-071-1/+1
| | | | | | SoC is a BCM63169. Signed-off-by: Álvaro Fernández Rojas <noltari@gmail.com>
* mediatek: add mt7531 DSA supportJohn Crispin2020-06-078-38/+2028
| | | | Signed-off-by: John Crispin <john@phrozen.org>
* mediatek: add bpi-r64 emmc supportJohn Crispin2020-06-075-8/+638
| | | | Signed-off-by: John Crispin <john@phrozen.org>
* mediatek: make emmc image generation work on mt7622John Crispin2020-06-072-1/+20
| | | | Signed-off-by: John Crispin <john@phrozen.org>
* mediatek: switch over to extended upstream eip97 driverJohn Crispin2020-06-073-0/+5514
| | | | Signed-off-by: John Crispin <john@phrozen.org>
* mediatek: tidy up image subtarget MakefilesSungbo Eo2020-06-072-24/+23
| | | | | | | | | | - sort device recipes alphabetically - adjust board name of ELECOM WRC-2533GENT - harmonize line wrapping Signed-off-by: Sungbo Eo <mans0n@gorani.run> [rebased] Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
* bcm27xx: fix unmounting /boot after sysupgradeStijn Tintel2020-06-071-1/+1
| | | | | | | | Due to a typo, /boot is not properly unmounted after copying the backup file to it. Fix the typo to solve this. Fixes: 246916ddf4a1 ("brcm2708: use x86's upgrade scripts for all rpi targets") Signed-off-by: Stijn Tintel <stijn@linux-ipv6.be>
* kernel: sch_cake: use skb hash improve wireguard compatibilityKevin Darbyshire-Bryant2020-06-051-0/+170
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | While the other fq-based qdiscs take advantage of skb->hash and doesn't recompute it if it is already set, sch_cake does not. This was a deliberate choice because sch_cake hashes various parts of the packet header to support its advanced flow isolation modes. However, foregoing the use of skb->hash entirely loses a few important benefits: - When skb->hash is set by hardware, a few CPU cycles can be saved by not hashing again in software. - Tunnel encapsulations will generally preserve the value of skb->hash from before the encapsulation, which allows flow-based qdiscs to distinguish between flows even though the outer packet header no longer has flow information. It turns out that we can preserve these desirable properties in many cases, while still supporting the advanced flow isolation properties of sch_cake. This patch does so by reusing the skb->hash value as the flow_hash part of the hashing procedure in cake_hash() only in the following conditions: - If the skb->hash is marked as covering the flow headers (skb->l4_hash is set) AND - NAT header rewriting is either disabled, or did not change any values used for hashing. The latter is important to match local-origin packets such as those of a tunnel endpoint. The immediate motivation for fixing this was the recent patch to WireGuard to preserve the skb->hash on encapsulation. As such, this is also what I tested against; with this patch, added latency under load for competing flows drops from ~8 ms to sub-1ms on an RRUL test over a WireGuard tunnel going through a virtual link shaped to 1Gbps using sch_cake. This matches the results we saw with a similar setup using sch_fq_codel when testing the WireGuard patch. Fixes: 046f6fd5daef ("sched: Add Common Applications Kept Enhanced (cake) qdisc") Signed-off-by: Toke Høiland-Jørgensen <toke@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Kevin Darbyshire-Bryant <ldir@darbyshire-bryant.me.uk>
* mvebu: remove ClearFog Pro SUPPORTED_DEVICESDENG Qingfang2020-06-051-1/+0
| | | | | | | | | | A direct upgrade from previous swconfig version with incompatible settings to DSA will break the internet. Remove SUPPORTED_DEVICES so users cannot upgrade directly. Signed-off-by: DENG Qingfang <dengqf6@mail2.sysu.edu.cn> [rebase after Linksys rename, adjust title] Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
* mvebu: rename Linksys devices based on their common namesPaul Spooren2020-06-0521-77/+223
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The Linksys devices in mvebu target feature a mixed naming, where parts are based on the official product name (device node, image; e.g. WRT3200ACM) and parts are based on the internal code name (DTS file name, compatible, LED labels; e.g. rango). This inconsistent naming has been perceived as quite confusing. A recent attempt by Paul Spooren to harmonize this naming in kernel has been declined there. However, for us it still makes sense to apply at least a part of these changes locally. Primarily, this patch changes the compatible in DTS and thus the board name used in various scripts to have them in line with the device, model and image names. Due to the recent switch from swconfig to DSA, this allows us to drop SUPPORTED_DEVICES and thus prevent seamless upgrade between these incompatible setups. However, this does not include the LED label rename from Paul's initial patch: I don't think it's worth keeping the enormous diff locally for this case, as we can implement this much easier in 01_leds if we have to live with the inconsistency anyway. Signed-off-by: Paul Spooren <mail@aparcar.org> [rebase, extend to all devices, drop DT LED changes] Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
* kernel: b53: fix compilation with kernels 5.5+Rafał Miłecki2020-06-051-0/+8
| | | | Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
* generic: mt7530: support adjusting EEEDENG Qingfang2020-06-041-0/+121
| | | | | | Add support for adjusting EEE with ethtool Signed-off-by: DENG Qingfang <dengqf6@mail2.sysu.edu.cn>
* generic: mt7530: fix roaming from DSA user portsDENG Qingfang2020-06-041-0/+116
| | | | | | | | | | | | | | | | | | | When a client moves from a DSA user port to a software port in a bridge, it cannot reach any other clients that connected to the DSA user ports. That is because SA learning on the CPU port is disabled, so the switch ignores the client's frames from the CPU port and still thinks it is at the user port. Fix it by enabling SA learning on the CPU port. To prevent the switch from learning from flooding frames from the CPU port, set skb->offload_fwd_mark to 1 for unicast and broadcast frames, and let the switch flood them instead of trapping to the CPU port. Multicast frames still need to be trapped to the CPU port for snooping, so set the SA_DIS bit of the MTK tag to 1 when transmitting those frames to disable SA learning. Signed-off-by: DENG Qingfang <dengqf6@mail2.sysu.edu.cn>
* generic: fix DSA VLAN filteringDENG Qingfang2020-06-043-0/+199
| | | | | | | | | | | Currently enabling VLAN filtering blocks all traffic in the bridge immediately. That is because DSA ignores all VLAN setup when VLAN filtering is disabled, and when it is enabled, there is no VLAN entry in the VLAN table, causing all traffic to be blocked. Add patches to allow VLAN setup even if VLAN filtering is disabled. Signed-off-by: DENG Qingfang <dengqf6@mail2.sysu.edu.cn>
* generic: mt7530: set CPU port to fallback modeDENG Qingfang2020-06-041-0/+65
| | | | | | | | | | | | | | | | | | | Currently, setting a bridge's self PVID to other value and deleting the default VID 1 renders untagged ports of that VLAN unable to talk to the CPU port: bridge vlan add dev br0 vid 2 pvid untagged self bridge vlan del dev br0 vid 1 self bridge vlan add dev sw0p0 vid 2 pvid untagged bridge vlan del dev sw0p0 vid 1 # br0 cannot send untagged frames out of sw0p0 anymore That is because the CPU port is set to security mode and its PVID is still 1, and untagged frames are dropped due to VLAN member violation. Set the CPU port to fallback mode so untagged frames can pass through. Signed-off-by: DENG Qingfang <dengqf6@mail2.sysu.edu.cn>
* ramips/mediatek: select kmod-mt7615-firmware where kmod-mt7615e is selectedFelix Fietkau2020-06-043-28/+29
| | | | | | | The new mt76 version splits out the firmware, because the driver can also be used for MT7663/MT7613 Signed-off-by: Felix Fietkau <nbd@nbd.name>
* kernel: fix portability issue with perf on linux 5.4Felix Fietkau2020-06-041-3/+48
| | | | | | | Remove dependencies on core kernel headers in host tools used to build perf, which break on any non-linux system Signed-off-by: Felix Fietkau <nbd@nbd.name>
generated by cgit v1.2.3 (git 2.25.1) at 2024-11-14 17:54:15 +0000