[PATCH v2] kernel: DSA roaming fix for Marvell mv88e6xxx
Marvell mv88e6xxx switch series cannot perform MAC learning from
CPU-injected (FROM_CPU) DSA frames, which results in 2 issues.
- excessive flooding, due to the fact that DSA treats those addresses
as unknown
- the risk of stale routes, which can lead to temporary packet loss
Backport those patch series from netdev mailing list, which solve these
issues by adding and clearing static entries to the switch's FDB.
Add a hack patch to set default VID to 1 in port_fdb_{add,del}. Otherwise
the static entries will be added to the switch's private FDB if VLAN
filtering disabled, which will not work.
The switch may generate an "ATU violation" warning when a client moves
from the CPU port to a switch port because the static ATU entry added by
DSA core still points to the CPU port. DSA core will then clear the static
entry so it is not fatal. Disable the warning so it will not confuse users.
Link: https://lore.kernel.org/netdev/20210106095136.224739-1-olte...@gmail.com/
Link:
https://lore.kernel.org/netdev/20210116012515.3152-1-tob...@waldekranz.com/
Ref: https://gitlab.nic.cz/turris/turris-build/-/issues/165
Signed-off-by: DENG Qingfang
---
v1 -> v2:
Dropped upstreamed patch
Also backported to 5.10
...y-switchdev-of-disappearance-of-old-.patch | 126 +
...r-when-a-non-legacy-FDB-operation-fa.patch | 52
...e-switchdev_notifier_fdb_info-in-dsa.patch | 226 +++
...tchdev-event-implementation-under-th.patch | 85 ++
...ly-in-dsa_slave_switchdev_event-if-w.patch | 42 +++
...or-SWITCHDEV_-FDB-DEL-_ADD_TO_DEVICE.patch | 264 ++
...y-switchdev-of-disappearance-of-old-.patch | 126 +
...r-when-a-non-legacy-FDB-operation-fa.patch | 52
...e-switchdev_notifier_fdb_info-in-dsa.patch | 226 +++
...tchdev-event-implementation-under-th.patch | 85 ++
...ly-in-dsa_slave_switchdev_event-if-w.patch | 42 +++
...or-SWITCHDEV_-FDB-DEL-_ADD_TO_DEVICE.patch | 263 +
.../710-net-dsa-mv88e6xxx-default-VID-1.patch | 18 ++
...-dsa-mv88e6xxx-disable-ATU-violation.patch | 12 +
.../710-net-dsa-mv88e6xxx-default-VID-1.patch | 18 ++
...-dsa-mv88e6xxx-disable-ATU-violation.patch | 12 +
...hdev-Refactor-br_switchdev_fdb_notif.patch | 75 +
...hdev-Include-local-flag-in-FDB-notif.patch | 42 +++
...hdev-Send-FDB-notifications-for-host.patch | 94 +++
...local-addresses-in-assisted-CPU-port.patch | 36 +++
...bridge-addresses-in-assisted-CPU-por.patch | 30 ++
...tic-FDB-entries-on-foreign-interface.patch | 56
...equest-assisted-learning-on-CPU-port.patch | 27 ++
...hdev-Refactor-br_switchdev_fdb_notif.patch | 71 +
...hdev-Include-local-flag-in-FDB-notif.patch | 42 +++
...hdev-Send-FDB-notifications-for-host.patch | 94 +++
...local-addresses-in-assisted-CPU-port.patch | 36 +++
...bridge-addresses-in-assisted-CPU-por.patch | 30 ++
...tic-FDB-entries-on-foreign-interface.patch | 56
...equest-assisted-learning-on-CPU-port.patch | 27 ++
30 files changed, 2365 insertions(+)
create mode 100644
target/linux/generic/backport-5.10/770-v5.12-net-bridge-notify-switchdev-of-disappearance-of-old-.patch
create mode 100644
target/linux/generic/backport-5.10/771-v5.12-net-dsa-be-louder-when-a-non-legacy-FDB-operation-fa.patch
create mode 100644
target/linux/generic/backport-5.10/772-v5.12-net-dsa-don-t-use-switchdev_notifier_fdb_info-in-dsa.patch
create mode 100644
target/linux/generic/backport-5.10/773-v5.12-net-dsa-move-switchdev-event-implementation-under-th.patch
create mode 100644
target/linux/generic/backport-5.10/774-v5.12-net-dsa-exit-early-in-dsa_slave_switchdev_event-if-w.patch
create mode 100644
target/linux/generic/backport-5.10/775-v5.12-net-dsa-listen-for-SWITCHDEV_-FDB-DEL-_ADD_TO_DEVICE.patch
create mode 100644
target/linux/generic/backport-5.4/770-v5.12-net-bridge-notify-switchdev-of-disappearance-of-old-.patch
create mode 100644
target/linux/generic/backport-5.4/771-v5.12-net-dsa-be-louder-when-a-non-legacy-FDB-operation-fa.patch
create mode 100644
target/linux/generic/backport-5.4/772-v5.12-net-dsa-don-t-use-switchdev_notifier_fdb_info-in-dsa.patch
create mode 100644
target/linux/generic/backport-5.4/773-v5.12-net-dsa-move-switchdev-event-implementation-under-th.patch
create mode 100644
target/linux/generic/backport-5.4/774-v5.12-net-dsa-exit-early-in-dsa_slave_switchdev_event-if-w.patch
create mode 100644
target/linux/generic/backport-5.4/775-v5.12-net-dsa-listen-for-SWITCHDEV_-FDB-DEL-_ADD_TO_DEVICE.patch
create mode 100644
target/linux/generic/hack-5.10/710-net-dsa-mv88e6xxx-default-VID-1.patch
create mode 100644
target/linux/generic/hack-5.10/711-net-dsa-mv88e6xxx-disable-ATU-violation.patch
create mode 100644
target/linux/generic/hack-5.4/710-net-dsa-mv88e6xxx-default-VID-1.patch
create mode 100644
target/linux/generic/hack-5.4/711-net-dsa-mv88e6xxx-disable-ATU-violation.patch
create mode 100644
target/linux/generic/pending-5.10/762-
[PATCH] wolfssl: bump to v4.7.0-stable
Biggest fix for this version is CVE-2021-3336, which has already been
applied here. There are a couple of low severity security bug fixes as
well.
Three patches are no longer needed, and were removed; the one remaining
was refreshed.
Signed-off-by: Eneas U de Queiroz
---
This was run-tested with master on mvebu using uhttpd and hostapd, and
should be cherry-picked to 21.02, and 19.07. It was compile-tested with
21.02 and 19.07.
---
package/libs/wolfssl/Makefile | 6 +--
.../wolfssl/patches/010-CVE-2021-3336.patch | 53 ---
.../patches/100-disable-hardening-check.patch | 2 +-
...Fix-linking-against-hostapd-with-LTO.patch | 25 -
.../patches/120-enable-secret-callback.patch | 10
5 files changed, 4 insertions(+), 92 deletions(-)
delete mode 100644 package/libs/wolfssl/patches/010-CVE-2021-3336.patch
delete mode 100644
package/libs/wolfssl/patches/110-Fix-linking-against-hostapd-with-LTO.patch
delete mode 100644
package/libs/wolfssl/patches/120-enable-secret-callback.patch
diff --git a/package/libs/wolfssl/Makefile b/package/libs/wolfssl/Makefile
index 846351f06d..53cd932d1f 100644
--- a/package/libs/wolfssl/Makefile
+++ b/package/libs/wolfssl/Makefile
@@ -8,12 +8,12 @@
include $(TOPDIR)/rules.mk
PKG_NAME:=wolfssl
-PKG_VERSION:=4.6.0-stable
-PKG_RELEASE:=2
+PKG_VERSION:=4.7.0-stable
+PKG_RELEASE:=1
PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.gz
PKG_SOURCE_URL:=https://github.com/wolfSSL/wolfssl/archive/v$(PKG_VERSION)
-PKG_HASH:=053aefbb02d0b06b27c5e2df6875b4b587318755b7db9d6aa8d72206b310a848
+PKG_HASH:=b0e740b31d4d877d540ad50cc539a8873fc41af02bd3091c4357b403f7106e31
PKG_FIXUP:=libtool libtool-abiver
PKG_INSTALL:=1
diff --git a/package/libs/wolfssl/patches/010-CVE-2021-3336.patch
b/package/libs/wolfssl/patches/010-CVE-2021-3336.patch
deleted file mode 100644
index abb9bfdd9b..00
--- a/package/libs/wolfssl/patches/010-CVE-2021-3336.patch
+++ /dev/null
@@ -1,53 +0,0 @@
-From fad1e67677bf7797b6bd6e1f21a513c289d963a7 Mon Sep 17 00:00:00 2001
-From: Sean Parkinson
-Date: Thu, 21 Jan 2021 08:24:38 +1000
-Subject: [PATCH] TLS 1.3: ensure key for signature in CertificateVerify
-
- src/tls13.c | 18 +-
- 1 file changed, 13 insertions(+), 5 deletions(-)
-
a/src/tls13.c
-+++ b/src/tls13.c
-@@ -5624,28 +5624,36 @@ static int DoTls13CertificateVerify(WOLF
- #ifdef HAVE_ED25519
- if (args->sigAlgo == ed25519_sa_algo &&
-
!ssl->peerEd25519KeyPresent) {
--WOLFSSL_MSG("Oops, peer sent ED25519 key but not in verify");
-+WOLFSSL_MSG("Peer sent ED22519 sig but not ED22519 cert");
-+ret = SIG_VERIFY_E;
-+goto exit_dcv;
- }
- #endif
- #ifdef HAVE_ED448
- if (args->sigAlgo == ed448_sa_algo && !ssl->peerEd448KeyPresent) {
--WOLFSSL_MSG("Oops, peer sent ED448 key but not in verify");
-+WOLFSSL_MSG("Peer sent ED448 sig but not ED448 cert");
-+ret = SIG_VERIFY_E;
-+goto exit_dcv;
- }
- #endif
- #ifdef HAVE_ECC
- if (args->sigAlgo == ecc_dsa_sa_algo &&
-
!ssl->peerEccDsaKeyPresent) {
--WOLFSSL_MSG("Oops, peer sent ECC key but not in verify");
-+WOLFSSL_MSG("Peer sent ECC sig but not ECC cert");
-+ret = SIG_VERIFY_E;
-+goto exit_dcv;
- }
- #endif
- #ifndef NO_RSA
- if (args->sigAlgo == rsa_sa_algo) {
--WOLFSSL_MSG("Oops, peer sent PKCS#1.5 signature");
-+WOLFSSL_MSG("Peer sent PKCS#1.5 algo but not in certificate");
- ERROR_OUT(INVALID_PARAMETER, exit_dcv);
- }
- if (args->sigAlgo == rsa_pss_sa_algo &&
- (ssl->peerRsaKey == NULL ||
!ssl->peerRsaKeyPresent)) {
--WOLFSSL_MSG("Oops, peer sent RSA key but not in verify");
-+WOLFSSL_MSG("Peer sent RSA sig but not RSA cert");
-+ret = SIG_VERIFY_E;
-+goto exit_dcv;
- }
- #endif
-
diff --git a/package/libs/wolfssl/patches/100-disable-hardening-check.patch
b/package/libs/wolfssl/patches/100-disable-hardening-check.patch
index c2793285e7..c89ff1be9d 100644
--- a/package/libs/wolfssl/patches/100-disable-hardening-check.patch
+++ b/package/libs/wolfssl/patches/100-disable-hardening-check.patch
@@ -1,6 +1,6 @@
--- a/wolfssl/wolfcrypt/settings.h
+++ b/wolfssl/wolfcrypt/settings.h
-@@ -2248,7 +2248,7 @@ extern void uITRON4_free(void *p) ;
+@@ -2255,7 +2255,7 @@ extern void uITRON4_free(void *p) ;
#endif
/* warning for not using harden build options (default with ./configure) */
diff --git
a/package/libs/wolfssl/patches/110-Fix-linking-against-hostapd-with-LTO.patch
b/package/l
[sdwalker/sdwalker.github.io] 62822a: This week's update
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: https://github.com/sdwalker/sdwalker.github.io Commit: 62822a904f5c5c2eb94e2a65c1c67e0513a4252f https://github.com/sdwalker/sdwalker.github.io/commit/62822a904f5c5c2eb94e2a65c1c67e0513a4252f Author: Stephen Walker Date: 2021-02-21 (Sun, 21 Feb 2021) Changed paths: M uscan/index-18.06.html M uscan/index-19.07.html M uscan/index.html Log Message: --- This week's update --- End Message --- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Enabling SATA via SATA_DWC on Meraki MX60W / APM82181
I would like to get the HDD port on the MX60 / MX60W working.
Knowing that the APM82181 muxes PCIe and SATA, I tried replacing the
PCIe WLAN module with an mSATA one, and disabling PCIe in the MX60
device tree, but enabling SATA0/1:
--- a/target/linux/apm821xx/dts/meraki-mx60.dts
+++ b/target/linux/apm821xx/dts/meraki-mx60.dts
@@ -169,31 +169,46 @@
};
};
-&PCIE0 {
-/* Leave this enabled as u-boot on the MX60 will disable it for us */
+&SATA0 {
status = "okay";
+drive0: sata-port@0 {
+reg = <0>;
+};
+};
-/*
- * relevant lspci topology:
- *
- *-+-[:40]---00.0-[41-7f]00.0
- */
-
-bridge@64,0 {
-reg = <0x0040 0 0 0 0>;
-#address-cells = <3>;
-#size-cells = <2>;
-ranges;
-
-wifi0: wifi@65,0 {
-/* Atheros AR9380 2.4/5GHz */
-compatible = "pci168c,0030";
-reg = <0x0041 0 0 0 0>;
-interrupts = <1>; /* INTA */
-};
+&SATA1 {
+status = "okay";
+drive1: sata-port@0 {
+reg = <0>;
};
};
+
+/* &PCIE0 { */
+/* /\* Leave this enabled as u-boot on the MX60 will disable it
for us *\/ */
+/* status = "okay"; */
+
+/* /\* */
+/* * relevant lspci topology: */
+/* * */
+/* *-+-[:40]---00.0-[41-7f]00.0 */
+/* *\/ */
+
+/* bridge@64,0 { */
+/* reg = <0x0040 0 0 0 0>; */
+/* #address-cells = <3>; */
+/* #size-cells = <2>; */
+/* ranges; */
+
+/* wifi0: wifi@65,0 { */
+/* /\* Atheros AR9380 2.4/5GHz *\/ */
+/* compatible = "pci168c,0030"; */
+/* reg = <0x0041 0 0 0 0>; */
+/* interrupts = <1>; /\* INTA *\/ */
+/* }; */
+/* }; */
+/* }; */
+
&MSI {
status = "okay";
};
I also enabled CONFIG_SATA_DWC_DEBUG=y for all nand-boards before recompiling:
--- a/target/linux/apm821xx/nand/config-default
+++ b/target/linux/apm821xx/nand/config-default
@@ -14,7 +14,7 @@ CONFIG_ATA_BMDMA=y
CONFIG_SATA_PMP=y
CONFIG_GENERIC_PHY=y
CONFIG_SATA_DWC=y
-# CONFIG_SATA_DWC_DEBUG is not set
+CONFIG_SATA_DWC_DEBUG=y
CONFIG_SCSI=y
CONFIG_BLK_DEV_SD=y
CONFIG_GPIOLIB=y
I received repeated errors similar to those from a previous mailing list entry
on the AmigaOne (this line is approximate) : https://lkml.org/lkml/2016/4/23/116
sata-dwc 4bffd1000.sata: sata_dwc_error_intr SCR_ERROR=0x0002
intpr=0x0088 status=0x00d0 dma_intp=187 pending=0 issued=0
These errors eventually triggered a kernel oops the first time
around. On the second boot, I removed the mSATA card after the
repeated errors began - they stopped temporarily, but restarted upon
reapplication of the drive. They went away entirely after disabling
USB in the device tree, though still no drive appears.
--- a/target/linux/apm821xx/dts/meraki-mx60.dts
+++ b/target/linux/apm821xx/dts/meraki-mx60.dts
@@ -40,10 +40,10 @@
status = "okay";
};
-&USBOTG0 {
-status = "okay";
-dr_mode = "host";
-};
+/* &USBOTG0 { */
+/* status = "okay"; */
+/* dr_mode = "host"; */
+/* }; */
&EBC0 {
/* Buckminster has 1GiB of NAND */
I have soldered a SATA power+data header onto an MX60W's pads; I have
bridged solder on four points where 1nF 0102 SMD capacitor should have
been placed to avoid DC bias. Still, despite a WG Green 3.5" drive,
Sandisk U100 8GB 2.5" drive and Toshiba 250GB 2.5" HDD all certainly
powering on on boot, none of these were recognized; instead, I only
got a 'SATA link down' once the port had been probed and IRQs set up.
Does DesignWare SATA on the APM82181 require U-boot's involvement to
initialize? Or am I missing something from the OpenWrt side? Would
attempting to boot Debian instead be a good idea?
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH v2 4/5] mvebu: add 5.10 kernel config
Hi, Hauke, On Sun, 21 Feb 2021 at 19:09, Hauke Mehrtens wrote: > > Could you please try to update also the other subtargets in this patch > set and ask others to test this on some devices. > If you do not have these devices it should be fine that you only compile > tested them. Yes, that's the idea. Working on it. Thanks, Rui ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH v2 1/5] mvebu: copy 5.4 patches to 5.10
Hi, Hauke, On Sun, 21 Feb 2021 at 18:16, Hauke Mehrtens wrote: > > > If you copy the patches first could you also copy the kernel > configuration files, so it is easy to review them. The new iteration will have the kernel configuration files included in the copy, yes. Thanks, Rui ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH 21.02] feeds: freifunk: use mirror from openwrt.org
Perry [2021-02-21 14:13:15]: Hi, > I have submitted two PR's to remove the freifunk feed from master and > openwrt-21.02. thank you for the heads up, I'm just wondering why we should left openwrt-19.07[1] behind? 1. https://git.openwrt.org/2a3dbded93775aeaf28fbebbd6aada07c9f588c1 Cheers, Petr ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH v2 4/5] mvebu: add 5.10 kernel config
On 2/20/21 9:39 PM, Rui Salvaterra wrote: Hi, Tomasz, On Sat, 20 Feb 2021 at 16:55, Tomasz Maciej Nowak wrote: The cortexa53 and cortexa72 config refresh are missing, also some symbols could be split from this patch and added to generic config, so other targets refresh will produce smaller diffs. Comments inline. I have no a53/a72 hardware at all (I only have a9, the Omnia), so any changes to those targets will be completely untested. Maybe I should have made this point explicit. :/ Could you please try to update also the other subtargets in this patch set and ask others to test this on some devices. If you do not have these devices it should be fine that you only compile tested them. Hauke OpenPGP_0x93DD20630910B515.asc Description: application/pgp-keys OpenPGP_signature Description: OpenPGP digital signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH v2 1/5] mvebu: copy 5.4 patches to 5.10
On 2/20/21 10:48 PM, Rui Salvaterra wrote: [resending as reply to all, sorry about that] Hi, Tomasz, On Sat, 20 Feb 2021 at 16:55, Tomasz Maciej Nowak wrote: Hi Rui, aside from copying patches also files should be split, since some ESPRESSObin variants are merged upstream and with keeping files as they are now, we will overwrite changes done upstream. Additionally just a small nit inline. This is just a brainless copying. The idea is to split the bringup into logical steps, as suggested by Adrian Schmutzler [1]. Since setting the kernel testing version is the last of the patch series, this should have no influence at all in the build. Hi, If you copy the patches first could you also copy the kernel configuration files, so it is easy to review them. Hauke OpenPGP_0x93DD20630910B515.asc Description: application/pgp-keys OpenPGP_signature Description: OpenPGP digital signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH v2 3/5] mvebu: update the Turris Omnia device tree
On 2/21/21 12:06 PM, Tomasz Maciej Nowak wrote: W dniu 20.02.2021 o 21:26, Rui Salvaterra pisze: Hi, Tomasz, On Sat, 20 Feb 2021 at 16:55, Tomasz Maciej Nowak wrote: W dniu 20.02.2021 o 12:53, Rui Salvaterra pisze: Include support for the multicolor LEDs (software controlled, for now) and fix the hardware buffer management support, due to a missing mbus window. I see more stuff added then what the message says. Also some of changes are in Linus tree, please backport relevant patches with proper message and commit hash (git format-patch -1 ), and add proper index according to target/linux/generic/PATCHES. This is a complete backport of the current (Linux 5.11) Turris Omnia device tree, including the hardware buffer management fix. I squashed everyting in a single patch, as it seemed more logical. I can backport the individual patches, if you prefer. That's always preferred, since next person doing bump or backporting patches to the same component, won't have to track changes in individual files. I would prefer if you only do the kernel update in this patch series and do the additional backports for the Turris Omnia later when this was merged. It will only make this more complicated. Hauke OpenPGP_0x93DD20630910B515.asc Description: application/pgp-keys OpenPGP_signature Description: OpenPGP digital signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH v2 2/5] mvebu: refresh 5.10 patches
On 2/20/21 5:55 PM, Tomasz Maciej Nowak wrote: W dniu 20.02.2021 o 12:53, Rui Salvaterra pisze: Also delete already upstreamed patches/changes. Signed-off-by: Rui Salvaterra --- ...t-for-endpoint-to-be-ready-before-tr.patch | 50 --- ...-t-rely-on-jiffies-while-holding-spi.patch | 54 --- ...ntroduce-mvneta_update_stats-routine.patch | 95 -- ...duce-page-pool-API-for-sw-buffer-man.patch | 181 -- ...on-build_skb-in-mvneta_rx_swbm-poll-.patch | 303 - ...006-net-mvneta-add-basic-XDP-support.patch | 311 -- ...avoid_error_message_for_optional_IRQ.patch | 31 -- ...header-prefetch-in-mvneta_swbm_rx_fr.patch | 43 --- ...mvneta-make-tx-buffer-array-agnostic.patch | 210 .../009-net-mvneta-add-XDP_TX-support.patch | 175 -- ...fix-build-skb-for-bm-capable-devices.patch | 41 --- ...-arm64-dts-uDPU-remove-i2c-fast-mode.patch | 31 -- ...ts-uDPU-SFP-cages-support-3W-modules.patch | 34 -- ...on-page_pool_recycle_direct-in-mvnet.patch | 39 --- ...sallow-XDP-program-on-hardware-buffe.patch | 53 --- ...DP-support-if-sw-bm-is-used-as-fallb.patch | 67 ...in-link-immediately-after-enabling-t.patch | 60 ...7-PCI-aardvark-Improve-link-training.patch | 208 ...18-PCI-aardvark-Issue-PERST-via-GPIO.patch | 123 --- .../019-PCI-aardvark-Add-PHY-support.patch| 152 - ...l-armada-37xx-Set-pcie_reset_pin-to-.patch | 93 -- ...l-armada-37xx-Move-PCIe-comphy-handl.patch | 57 ...l-armada-37xx-Move-PCIe-max-link-spe.patch | 44 --- ...-arm64-dts-add-uDPU-i2c-bus-recovery.patch | 53 --- ...-t-touch-PCIe-registers-if-no-card-c.patch | 50 --- ...add-driver-for-LinkStation-power-off.patch | 207 ...-initialization-with-old-Marvell-s-A.patch | 44 --- ...l-espressobin-Add-ethernet-switch-al.patch | 88 - ...Mangle-bootloader-s-kernel-arguments.patch | 37 +-- ...-mvebu-armada-38x-enable-libata-leds.patch | 4 +- ...l-armada-3720-espressobin-add-ports-.patch | 26 -- .../patches-5.10/400-find_active_root.patch | 2 +- .../700-mvneta-tx-queue-workaround.patch | 6 +- ...-pci-mvebu-time-out-reset-on-link-up.patch | 6 +- 34 files changed, 18 insertions(+), 2960 deletions(-) delete mode 100644 target/linux/mvebu/patches-5.10/001-PCI-aardvark-Wait-for-endpoint-to-be-ready-before-tr.patch delete mode 100644 target/linux/mvebu/patches-5.10/002-PCI-aardvark-Don-t-rely-on-jiffies-while-holding-spi.patch delete mode 100644 target/linux/mvebu/patches-5.10/003-net-mvneta-introduce-mvneta_update_stats-routine.patch delete mode 100644 target/linux/mvebu/patches-5.10/004-net-mvneta-introduce-page-pool-API-for-sw-buffer-man.patch delete mode 100644 target/linux/mvebu/patches-5.10/005-net-mvneta-rely-on-build_skb-in-mvneta_rx_swbm-poll-.patch delete mode 100644 target/linux/mvebu/patches-5.10/006-net-mvneta-add-basic-XDP-support.patch delete mode 100644 target/linux/mvebu/patches-5.10/007-gpio-mvebu-avoid_error_message_for_optional_IRQ.patch delete mode 100644 target/linux/mvebu/patches-5.10/007-net-mvneta-move-header-prefetch-in-mvneta_swbm_rx_fr.patch delete mode 100644 target/linux/mvebu/patches-5.10/008-net-mvneta-make-tx-buffer-array-agnostic.patch delete mode 100644 target/linux/mvebu/patches-5.10/009-net-mvneta-add-XDP_TX-support.patch delete mode 100644 target/linux/mvebu/patches-5.10/010-net-mvneta-fix-build-skb-for-bm-capable-devices.patch delete mode 100644 target/linux/mvebu/patches-5.10/011-arm64-dts-uDPU-remove-i2c-fast-mode.patch delete mode 100644 target/linux/mvebu/patches-5.10/012-arm64-dts-uDPU-SFP-cages-support-3W-modules.patch delete mode 100644 target/linux/mvebu/patches-5.10/013-net-mvneta-rely-on-page_pool_recycle_direct-in-mvnet.patch delete mode 100644 target/linux/mvebu/patches-5.10/014-mvneta-driver-disallow-XDP-program-on-hardware-buffe.patch delete mode 100644 target/linux/mvebu/patches-5.10/015-net-mvneta-fix-XDP-support-if-sw-bm-is-used-as-fallb.patch delete mode 100644 target/linux/mvebu/patches-5.10/016-PCI-aardvark-Train-link-immediately-after-enabling-t.patch delete mode 100644 target/linux/mvebu/patches-5.10/017-PCI-aardvark-Improve-link-training.patch delete mode 100644 target/linux/mvebu/patches-5.10/018-PCI-aardvark-Issue-PERST-via-GPIO.patch delete mode 100644 target/linux/mvebu/patches-5.10/019-PCI-aardvark-Add-PHY-support.patch delete mode 100644 target/linux/mvebu/patches-5.10/020-arm64-dts-marvell-armada-37xx-Set-pcie_reset_pin-to-.patch delete mode 100644 target/linux/mvebu/patches-5.10/021-arm64-dts-marvell-armada-37xx-Move-PCIe-comphy-handl.patch delete mode 100644 target/linux/mvebu/patches-5.10/022-arm64-dts-marvell-armada-37xx-Move-PCIe-max-link-spe.patch delete mode 100644 target/linux/mvebu/patches-5.10/023-arm64-dts-add-uDPU-i2c-bus-recovery.patch delete mode 100644 target/linux/mvebu/patches-5.10/024-PCI-aardvark
Re: Host dependencies and checking them
On 20/02/21 23:52, Bas Mevissen wrote: Hi all, When starting a clean build (21.02 branch) on a clean Fedora 33 machine, I ran into the small issue of tools/autoconf failing to build. This was due to perl-File-Compare missing. I apparently missed that prerequisite. After installing said package, everything built fine. Looking at the instructions at https://openwrt.org/docs/guide-developer/build-system/install-buildsystem#prerequisites, listing all prerequisites, I at first did not find perl-File-Compare. It was only at the distribution specific instructions for CentOS/Fedora that it was mentioned. The main list does specifically mention perl-ExtUtils-MakeMaker and perl-Thread-Queue, so I wonder whether perl-File-Compare should be added there as well? It's better to add it, yes. Depending on distro you may or may not need to install a specific package for it, but if you can't build the core repo and its packages without it, then it should be added to the list. Another question regarding prerequisites: is python2 still a requirement for master and openwrt-21.02? afaik no, the migration to python 3 was completed years ago, only references for python2 are to make sure that the build system is NOT using it even if it's installed or left in the build folders from previous builds. Anyway, it made me wonder whether the prerequisites list and test for at least the core should be revised. I took a look at the current list and compared them to include/prereq-build.mk from current (2021-02-20) openwrt-21.02 branch: PREREQ prereq-build.mk needed result == asciidoc no no? Q bash yes yes OK binutils no yes ADD bzip2 yes yes OK flex no hostbuild -> no REMOVE git yes yes OK g++ yes (no IB) yes OK gcc yes (no IB) yes OK time no no? Q getopt yes yes OK gawk yes yes OK help2man no no? Q intltool-update no no? Q libelf-dev no yes ADD libz-dev no yes ADD make yes yes OK ncurses yes yes OK openssl no util&lib? Q patch yes yes OK perl ExtUtils- MakeMaker no ? Q perl Thread- Queue yes ? Q python2-dev no no >19.07? Q unzip yes yes OK wget yes yes OK xgettext no yes ADD xsltproc no no REMOVE zlib no yes ADD The file prereq-build.mk does check for a number of other utilities that are not in the list or only in the distribution specific requirements: Perl Data::Dumper tar find xargs seq grep stat perl (5.x) python (>=3.5) file rsync these should be probably added to the list, as the build won't start if these are missing. It wouldn't be a bad thing to update the prereq-build.mk file as well with the other missing things but I'm not a core developer and I'd rather not touch these things. Looking at the distro specific instructions, I noticed a variation in the advised mandatoty and optional packages to install per distro. For example, some install asciidoc, other ccache and so on. the variation is probably due to the fact that other packages that aren't part of core repo might need that and the user had enabled them, or that some options not enabled by default (like ccache) might need them. Also there might be just legacy information from older versions (or just wrong info) that nobody ever updated and got carried over by cargo culting. The distro-specific information is added and updated by users after all. I would like to help cleaning this up, both the code and the documentation. What I need is input on what are mandatory and what are optional prerequisites Mandatory prerequisites are things that are necessary for building core repository without package feeds, and most of that stuff should be listed in the prereq-build.mk. Optional is what is needed to build core repo with non-default options and to build other packages in the feeds. This is not strictly defined, in most cases it's the package's own source and build system that does the prerequisite check before building and throws errors if it does not find things so you can't just check in OpenWrt repositories. It might not be practical to map all prerequisites of all packages available, so you might just document how to deal with build failures for optional packages/options (i.e. how to
Re: [PATCH 21.02] feeds: freifunk: use mirror from openwrt.org
Hi, I have submitted two PR's to remove the freifunk feed from master and openwrt-21.02. https://github.com/openwrt/openwrt/pull/3900 https://github.com/openwrt/openwrt/pull/3901 The reasons for removing the feeds, outside of this email thread, can be read at https://github.com/freifunk/openwrt-packages/issues/37 Greetings, Perry On 2/16/21 1:54 PM, Adrian Schmutzler wrote: > Hi, > >> -Original Message- >> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org] >> On Behalf Of Petr Štetiar >> Sent: Dienstag, 16. Februar 2021 10:31 >> To: openwrt-devel@lists.openwrt.org >> Cc: Petr Štetiar >> Subject: [PATCH 21.02] feeds: freifunk: use mirror from openwrt.org >> >> We shouldn't rely on GitHub for anything serious for obvious reasons. >> >> References: >> https://github.com/openwrt/openwrt/pull/3701#issuecomment-770841946 >> Signed-off-by: Petr Štetiar >> --- >> >> We've recently got following notice from GitHub: >> >> "If we determine that a violation has occurred, we may need to disable the >> repository" >> >> BTW I find it quite weird, that we're using feed from external project and >> we >> don't have access there. This is for example issue now, where we wanted to >> prepare 21.02 release, but we can't even create branch in that feed >> repository, which is blocking builds[1]: >> >> Updating feed 'freifunk' from 'https://github.com/freifunk/openwrt- >> packages.git;openwrt-21.02' ... >> ... >> fatal: Remote branch openwrt-21.02 not found in upstream origin >> >> 1. http://buildbot.openwrt.org/openwrt- >> 21.02/images/builders/imx6%2Fgeneric/builds/1/steps/updatefeeds/logs/st >> dio > > In the discussion about adding this feed, there was only a very weak tendency > for the addition (I added it to master then): > > https://github.com/openwrt/openwrt/pull/3013 > > If this creates non-trivial problems/holdup or the maintainers are not > interested in moving, I think making the feed optional or removing it again > is the better option. > > Added Sven to the recipients. > > Best > > Adrian > >> >> feeds.conf.default | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/feeds.conf.default b/feeds.conf.default index >> 03bfacb620fd..7aa07a8916c1 100644 >> --- a/feeds.conf.default >> +++ b/feeds.conf.default >> @@ -2,7 +2,7 @@ src-git packages >> https://git.openwrt.org/feed/packages.git >> src-git luci https://git.openwrt.org/project/luci.git >> src-git routing https://git.openwrt.org/feed/routing.git >> src-git telephony https://git.openwrt.org/feed/telephony.git >> -src-git freifunk https://github.com/freifunk/openwrt-packages.git >> +src-git freifunk https://git.openwrt.org/feed/freifunk.git >> #src-git video https://github.com/openwrt/video.git >> #src-git targets https://github.com/openwrt/targets.git >> #src-git management https://github.com/openwrt- >> management/packages.git >> >> ___ >> openwrt-devel mailing list >> openwrt-devel@lists.openwrt.org >> https://lists.openwrt.org/mailman/listinfo/openwrt-devel > > > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel > ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH v2 4/5] mvebu: add 5.10 kernel config
W dniu 20.02.2021 o 21:39, Rui Salvaterra pisze: > Hi, Tomasz, > > On Sat, 20 Feb 2021 at 16:55, Tomasz Maciej Nowak wrote: >> >> The cortexa53 and cortexa72 config refresh are missing, also some symbols >> could be split from this patch and added to generic config, so other targets >> refresh will produce smaller diffs. Comments inline. > > I have no a53/a72 hardware at all (I only have a9, the Omnia), so any > changes to those targets will be completely untested. Maybe I should > have made this point explicit. :/ I assumed it's bump for whole target and reviewed as such, since the series name doesn't explicitly state it's for cortexa9. Anyway that's the point of KERNEL_TESTING_PATCHVER, to allow volunteers to test it and some could provide Tested-by tag (for example me) or point/submit a fix. > > [sniped] > >>> +# CONFIG_ARCH_MSTARV7 is not set >> Split from this commit and move to generic config. > > What do you mean? Split this specific kconfig symbol, or the whole block? All the symbols I pointed to, move them to generic config with separate commit before mvebu kernel 5.10 config refresh. > > [sniped] > >>> +# CONFIG_LEDS_TURRIS_OMNIA is not set >> >> You are adding LEDs node to dts but the driver still is disabled, do the >> LEDs work without it? If not, make it built-in or package as module. > > I'm not adding any features yet. First, I want to get to a point where > the system runs exactly as it would run with 5.4. New features will > come afterwards (in this case, as a module, of course). So there's no point to add changes to Omnia dts (add hw buf management to Your other series, when kernel bump is merged), introduce them when You'll activate the features, in single series of patches. Also doing raw kernel bump will speed up the review/merge process. > > [sniped] > > Thanks, > Rui > -- TMN ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH v2 3/5] mvebu: update the Turris Omnia device tree
W dniu 20.02.2021 o 21:26, Rui Salvaterra pisze: > Hi, Tomasz, > > On Sat, 20 Feb 2021 at 16:55, Tomasz Maciej Nowak wrote: >> >> W dniu 20.02.2021 o 12:53, Rui Salvaterra pisze: >>> Include support for the multicolor LEDs (software controlled, for now) and >>> fix >>> the hardware buffer management support, due to a missing mbus window. >> >> I see more stuff added then what the message says. Also some of changes are >> in Linus tree, please backport relevant patches with proper message and >> commit hash (git format-patch -1 ), and add proper index according to >> target/linux/generic/PATCHES. > > This is a complete backport of the current (Linux 5.11) Turris Omnia > device tree, including the hardware buffer management fix. I squashed > everyting in a single patch, as it seemed more logical. I can backport > the individual patches, if you prefer. That's always preferred, since next person doing bump or backporting patches to the same component, won't have to track changes in individual files. > > Thanks, > Rui > -- TMN ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH v2 1/5] mvebu: copy 5.4 patches to 5.10
W dniu 20.02.2021 o 20:46, Rui Salvaterra pisze: > Hi, Tomasz, > > On Sat, 20 Feb 2021 at 16:55, Tomasz Maciej Nowak wrote: >> >> Hi Rui, >> >> aside from copying patches also files should be split, since some >> ESPRESSObin variants are merged upstream and with keeping files as they are >> now, we will overwrite changes done upstream. >> Additionally just a small nit inline. > > This is just a brainless copying. The idea is to split the bringup > into logical steps, as suggested by Adrian Schmutzler [1]. Since > setting the kernel testing version is the last of the patch series, > this should have no influence at all in the build. Adrian also mentioned "files". You can treat "files" as patches since they add/replace files in kernel source tree. I was missing this change, so commented here, since that's the closest. You can check my tree as I also suggested that to Sebastian in [2]. 2. http://lists.infradead.org/pipermail/openwrt-devel/2021-February/033868.html > >> W dniu 20.02.2021 o 12:53, Rui Salvaterra pisze: >>> >>> create mode 100644 >>> target/linux/mvebu/patches-5.10/312-ARM-dts-armada388-clearfog-emmc-on-clearfog-base.patch >>> create mode 100644 >>> target/linux/mvebu/patches-5.10/312-helios4-dts-status-led-alias.patch >> >> I missed this, when sorting patches. When copying please change the index of >> helios4-dts-status-led-alias.patch to 313. > > Will do, thanks! > > Rui > > [1] https://github.com/openwrt/openwrt/pull/3886#issuecomment-781562000 > -- TMN ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
