[PATCH 0/3] realtek: add support for Panasonic Switch-M8eG PN28080K

2021-10-03 Thread INAGAKI Hiroshi
This is a continuation of the PR in GitHub[1]. This patch series adds support for Panasonic Switch-M8eG PN28080K. Panasonic Switch-M*eG PN28xx0K series has the following models: - Switch-M8eG PN28080K (RTL8380M, 8 + 1 SFP) - 1-9 : RTL8380M (SoC) - Switch-M16eG PN28160K (RTL8382M?, 14 + 2 comb

[PATCH 3/3] realtek: add support for Panasonic Switch-M8eG PN28080K

2021-10-03 Thread INAGAKI Hiroshi
Panasonic M8eG PN28080K is a 8 + 1 port gigabit switch, based on RTL8380M. Specification: - SoC : Realtek RTL8380M - RAM : DDR3 128 MiB (Winbond W631GG8KB-15) - Flash : SPI-NOR 32 MiB (Macronix MX25L25635FMI-10G) - Ethernet : 10/100/1000 Mbps x8 + 1 - port 1-8

[PATCH 2/3] realtek: enable gpio-restart driver in target

2021-10-03 Thread INAGAKI Hiroshi
On Panasonic Switch-M8eG PN28080K, a GPIO pin on PCA9539 chip is used for for hard-reset of the system. To use this, enable gpio-restart driver and built-in to the kernel. Signed-off-by: INAGAKI Hiroshi --- target/linux/realtek/config-5.10 | 1 + target/linux/realtek/config-5.4 | 1 + 2 files c

[PATCH 1/3] realtek: enable pca953x driver for target

2021-10-03 Thread INAGAKI Hiroshi
The system status LED on Panasonic Switch-M8eG PN28080K is connected to a PCA9539PW. To use the LED as a status LED of OpenWrt while booting, enable the pca953x driver and built-in to the kernel. Signed-off-by: INAGAKI Hiroshi --- target/linux/realtek/config-5.10 | 3 +++ target/linux/realtek/co

[PATCH-21.02] fix bug: NETDEV WATCHDOG: eth0 (mtk_SOC_eth): Transmit Queue 0 timed out Use flow control or BQL maybe lead to bug. Iperf3 was used for 24 hours, Transmit Queue 0 timed out may occur. ex

2021-10-03 Thread daxiong
Signed-off-by: daxiong --- ...iatek-ethernet-transmit-queue-timeout-bug.patch | 113 + 1 file changed, 113 insertions(+) create mode 100644 target/linux/ramips/patches-5.4/500-mediatek-ethernet-transmit-queue-timeout-bug.patch diff --git a/target/linux/ramips/patches-5.4/5

RE: [PATCH-21.02] fix bug: NETDEV WATCHDOG: eth0 (mtk_SOC_eth): Transmit Queue 0 timed out Use flow control or BQL maybe lead to bug. Iperf3 was used for 24 hours, Transmit Queue 0 timed out may occur

2021-10-03 Thread Adrian Schmutzler
Hi, > -Original Message- > From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org] > On Behalf Of daxiong > Sent: Sonntag, 3. Oktober 2021 13:03 > To: openwrt-devel@lists.openwrt.org > Subject: [PATCH-21.02] fix bug: NETDEV WATCHDOG: eth0 (mtk_SOC_eth): > Transmit Queue 0 time

mediatek: fix NETDEV WATCHDOG: eth0 (mtk_SOC_eth): Transmit queue 0 timed out

2021-10-03 Thread daxiong
Use flow control or BQL maybe lead to bug. Iperf3 was usedfor 24 hours, Transmit Queue 0 timed out may occur. example: Server: iperf3 -s Client: iperf3 -c 172.16.10.20 Signed-off-by: daxiong --- ...iatek-ethernet-transmit-queue-timeout-bug.patch | 109 + 1 file changed

RE: mediatek: fix NETDEV WATCHDOG: eth0 (mtk_SOC_eth): Transmit queue 0 timed out

2021-10-03 Thread Adrian Schmutzler
Hi, > -Original Message- > From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org] > On Behalf Of daxiong > Sent: Sonntag, 3. Oktober 2021 13:35 > To: openwrt-devel@lists.openwrt.org > Subject: mediatek: fix NETDEV WATCHDOG: eth0 (mtk_SOC_eth): Transmit > queue 0 timed out >

RFC: toolchain for building eBPF modules within the OpenWrt build system

2021-10-03 Thread Felix Fietkau
Hi, I recently spent some time digging into what's needed for proper eBPF build support in OpenWrt. Here's what I found so far: Most out-of-tree eBPF based projects fork some of the BPF related kernel headers from various different kernel versions and manually maintain those forks. These header

[PATCH 2/4] zynq: kernel: copy config from 5.4 to 5.10

2021-10-03 Thread Luis Araneda
Signed-off-by: Luis Araneda --- target/linux/zynq/config-5.10 | 553 ++ 1 file changed, 553 insertions(+) create mode 100644 target/linux/zynq/config-5.10 diff --git a/target/linux/zynq/config-5.10 b/target/linux/zynq/config-5.10 new file mode 100644 index 00

[PATCH 0/4] zynq: add support for kernel 5.10 and switch to it by default

2021-10-03 Thread Luis Araneda
This series adds support for kernel 5.10 and then switches to it by default. As the series is introducing and switching to 5.10, I didn't want to remove 5.4 files to give some time in case regressions appear. compile-tested: all devices from target run-tested: Digilent Zybo Z7-20 Signed-off-by:

[PATCH 1/4] zynq: kernel: refresh config

2021-10-03 Thread Luis Araneda
using "make kernel_oldconfig" Several configs are now part of generic Signed-off-by: Luis Araneda --- target/linux/zynq/config-5.4 | 96 +--- 1 file changed, 2 insertions(+), 94 deletions(-) diff --git a/target/linux/zynq/config-5.4 b/target/linux/zynq/config-5.

[PATCH 3/4] zynq: kernel: update config for 5.10

2021-10-03 Thread Luis Araneda
Update config with make kernel_oldconfig Signed-off-by: Luis Araneda --- target/linux/zynq/config-5.10 | 24 +--- 1 file changed, 13 insertions(+), 11 deletions(-) diff --git a/target/linux/zynq/config-5.10 b/target/linux/zynq/config-5.10 index 98b2bd0f93..aad769d319 100644

[PATCH 4/4] zynq: switch to kernel 5.10

2021-10-03 Thread Luis Araneda
Use kernel 5.10 by default compile-tested: all devices from target run-tested: Digilent Zybo Z7-20 Signed-off-by: Luis Araneda --- target/linux/zynq/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/target/linux/zynq/Makefile b/target/linux/zynq/Makefile index b5988c9

[sdwalker/sdwalker.github.io] 25b5e5: This week's update

2021-10-03 Thread Stephen Walker via openwrt-devel
The sender domain has a DMARC Reject/Quarantine policy which disallows sending mailing list messages using the original "From" header. To mitigate this problem, the original message has been wrapped automatically by the mailing list software.--- Begin Message --- Branch: refs/heads/master Home

Re: mediatek: fix NETDEV WATCHDOG: eth0 (mtk_SOC_eth): Transmit queue 0 timed out

2021-10-03 Thread Rosen Penev
On Sun, Oct 3, 2021 at 5:18 AM Adrian Schmutzler wrote: > > Hi, > > > -Original Message- > > From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org] > > On Behalf Of daxiong > > Sent: Sonntag, 3. Oktober 2021 13:35 > > To: openwrt-devel@lists.openwrt.org > > Subject: mediatek:

Re: RFC: toolchain for building eBPF modules within the OpenWrt build system

2021-10-03 Thread Rosen Penev
On Sun, Oct 3, 2021 at 5:47 AM Felix Fietkau wrote: > > > Hi, > > I recently spent some time digging into what's needed for proper eBPF > build support in OpenWrt. Here's what I found so far: > > Most out-of-tree eBPF based projects fork some of the BPF related kernel > headers from various differ

Re: Removing 5.4 support for bcm27xx and bcm53xx

2021-10-03 Thread Álvaro Fernández Rojas
Hi Adrian, No objections from me for bcm27xx. Best regards, Álvaro. > El 2 oct 2021, a las 18:43, Adrian Schmutzler > escribió: > > Hi, > > both bcm27xx and bcm53xx have kernel 5.10 by default for more than one > month. > > I'd like to remove 5.4 patches etc. there, so we don't have to bot

Suggestion: Explicitly warn to not use GitHub web UI for patches

2021-10-03 Thread Adrian Schmutzler
Hi, I've repeatedly made the observation that people who submit PRs with edits from GitHub's web interface cannot do history edits there when we request them. This leads to a lot of frustration both for the reviewers and the submitters. Eventually, it's mostly one of the following three undesirab

OpenWrt imx split status?

2021-10-03 Thread Tim Harvey
Piotr, How is your progress regarding submitting patches to OpenWrt to split the imx target into multiple arch related subtargets (like cortexa7, cortexa9)? Is anyone working on i.MX8 support that you know of? I have seen people ask for it in the past but nobody has been persistent about it. Bes

Re: [PATCH v4 0/6] at91: add support for sama5d2 icp, sama5d27 wlsom1 ek and sam9x60ek

2021-10-03 Thread Hauke Mehrtens
On 9/20/21 11:27 AM, Claudiu Beznea wrote: Hi, This series adds support for SAMA5D2 ICP, SAMA5D27-WLSOM1-EK and SAM9X60EK boards. Since SAM9X60's kernel support is included in 5.10 but not on 5.4 1st (patch 1/6) switches to kernel 5.10. Patches 2/6, 5/6 updates the kernel config for sam9x SoCs

Re: [PATCH v4 1/6] at91: kernel: bump to 5.10

2021-10-03 Thread Hauke Mehrtens
On 9/20/21 11:27 AM, Claudiu Beznea wrote: Bump at91 targets to kernel v5.10. With this patches and files for wb45n and wb50n were removed as they are now included in upstream kernel. Along with: - this the kernel config for sam9x targets has been refreshed (with make kernel_menuconfig + save)

Re: [PATCH v4 2/6] at91: enable specific sam9x kernel config flags

2021-10-03 Thread Hauke Mehrtens
On 9/20/21 11:27 AM, Claudiu Beznea wrote: Enable specific sam9x kernel config flags. Signed-off-by: Claudiu Beznea --- target/linux/at91/sam9x/config-default | 168 +++-- 1 file changed, 159 insertions(+), 9 deletions(-) diff --git a/target/linux/at91/sam9x/config-defau

Re: [PATCH] ramips: switch to kernel 5.10

2021-10-03 Thread Ilya Lipnitskiy
Hi Adrian, On Wed, Sep 29, 2021 at 1:34 PM Stijn Segers wrote: > > Hi Ilya, > > Op maandag 27 september 2021 om 19u11 schreef Ilya Lipnitskiy > : > > Hi Stijn, > > > >> >> >all mt7620 JBOOT devices will be broken. > > ... > >> $ grep \ KERNEL_SIZE image/mt7620.mk|wc -l > >> 1 > > That one is

[PATCH] Revert "swconfig: fix Broadcom b53 support"

2021-10-03 Thread Rafał Miłecki
From: Rafał Miłecki This reverts commit 8f9cd1af0f9c325a902dbd0e79e12015372e6bb0. That commit was meant to add a single EXPORT_SYMBOL_GPL() but it actually also added few .of_match_table-s. One commit should handle one thing and should not introduce unrelated changes. Regarding actual changes: