[PATCH 1/4] packages/x86: detect architecture, not x86/64 target

2023-03-12 Thread Elliott Mitchell 
These spots should be detecting the amd64 architecture, not the
specific target name.  If additional amd64 targets were added, or
the target was renamed, these would fail to build.

Signed-off-by: Elliott Mitchell 
---
 package/firmware/intel-microcode/Makefile | 2 +-
 package/kernel/linux/modules/crypto.mk| 2 +-
 package/kernel/linux/modules/virt.mk  | 4 ++--
 package/libs/wolfssl/Makefile | 2 +-
 target/linux/x86/modules.mk   | 4 ++--
 5 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/package/firmware/intel-microcode/Makefile 
b/package/firmware/intel-microcode/Makefile
index 58ae7ee74b..750d7db26d 100644
--- a/package/firmware/intel-microcode/Makefile
+++ b/package/firmware/intel-microcode/Makefile
@@ -18,7 +18,7 @@ PKG_BUILD_DIR:=$(BUILD_DIR)/intel-microcode-3.$(PKG_VERSION).1
 
 PKG_BUILD_DEPENDS:=iucode-tool/host
 
-ifdef CONFIG_TARGET_x86_64
+ifdef CONFIG_x86_64
MICROCODE:="intel-microcode-64"
 else
MICROCODE:="intel-microcode"
diff --git a/package/kernel/linux/modules/crypto.mk 
b/package/kernel/linux/modules/crypto.mk
index 83048e50d3..91b283cce6 100644
--- a/package/kernel/linux/modules/crypto.mk
+++ b/package/kernel/linux/modules/crypto.mk
@@ -722,7 +722,7 @@ define KernelPackage/crypto-misc
   $(call AddDepends/crypto)
 endef
 
-ifndef CONFIG_TARGET_x86_64
+ifndef CONFIG_x86_64
   define KernelPackage/crypto-misc/x86
 FILES+= \
$(LINUX_DIR)/arch/x86/crypto/twofish-i586.ko \
diff --git a/package/kernel/linux/modules/virt.mk 
b/package/kernel/linux/modules/virt.mk
index 59a2d79563..d572a873df 100644
--- a/package/kernel/linux/modules/virt.mk
+++ b/package/kernel/linux/modules/virt.mk
@@ -77,7 +77,7 @@ $(eval $(call KernelPackage,kvm-amd))
 define KernelPackage/vfio
   SUBMENU:=Virtualization
   TITLE:=VFIO Non-Privileged userspace driver framework
-  DEPENDS:=@TARGET_x86_64
+  DEPENDS:=@x86_64
   KCONFIG:= \
CONFIG_VFIO \
CONFIG_VFIO_NOIOMMU=n \
@@ -99,7 +99,7 @@ $(eval $(call KernelPackage,vfio))
 define KernelPackage/vfio-pci
   SUBMENU:=Virtualization
   TITLE:=Generic VFIO support for any PCI device
-  DEPENDS:=@TARGET_x86_64 @PCI_SUPPORT +kmod-vfio +kmod-irqbypass
+  DEPENDS:=@x86_64 @PCI_SUPPORT +kmod-vfio +kmod-irqbypass
   KCONFIG:= \
CONFIG_VFIO_PCI \
CONFIG_VFIO_PCI_IGD=y
diff --git a/package/libs/wolfssl/Makefile b/package/libs/wolfssl/Makefile
index 6ad44a9acf..b21ccde5df 100644
--- a/package/libs/wolfssl/Makefile
+++ b/package/libs/wolfssl/Makefile
@@ -188,7 +188,7 @@ else ifdef CONFIG_aarch64
 CONFIGURE_ARGS += --enable-armasm
 TARGET_CFLAGS:=$(TARGET_CFLAGS:-mcpu%=-mcpu%+crypto)
 
Package/libwolfsslcpu-crypto/preinst=$(Package/libwolfsslcpu-crypto/preinst-aarch64)
-else ifdef CONFIG_TARGET_x86_64
+else ifdef CONFIG_x86_64
CONFIGURE_ARGS += --enable-intelasm
 endif
 
diff --git a/target/linux/x86/modules.mk b/target/linux/x86/modules.mk
index e0c3b4174f..a63ad725c7 100644
--- a/target/linux/x86/modules.mk
+++ b/target/linux/x86/modules.mk
@@ -5,7 +5,7 @@
 define KernelPackage/amazon-ena
   SUBMENU:=$(NETWORK_DEVICES_MENU)
   TITLE:=Elastic Network Adapter (for Amazon AWS T3)
-  DEPENDS:=@TARGET_x86_64
+  DEPENDS:=@x86_64
   KCONFIG:=CONFIG_ENA_ETHERNET
   FILES:=$(LINUX_DIR)/drivers/net/ethernet/amazon/ena/ena.ko
   AUTOLOAD:=$(call AutoLoad,12,ena)
@@ -22,7 +22,7 @@ $(eval $(call KernelPackage,amazon-ena))
 define KernelPackage/amd-xgbe
   SUBMENU:=$(NETWORK_DEVICES_MENU)
   TITLE:=AMD Ethernet on SoC support
-  DEPENDS:=@PCI_SUPPORT @TARGET_x86_64 +kmod-lib-crc32c +kmod-ptp +kmod-libphy 
+(LINUX_5_10||LINUX_5_15):kmod-mdio-devres
+  DEPENDS:=@PCI_SUPPORT @x86_64 +kmod-lib-crc32c +kmod-ptp +kmod-libphy 
+(LINUX_5_10||LINUX_5_15):kmod-mdio-devres
   KCONFIG:=CONFIG_AMD_XGBE
   FILES:=$(LINUX_DIR)/drivers/net/ethernet/amd/xgbe/amd-xgbe.ko
   AUTOLOAD:=$(call AutoLoad,35,amd-xgbe)
-- 
2.30.2


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[PATCH 4/4] kernel/x86: move "64" to "generic"

2023-03-12 Thread Elliott Mitchell 
Point "generic" at amd64 which is far more important to nearly
everyone.

Signed-off-by: Elliott Mitchell 
---
 package/kernel/linux/modules/virt.mk| 2 +-
 target/linux/x86/Makefile   | 2 +-
 .../x86/{64 => generic}/base-files/lib/preinit/45_mount_xenfs   | 0
 target/linux/x86/{64 => generic}/config-5.10| 0
 target/linux/x86/{64 => generic}/config-5.15| 0
 target/linux/x86/{64 => generic}/target.mk  | 2 +-
 6 files changed, 3 insertions(+), 3 deletions(-)
 rename target/linux/x86/{64 => generic}/base-files/lib/preinit/45_mount_xenfs 
(100%)
 rename target/linux/x86/{64 => generic}/config-5.10 (100%)
 rename target/linux/x86/{64 => generic}/config-5.15 (100%)
 rename target/linux/x86/{64 => generic}/target.mk (85%)

diff --git a/package/kernel/linux/modules/virt.mk 
b/package/kernel/linux/modules/virt.mk
index d0fd4d72cc..fb2e7ccb24 100644
--- a/package/kernel/linux/modules/virt.mk
+++ b/package/kernel/linux/modules/virt.mk
@@ -18,7 +18,7 @@ $(eval $(call KernelPackage,irqbypass))
 define KernelPackage/kvm-x86
   SUBMENU:=Virtualization
   TITLE:=Kernel-based Virtual Machine (KVM) support
-  DEPENDS:=@TARGET_x86_generic||TARGET_x86_64||TARGET_x86_i686 +kmod-irqbypass
+  DEPENDS:=@TARGET_x86_generic||TARGET_x86_i686 +kmod-irqbypass
   KCONFIG:=\
  CONFIG_KVM \
  CONFIG_KVM_MMU_AUDIT=n \
diff --git a/target/linux/x86/Makefile b/target/linux/x86/Makefile
index 22bafb8d05..f2e9681621 100644
--- a/target/linux/x86/Makefile
+++ b/target/linux/x86/Makefile
@@ -8,7 +8,7 @@ ARCH:=i386
 BOARD:=x86
 BOARDNAME:=x86
 FEATURES:=squashfs ext4 vdi vmdk vhdx pcmcia targz fpu boot-part rootfs-part
-SUBTARGETS:=legacy geode 64 i686
+SUBTARGETS:=generic legacy geode i686
 
 KERNEL_PATCHVER:=5.15
 
diff --git a/target/linux/x86/64/base-files/lib/preinit/45_mount_xenfs 
b/target/linux/x86/generic/base-files/lib/preinit/45_mount_xenfs
similarity index 100%
rename from target/linux/x86/64/base-files/lib/preinit/45_mount_xenfs
rename to target/linux/x86/generic/base-files/lib/preinit/45_mount_xenfs
diff --git a/target/linux/x86/64/config-5.10 
b/target/linux/x86/generic/config-5.10
similarity index 100%
rename from target/linux/x86/64/config-5.10
rename to target/linux/x86/generic/config-5.10
diff --git a/target/linux/x86/64/config-5.15 
b/target/linux/x86/generic/config-5.15
similarity index 100%
rename from target/linux/x86/64/config-5.15
rename to target/linux/x86/generic/config-5.15
diff --git a/target/linux/x86/64/target.mk b/target/linux/x86/generic/target.mk
similarity index 85%
rename from target/linux/x86/64/target.mk
rename to target/linux/x86/generic/target.mk
index ece3d1bc9a..d0c4a69f58 100644
--- a/target/linux/x86/64/target.mk
+++ b/target/linux/x86/generic/target.mk
@@ -1,5 +1,5 @@
 ARCH:=x86_64
-BOARDNAME:=x86_64
+BOARDNAME:=Generic
 
 define Target/Description
 Build images for 64 bit systems including virtualized guests.
-- 
2.30.2


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[PATCH 3/4] kernel/x86: rename "generic" to i686

2023-03-12 Thread Elliott Mitchell 
There are few (if any) non-64-bit x86 processors currently in
production, therefore calling non-64-bit "generic" is a major
misnomer.

Signed-off-by: Elliott Mitchell 
---
 package/kernel/linux/modules/virt.mk| 2 +-
 target/linux/x86/Makefile   | 2 +-
 .../x86/{generic => i686}/base-files/lib/preinit/45_mount_xenfs | 0
 target/linux/x86/{generic => i686}/config-5.10  | 0
 target/linux/x86/{generic => i686}/config-5.15  | 0
 target/linux/x86/{generic => i686}/target.mk| 2 +-
 6 files changed, 3 insertions(+), 3 deletions(-)
 rename target/linux/x86/{generic => 
i686}/base-files/lib/preinit/45_mount_xenfs (100%)
 rename target/linux/x86/{generic => i686}/config-5.10 (100%)
 rename target/linux/x86/{generic => i686}/config-5.15 (100%)
 rename target/linux/x86/{generic => i686}/target.mk (92%)

diff --git a/package/kernel/linux/modules/virt.mk 
b/package/kernel/linux/modules/virt.mk
index d572a873df..d0fd4d72cc 100644
--- a/package/kernel/linux/modules/virt.mk
+++ b/package/kernel/linux/modules/virt.mk
@@ -18,7 +18,7 @@ $(eval $(call KernelPackage,irqbypass))
 define KernelPackage/kvm-x86
   SUBMENU:=Virtualization
   TITLE:=Kernel-based Virtual Machine (KVM) support
-  DEPENDS:=@TARGET_x86_generic||TARGET_x86_64 +kmod-irqbypass
+  DEPENDS:=@TARGET_x86_generic||TARGET_x86_64||TARGET_x86_i686 +kmod-irqbypass
   KCONFIG:=\
  CONFIG_KVM \
  CONFIG_KVM_MMU_AUDIT=n \
diff --git a/target/linux/x86/Makefile b/target/linux/x86/Makefile
index 5368a779e5..22bafb8d05 100644
--- a/target/linux/x86/Makefile
+++ b/target/linux/x86/Makefile
@@ -8,7 +8,7 @@ ARCH:=i386
 BOARD:=x86
 BOARDNAME:=x86
 FEATURES:=squashfs ext4 vdi vmdk vhdx pcmcia targz fpu boot-part rootfs-part
-SUBTARGETS:=generic legacy geode 64
+SUBTARGETS:=legacy geode 64 i686
 
 KERNEL_PATCHVER:=5.15
 
diff --git a/target/linux/x86/generic/base-files/lib/preinit/45_mount_xenfs 
b/target/linux/x86/i686/base-files/lib/preinit/45_mount_xenfs
similarity index 100%
rename from target/linux/x86/generic/base-files/lib/preinit/45_mount_xenfs
rename to target/linux/x86/i686/base-files/lib/preinit/45_mount_xenfs
diff --git a/target/linux/x86/generic/config-5.10 
b/target/linux/x86/i686/config-5.10
similarity index 100%
rename from target/linux/x86/generic/config-5.10
rename to target/linux/x86/i686/config-5.10
diff --git a/target/linux/x86/generic/config-5.15 
b/target/linux/x86/i686/config-5.15
similarity index 100%
rename from target/linux/x86/generic/config-5.15
rename to target/linux/x86/i686/config-5.15
diff --git a/target/linux/x86/generic/target.mk 
b/target/linux/x86/i686/target.mk
similarity index 92%
rename from target/linux/x86/generic/target.mk
rename to target/linux/x86/i686/target.mk
index 7e7f9f5a78..74cf434cb6 100644
--- a/target/linux/x86/generic/target.mk
+++ b/target/linux/x86/i686/target.mk
@@ -1,4 +1,4 @@
-BOARDNAME:=Generic
+BOARDNAME:=i686
 CPU_TYPE :=i686
 FEATURES += audio pci pcie usb
 
-- 
2.30.2


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[PATCH 2/4] kernel/x86: revert "generic" to i686 ("Pentium Pro")

2023-03-12 Thread Elliott Mitchell 
While many Intel P4 processors were produced, they do not represent
sufficient share of x86 to deserve an exclusive target.  i686 is
a much larger share.  Due to the feature of SMP, which was absent
from x86 before i686 this is still worthy of a distinct target.

Signed-off-by: Elliott Mitchell 
---
 target/linux/x86/generic/config-5.10 | 8 
 target/linux/x86/generic/config-5.15 | 8 
 target/linux/x86/generic/target.mk   | 4 ++--
 3 files changed, 10 insertions(+), 10 deletions(-)

diff --git a/target/linux/x86/generic/config-5.10 
b/target/linux/x86/generic/config-5.10
index b683720bf8..65540dc385 100644
--- a/target/linux/x86/generic/config-5.10
+++ b/target/linux/x86/generic/config-5.10
@@ -235,7 +235,7 @@ CONFIG_KVM_XFER_TO_GUEST_WORK=y
 # CONFIG_LANCE is not set
 CONFIG_LIBNVDIMM=y
 CONFIG_LOCK_SPIN_ON_OWNER=y
-# CONFIG_M686 is not set
+CONFIG_M686=y
 # CONFIG_MDA_CONSOLE is not set
 CONFIG_MEMORY_BALLOON=y
 CONFIG_MEMREGION=y
@@ -271,7 +271,7 @@ CONFIG_MOUSE_PS2_TRACKPOINT=y
 # CONFIG_MOUSE_PS2_VMMOUSE is not set
 # CONFIG_MOUSE_SERIAL is not set
 # CONFIG_MOUSE_VSXXXAA is not set
-CONFIG_MPENTIUM4=y
+# CONFIG_MPENTIUM4 is not set
 CONFIG_MUTEX_SPIN_ON_OWNER=y
 CONFIG_ND_BLK=y
 CONFIG_ND_BTT=y
@@ -411,8 +411,8 @@ CONFIG_X86_CPUID=y
 CONFIG_X86_HV_CALLBACK_VECTOR=y
 CONFIG_X86_INTEL_LPSS=y
 CONFIG_X86_INTEL_PSTATE=y
-CONFIG_X86_INTERNODE_CACHE_SHIFT=7
-CONFIG_X86_L1_CACHE_SHIFT=7
+CONFIG_X86_INTERNODE_CACHE_SHIFT=6
+CONFIG_X86_L1_CACHE_SHIFT=6
 # CONFIG_X86_LONGHAUL is not set
 CONFIG_X86_NEED_RELOCS=y
 CONFIG_X86_PAE=y
diff --git a/target/linux/x86/generic/config-5.15 
b/target/linux/x86/generic/config-5.15
index 1da6ad555d..e27046c195 100644
--- a/target/linux/x86/generic/config-5.15
+++ b/target/linux/x86/generic/config-5.15
@@ -242,7 +242,7 @@ CONFIG_KVM_XFER_TO_GUEST_WORK=y
 # CONFIG_LANCE is not set
 CONFIG_LIBNVDIMM=y
 CONFIG_LOCK_SPIN_ON_OWNER=y
-# CONFIG_M686 is not set
+CONFIG_M686=y
 # CONFIG_MDA_CONSOLE is not set
 CONFIG_MEMORY_BALLOON=y
 CONFIG_MEMREGION=y
@@ -278,7 +278,7 @@ CONFIG_MOUSE_PS2_TRACKPOINT=y
 # CONFIG_MOUSE_PS2_VMMOUSE is not set
 # CONFIG_MOUSE_SERIAL is not set
 # CONFIG_MOUSE_VSXXXAA is not set
-CONFIG_MPENTIUM4=y
+# CONFIG_MPENTIUM4 is not set
 CONFIG_MUTEX_SPIN_ON_OWNER=y
 CONFIG_ND_BLK=y
 CONFIG_ND_BTT=y
@@ -422,8 +422,8 @@ CONFIG_X86_CPUID=y
 CONFIG_X86_HV_CALLBACK_VECTOR=y
 CONFIG_X86_INTEL_LPSS=y
 CONFIG_X86_INTEL_PSTATE=y
-CONFIG_X86_INTERNODE_CACHE_SHIFT=7
-CONFIG_X86_L1_CACHE_SHIFT=7
+CONFIG_X86_INTERNODE_CACHE_SHIFT=6
+CONFIG_X86_L1_CACHE_SHIFT=6
 # CONFIG_X86_LONGHAUL is not set
 CONFIG_X86_NEED_RELOCS=y
 CONFIG_X86_PAE=y
diff --git a/target/linux/x86/generic/target.mk 
b/target/linux/x86/generic/target.mk
index 81a1d7a792..7e7f9f5a78 100644
--- a/target/linux/x86/generic/target.mk
+++ b/target/linux/x86/generic/target.mk
@@ -1,10 +1,10 @@
 BOARDNAME:=Generic
-CPU_TYPE :=pentium4
+CPU_TYPE :=i686
 FEATURES += audio pci pcie usb
 
 define Target/Description
Build firmware images for modern x86 based boards with CPUs
-   supporting at least the Intel Pentium 4 instruction set with
+   supporting at least the Intel Pentium Pro instruction set with
MMX, SSE and SSE2.
 endef
 
-- 
2.30.2


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[PATCH 0/4] Adjusting x86 Target Goals

2023-03-12 Thread Elliott Mitchell 
"Pentium4" was never generic for x86.  Certainly Intel made plenty of
P4s, and they kept their extras with the ia32-only Core processors.  Yet
this excludes all AMD processors, all Cyrix processors, and all Transmeta
processors.

Further while those extras do add value, the value is limited.  Meanwhile
"Pentium Pro"/"i686" add one item of great value, SMP support.  I've seen
several OSes/distributions target i686, but OpenWRT is the very first
I've seen which selected P4.

At this point calling a non-amd64 x86 build "generic" is a misnomer.
Certainly amd64 may not have flooded out earlier processors in the
embedded space, but it is only a matter of time.


Notes:  This has been confirmed to build, but this hasn't been well
checked and there could be bugs.  For OpenWRT one can argue "generic"
shouldn't point at amd64.  At a minimum though a x86 "generic" should
NOT point at non-amd64.


Elliott Mitchell (4):
  packages/x86: detect architecture, not x86/64 target
  kernel/x86: revert "generic" to i686 ("Pentium Pro")
  kernel/x86: rename "generic" to i686
  kernel/x86: move "64" to "generic"

 package/firmware/intel-microcode/Makefile |   2 +-
 package/kernel/linux/modules/crypto.mk|   2 +-
 package/kernel/linux/modules/virt.mk  |   6 +-
 package/libs/wolfssl/Makefile |   2 +-
 target/linux/x86/64/target.mk |   6 -
 target/linux/x86/Makefile |   2 +-
 target/linux/x86/generic/config-5.10  | 251 +---
 target/linux/x86/generic/config-5.15  | 267 +++---
 target/linux/x86/generic/target.mk|   8 +-
 .../base-files/lib/preinit/45_mount_xenfs |   0
 target/linux/x86/{64 => i686}/config-5.10 | 251 +++-
 target/linux/x86/{64 => i686}/config-5.15 | 267 +++---
 target/linux/x86/{generic => i686}/target.mk  |   6 +-
 target/linux/x86/modules.mk   |   4 +-
 14 files changed, 532 insertions(+), 542 deletions(-)
 delete mode 100644 target/linux/x86/64/target.mk
 rename target/linux/x86/{64 => i686}/base-files/lib/preinit/45_mount_xenfs 
(100%)
 rename target/linux/x86/{64 => i686}/config-5.10 (67%)
 rename target/linux/x86/{64 => i686}/config-5.15 (66%)
 copy target/linux/x86/{generic => i686}/target.mk (59%)

-- 
2.30.2


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[PATCH 4/4] realtek: handle changed flags in VLAN configuration

2023-03-12 Thread Jan Hoffmann 
The port_vlan_add method may be called while a port is already a member
of that VLAN, so it needs to be able to handle changed flags. Fix it to
properly handle when the PVID or UNTAGGED flag was previously set, but
now no longer is.

To reduce duplication, move PVID configuration to a separate function.

Signed-off-by: Jan Hoffmann 
---
 .../files-5.10/drivers/net/dsa/rtl83xx/dsa.c  | 41 ++-
 .../files-5.15/drivers/net/dsa/rtl83xx/dsa.c  | 37 +
 2 files changed, 43 insertions(+), 35 deletions(-)

diff --git a/target/linux/realtek/files-5.10/drivers/net/dsa/rtl83xx/dsa.c 
b/target/linux/realtek/files-5.10/drivers/net/dsa/rtl83xx/dsa.c
index 6fee8f646167..efeca23d2253 100644
--- a/target/linux/realtek/files-5.10/drivers/net/dsa/rtl83xx/dsa.c
+++ b/target/linux/realtek/files-5.10/drivers/net/dsa/rtl83xx/dsa.c
@@ -1454,6 +1454,20 @@ static int rtl83xx_vlan_prepare(struct dsa_switch *ds, 
int port,
return 0;
 }
 
+static void rtl83xx_vlan_set_pvid(struct rtl838x_switch_priv *priv,
+ int port, int pvid)
+{
+   /* Set both inner and outer PVID of the port */
+   priv->r->vlan_port_pvid_set(port, PBVLAN_TYPE_INNER, pvid);
+   priv->r->vlan_port_pvid_set(port, PBVLAN_TYPE_OUTER, pvid);
+   priv->r->vlan_port_pvidmode_set(port, PBVLAN_TYPE_INNER,
+   PBVLAN_MODE_UNTAG_AND_PRITAG);
+   priv->r->vlan_port_pvidmode_set(port, PBVLAN_TYPE_OUTER,
+   PBVLAN_MODE_UNTAG_AND_PRITAG);
+
+   priv->ports[port].pvid = pvid;
+}
+
 static void rtl83xx_vlan_add(struct dsa_switch *ds, int port,
const struct switchdev_obj_port_vlan *vlan)
 {
@@ -1472,19 +1486,11 @@ static void rtl83xx_vlan_add(struct dsa_switch *ds, int 
port,
 
mutex_lock(>reg_mutex);
 
-   if (vlan->flags & BRIDGE_VLAN_INFO_PVID) {
-   for (v = vlan->vid_begin; v <= vlan->vid_end; v++) {
-   if (!v)
-   continue;
-   /* Set both inner and outer PVID of the port */
-   priv->r->vlan_port_pvid_set(port, PBVLAN_TYPE_INNER, v);
-   priv->r->vlan_port_pvid_set(port, PBVLAN_TYPE_OUTER, v);
-   priv->r->vlan_port_pvidmode_set(port, PBVLAN_TYPE_INNER,
-   
PBVLAN_MODE_UNTAG_AND_PRITAG);
-   priv->r->vlan_port_pvidmode_set(port, PBVLAN_TYPE_OUTER,
-   
PBVLAN_MODE_UNTAG_AND_PRITAG);
-
-   priv->ports[port].pvid = vlan->vid_end;
+   for (v = vlan->vid_begin; v <= vlan->vid_end; v++) {
+   if (vlan->flags & BRIDGE_VLAN_INFO_PVID) {
+   rtl83xx_vlan_set_pvid(priv, port, v);
+   } else if (priv->ports[port].pvid == v) {
+   rtl83xx_vlan_set_pvid(priv, port, 0);
}
}
 
@@ -1507,6 +1513,8 @@ static void rtl83xx_vlan_add(struct dsa_switch *ds, int 
port,
info.tagged_ports |= BIT_ULL(port);
if (vlan->flags & BRIDGE_VLAN_INFO_UNTAGGED)
info.untagged_ports |= BIT_ULL(port);
+   else
+   info.untagged_ports &= ~BIT_ULL(port);
 
priv->r->vlan_set_untagged(v, info.untagged_ports);
pr_debug("Untagged ports, VLAN %d: %llx\n", v, 
info.untagged_ports);
@@ -1541,12 +1549,7 @@ static int rtl83xx_vlan_del(struct dsa_switch *ds, int 
port,
for (v = vlan->vid_begin; v <= vlan->vid_end; v++) {
/* Reset to default if removing the current PVID */
if (v == pvid) {
-   priv->r->vlan_port_pvid_set(port, PBVLAN_TYPE_INNER, 0);
-   priv->r->vlan_port_pvid_set(port, PBVLAN_TYPE_OUTER, 0);
-   priv->r->vlan_port_pvidmode_set(port, PBVLAN_TYPE_INNER,
-   
PBVLAN_MODE_UNTAG_AND_PRITAG);
-   priv->r->vlan_port_pvidmode_set(port, PBVLAN_TYPE_OUTER,
-   
PBVLAN_MODE_UNTAG_AND_PRITAG);
+   rtl83xx_vlan_set_pvid(priv, port, 0);
}
/* Get port memberships of this vlan */
priv->r->vlan_tables_read(v, );
diff --git a/target/linux/realtek/files-5.15/drivers/net/dsa/rtl83xx/dsa.c 
b/target/linux/realtek/files-5.15/drivers/net/dsa/rtl83xx/dsa.c
index 46296d191797..d24a488d66cf 100644
--- a/target/linux/realtek/files-5.15/drivers/net/dsa/rtl83xx/dsa.c
+++ b/target/linux/realtek/files-5.15/drivers/net/dsa/rtl83xx/dsa.c
@@ -1438,6 +1438,20 @@ static int rtl83xx_vlan_prepare(struct dsa_switch *ds, 
int port,
return 0;
 }
 
+static void rtl83xx_vlan_set_pvid(struct rtl838x_switch_priv *priv,
+ int port, int

[PATCH 3/4] realtek: fix standalone ports in presence of static fdb entries

2023-03-12 Thread Jan Hoffmann 
The registers L2_PORT_STATIC_MV_ACT seem to specify the action to take
when the source address of a packet exists as a static fdb entry on
another port. By default the configured action is to drop such packets.

For standalone ports, this behaviour is undesired, as all traffic should
be forwarded to the CPU. So change the action to forward on standalone
ports.

A situation where this issue can occur is when a non-offloaded bond
interface is part of a bridge. In that case, the CPU port will have fdb
entries for devices connected to the bond interface, which are managed
by the assisted learning feature.

For now, this is only implemented for RTL838x/RTL839x, as the available
set of registers differs for the other devices.

Signed-off-by: Jan Hoffmann 
---
 .../files-5.10/drivers/net/dsa/rtl83xx/dsa.c | 16 
 .../files-5.10/drivers/net/dsa/rtl83xx/rtl838x.c | 10 ++
 .../files-5.10/drivers/net/dsa/rtl83xx/rtl838x.h | 14 ++
 .../files-5.10/drivers/net/dsa/rtl83xx/rtl839x.c | 11 +++
 .../files-5.15/drivers/net/dsa/rtl83xx/dsa.c | 16 
 .../files-5.15/drivers/net/dsa/rtl83xx/rtl838x.c | 10 ++
 .../files-5.15/drivers/net/dsa/rtl83xx/rtl838x.h | 14 ++
 .../files-5.15/drivers/net/dsa/rtl83xx/rtl839x.c | 11 +++
 8 files changed, 102 insertions(+)

diff --git a/target/linux/realtek/files-5.10/drivers/net/dsa/rtl83xx/dsa.c 
b/target/linux/realtek/files-5.10/drivers/net/dsa/rtl83xx/dsa.c
index 5936f5e7d2c3..6fee8f646167 100644
--- a/target/linux/realtek/files-5.10/drivers/net/dsa/rtl83xx/dsa.c
+++ b/target/linux/realtek/files-5.10/drivers/net/dsa/rtl83xx/dsa.c
@@ -200,6 +200,15 @@ static int rtl83xx_setup(struct dsa_switch *ds)
}
priv->r->traffic_set(priv->cpu_port, BIT_ULL(priv->cpu_port));
 
+   /* For standalone ports, forward packets even if a static fdb
+* entry for the source address exists on another port.
+*/
+   if (priv->r->set_static_move_action) {
+   for (i = 0; i <= priv->cpu_port; i++) {
+   priv->r->set_static_move_action(i, true);
+   }
+   }
+
if (priv->family_id == RTL8380_FAMILY_ID)
rtl838x_print_matrix();
else
@@ -1220,6 +1229,10 @@ static int rtl83xx_port_bridge_join(struct dsa_switch 
*ds, int port,
priv->r->traffic_set(port, v);
}
priv->ports[port].pm |= port_bitmap;
+
+   if (priv->r->set_static_move_action)
+   priv->r->set_static_move_action(port, false);
+
mutex_unlock(>reg_mutex);
 
return 0;
@@ -1261,6 +1274,9 @@ static void rtl83xx_port_bridge_leave(struct dsa_switch 
*ds, int port,
}
priv->ports[port].pm &= ~port_bitmap;
 
+   if (priv->r->set_static_move_action)
+   priv->r->set_static_move_action(port, true);
+
mutex_unlock(>reg_mutex);
 }
 
diff --git a/target/linux/realtek/files-5.10/drivers/net/dsa/rtl83xx/rtl838x.c 
b/target/linux/realtek/files-5.10/drivers/net/dsa/rtl83xx/rtl838x.c
index 9ce50989790e..74ad03127687 100644
--- a/target/linux/realtek/files-5.10/drivers/net/dsa/rtl83xx/rtl838x.c
+++ b/target/linux/realtek/files-5.10/drivers/net/dsa/rtl83xx/rtl838x.c
@@ -559,6 +559,15 @@ static void rtl838x_enable_bcast_flood(int port, bool 
enable)
 
 }
 
+static void rtl838x_set_static_move_action(int port, bool forward)
+{
+   int shift = MV_ACT_PORT_SHIFT(port);
+   u32 val = forward ? MV_ACT_FORWARD : MV_ACT_DROP;
+
+   sw_w32_mask(MV_ACT_MASK << shift, val << shift,
+   RTL838X_L2_PORT_STATIC_MV_ACT(port));
+}
+
 static void rtl838x_stp_get(struct rtl838x_switch_priv *priv, u16 msti, u32 
port_state[])
 {
int i;
@@ -1750,6 +1759,7 @@ const struct rtl838x_reg rtl838x_reg = {
.enable_flood = rtl838x_enable_flood,
.enable_mcast_flood = rtl838x_enable_mcast_flood,
.enable_bcast_flood = rtl838x_enable_bcast_flood,
+   .set_static_move_action = rtl838x_set_static_move_action,
.stp_get = rtl838x_stp_get,
.stp_set = rtl838x_stp_set,
.mac_port_ctrl = rtl838x_mac_port_ctrl,
diff --git a/target/linux/realtek/files-5.10/drivers/net/dsa/rtl83xx/rtl838x.h 
b/target/linux/realtek/files-5.10/drivers/net/dsa/rtl83xx/rtl838x.h
index 19049e4c957a..3f1f1d49f8e7 100644
--- a/target/linux/realtek/files-5.10/drivers/net/dsa/rtl83xx/rtl838x.h
+++ b/target/linux/realtek/files-5.10/drivers/net/dsa/rtl83xx/rtl838x.h
@@ -251,6 +251,19 @@
 #define RTL930X_L2_PORT_NEW_SA_FWD(p)  (0x8FF4 + (((p / 10) << 2)))
 #define RTL931X_L2_PORT_NEW_SA_FWD(p)  (0xC830 + (((p / 10) << 2)))
 
+#define RTL838X_L2_PORT_MV_ACT(p)  (0x335c + (((p >> 4) << 2)))
+#define RTL839X_L2_PORT_MV_ACT(p)  (0x3b80 + (((p >> 4) << 2)))
+
+#define RTL838X_L2_PORT_STATIC_MV_ACT(p)   (0x327c + (((p >> 4) << 2)))
+#define RTL839X_L2_PORT_STATIC_MV_ACT(p)   (0x38dc + (((p >> 4) << 2)))
+
+#define

[PATCH 1/4] realtek: properly update port masks when port leaves bridge

2023-03-12 Thread Jan Hoffmann 
Correctly update the isolation mask of the port being configured. The
port_bitmap variable should contain all other bridge members and needs
to be actually removed from the isolation mask instead of added to it.

Also actually remove the port being configured from the pm field of the
other ports, so that any other ports that are currently disabled will be
configured correctly when they are enabled.

Signed-off-by: Jan Hoffmann 
---

I originally wanted to put a proper Fixes tag here, but I'm not sure
which commit to choose. This bug seems to have existed since this target
was introduced, and survived through multiple refactorings. It looks
like the incorrect update to the pm field was even fixed in 2b88563ee5aa
("realtek: update the tree to the latest refactored version"), but then
27029277f98d ("realtek: add switch driver support for the RTL93XX based
switches") reintroduced the issue.

 .../realtek/files-5.10/drivers/net/dsa/rtl83xx/dsa.c   | 10 +-
 .../realtek/files-5.15/drivers/net/dsa/rtl83xx/dsa.c   | 10 +-
 2 files changed, 10 insertions(+), 10 deletions(-)

diff --git a/target/linux/realtek/files-5.10/drivers/net/dsa/rtl83xx/dsa.c 
b/target/linux/realtek/files-5.10/drivers/net/dsa/rtl83xx/dsa.c
index 63461ff57348..220f1d5d281d 100644
--- a/target/linux/realtek/files-5.10/drivers/net/dsa/rtl83xx/dsa.c
+++ b/target/linux/realtek/files-5.10/drivers/net/dsa/rtl83xx/dsa.c
@@ -1227,7 +1227,7 @@ static void rtl83xx_port_bridge_leave(struct dsa_switch 
*ds, int port,
struct net_device *bridge)
 {
struct rtl838x_switch_priv *priv = ds->priv;
-   u64 port_bitmap = BIT_ULL(priv->cpu_port), v;
+   u64 port_bitmap = 0, v;
int i;
 
pr_debug("%s %x: %d", __func__, (u32)priv, port);
@@ -1245,16 +1245,16 @@ static void rtl83xx_port_bridge_leave(struct dsa_switch 
*ds, int port,
if (priv->ports[i].enable)
priv->r->traffic_disable(i, port);
 
-   priv->ports[i].pm |= BIT_ULL(port);
-   port_bitmap &= ~BIT_ULL(i);
+   priv->ports[i].pm &= ~BIT_ULL(port);
+   port_bitmap |= BIT_ULL(i);
}
}
store_mcgroups(priv, port);
 
-   /* Add all other ports to this port matrix. */
+   /* Remove all other ports from this port matrix. */
if (priv->ports[port].enable) {
v = priv->r->traffic_get(port);
-   v |= port_bitmap;
+   v &= ~port_bitmap;
priv->r->traffic_set(port, v);
}
priv->ports[port].pm &= ~port_bitmap;
diff --git a/target/linux/realtek/files-5.15/drivers/net/dsa/rtl83xx/dsa.c 
b/target/linux/realtek/files-5.15/drivers/net/dsa/rtl83xx/dsa.c
index 83a0441ce27c..7eebb2107f84 100644
--- a/target/linux/realtek/files-5.15/drivers/net/dsa/rtl83xx/dsa.c
+++ b/target/linux/realtek/files-5.15/drivers/net/dsa/rtl83xx/dsa.c
@@ -1212,7 +1212,7 @@ static void rtl83xx_port_bridge_leave(struct dsa_switch 
*ds, int port,
struct net_device *bridge)
 {
struct rtl838x_switch_priv *priv = ds->priv;
-   u64 port_bitmap = BIT_ULL(priv->cpu_port), v;
+   u64 port_bitmap = 0, v;
 
pr_debug("%s %x: %d", __func__, (u32)priv, port);
mutex_lock(>reg_mutex);
@@ -1229,16 +1229,16 @@ static void rtl83xx_port_bridge_leave(struct dsa_switch 
*ds, int port,
if (priv->ports[i].enable)
priv->r->traffic_disable(i, port);
 
-   priv->ports[i].pm |= BIT_ULL(port);
-   port_bitmap &= ~BIT_ULL(i);
+   priv->ports[i].pm &= ~BIT_ULL(port);
+   port_bitmap |= BIT_ULL(i);
}
}
store_mcgroups(priv, port);
 
-   /* Add all other ports to this port matrix. */
+   /* Remove all other ports from this port matrix. */
if (priv->ports[port].enable) {
v = priv->r->traffic_get(port);
-   v |= port_bitmap;
+   v &= ~port_bitmap;
priv->r->traffic_set(port, v);
}
priv->ports[port].pm &= ~port_bitmap;
-- 
2.39.1


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[PATCH 2/4] realtek: initialize port masks to match the default state

2023-03-12 Thread Jan Hoffmann 
All ports are disabled by default, so configure the port isolation masks
and the pm field accordingly in the setup function. When port_enable is
called for a port, the isolation masks will be set up so that traffic
can flow between the port and the CPU.

While at it, change the code to also use the traffic_set method in
rtl83xx_setup.

Signed-off-by: Jan Hoffmann 
---
 .../files-5.10/drivers/net/dsa/rtl83xx/dsa.c  | 22 ++-
 .../files-5.15/drivers/net/dsa/rtl83xx/dsa.c  | 22 ++-
 2 files changed, 24 insertions(+), 20 deletions(-)

diff --git a/target/linux/realtek/files-5.10/drivers/net/dsa/rtl83xx/dsa.c 
b/target/linux/realtek/files-5.10/drivers/net/dsa/rtl83xx/dsa.c
index 220f1d5d281d..5936f5e7d2c3 100644
--- a/target/linux/realtek/files-5.10/drivers/net/dsa/rtl83xx/dsa.c
+++ b/target/linux/realtek/files-5.10/drivers/net/dsa/rtl83xx/dsa.c
@@ -176,7 +176,6 @@ static int rtl83xx_setup(struct dsa_switch *ds)
 {
int i;
struct rtl838x_switch_priv *priv = ds->priv;
-   u64 port_bitmap = BIT_ULL(priv->cpu_port);
 
pr_debug("%s called\n", __func__);
 
@@ -187,18 +186,19 @@ static int rtl83xx_setup(struct dsa_switch *ds)
priv->ports[i].enable = false;
priv->ports[priv->cpu_port].enable = true;
 
-   /* Isolate ports from each other: traffic only CPU <-> port */
+   /* Configure ports so they are disabled by default, but once enabled
+* they will work in isolated mode (only traffic between port and CPU).
+*/
/* Setting bit j in register RTL838X_PORT_ISO_CTRL(i) allows
 * traffic from source port i to destination port j
 */
for (i = 0; i < priv->cpu_port; i++) {
if (priv->ports[i].phy) {
-   priv->r->set_port_reg_be(BIT_ULL(priv->cpu_port) | 
BIT_ULL(i),
- priv->r->port_iso_ctrl(i));
-   port_bitmap |= BIT_ULL(i);
+   priv->ports[i].pm = BIT_ULL(priv->cpu_port);
+   priv->r->traffic_set(i, BIT_ULL(i));
}
}
-   priv->r->set_port_reg_be(port_bitmap, 
priv->r->port_iso_ctrl(priv->cpu_port));
+   priv->r->traffic_set(priv->cpu_port, BIT_ULL(priv->cpu_port));
 
if (priv->family_id == RTL8380_FAMILY_ID)
rtl838x_print_matrix();
@@ -240,7 +240,6 @@ static int rtl93xx_setup(struct dsa_switch *ds)
 {
int i;
struct rtl838x_switch_priv *priv = ds->priv;
-   u32 port_bitmap = BIT(priv->cpu_port);
 
pr_info("%s called\n", __func__);
 
@@ -258,13 +257,16 @@ static int rtl93xx_setup(struct dsa_switch *ds)
priv->ports[i].enable = false;
priv->ports[priv->cpu_port].enable = true;
 
+   /* Configure ports so they are disabled by default, but once enabled
+* they will work in isolated mode (only traffic between port and CPU).
+*/
for (i = 0; i < priv->cpu_port; i++) {
if (priv->ports[i].phy) {
-   priv->r->traffic_set(i, BIT_ULL(priv->cpu_port) | 
BIT_ULL(i));
-   port_bitmap |= BIT_ULL(i);
+   priv->ports[i].pm = BIT_ULL(priv->cpu_port);
+   priv->r->traffic_set(i, BIT_ULL(i));
}
}
-   priv->r->traffic_set(priv->cpu_port, port_bitmap);
+   priv->r->traffic_set(priv->cpu_port, BIT_ULL(priv->cpu_port));
 
rtl930x_print_matrix();
 
diff --git a/target/linux/realtek/files-5.15/drivers/net/dsa/rtl83xx/dsa.c 
b/target/linux/realtek/files-5.15/drivers/net/dsa/rtl83xx/dsa.c
index 7eebb2107f84..05f00ef20765 100644
--- a/target/linux/realtek/files-5.15/drivers/net/dsa/rtl83xx/dsa.c
+++ b/target/linux/realtek/files-5.15/drivers/net/dsa/rtl83xx/dsa.c
@@ -167,7 +167,6 @@ static void rtl83xx_port_set_salrn(struct 
rtl838x_switch_priv *priv,
 static int rtl83xx_setup(struct dsa_switch *ds)
 {
struct rtl838x_switch_priv *priv = ds->priv;
-   u64 port_bitmap = BIT_ULL(priv->cpu_port);
 
pr_debug("%s called\n", __func__);
 
@@ -178,18 +177,19 @@ static int rtl83xx_setup(struct dsa_switch *ds)
priv->ports[i].enable = false;
priv->ports[priv->cpu_port].enable = true;
 
-   /* Isolate ports from each other: traffic only CPU <-> port */
+   /* Configure ports so they are disabled by default, but once enabled
+* they will work in isolated mode (only traffic between port and CPU).
+*/
/* Setting bit j in register RTL838X_PORT_ISO_CTRL(i) allows
 * traffic from source port i to destination port j
 */
for (int i = 0; i < priv->cpu_port; i++) {
if (priv->ports[i].phy) {
-   priv->r->set_port_reg_be(BIT_ULL(priv->cpu_port) | 
BIT_ULL(i),
- priv->r->port_iso_ctrl(i));
-   port_bitmap |= BIT_ULL(i);
+

[PATCH 0/4] realtek: fix multiple issues with L2 forwarding

2023-03-12 Thread Jan Hoffmann 
This series fixes several bugs that can result in packets being
forwarded incorrectly. The port isolation and VLAN issues probably
remained unnoticed so far, because they only manifest when after a port
leaves a bridge, or an existing VLAN membership is changed.

Jan Hoffmann (4):
  realtek: properly update port masks when port leaves bridge
  realtek: initialize port masks to match the default state
  realtek: fix standalone ports in presence of static fdb entries
  realtek: handle changed flags in VLAN configuration

 .../files-5.10/drivers/net/dsa/rtl83xx/dsa.c  | 89 ---
 .../drivers/net/dsa/rtl83xx/rtl838x.c | 10 +++
 .../drivers/net/dsa/rtl83xx/rtl838x.h | 14 +++
 .../drivers/net/dsa/rtl83xx/rtl839x.c | 11 +++
 .../files-5.15/drivers/net/dsa/rtl83xx/dsa.c  | 85 +++---
 .../drivers/net/dsa/rtl83xx/rtl838x.c | 10 +++
 .../drivers/net/dsa/rtl83xx/rtl838x.h | 14 +++
 .../drivers/net/dsa/rtl83xx/rtl839x.c | 11 +++
 8 files changed, 179 insertions(+), 65 deletions(-)

-- 
2.39.1


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: Reusable Github Actions and containers [Was: Re: [PATCH uci 2/2] CI: Add github action]

2023-03-12 Thread Hauke Mehrtens 

Hi Petr,

thanks for the comments.

These patches are my minimal version to get something running. I will 
try to extend it in the new few weeks.


On 3/11/23 09:57, Petr Štetiar wrote:

Hauke Mehrtens  [2023-03-09 00:18:10]:

Hi,

thanks for taking care, LGTM for a start.

I'll just provide my past experience, something to consider as we're likely
going to bump into those in the long term, so ideally take them into the
account in the long term.


clang 14 generates debug information in DWARF 5 format, but valgrind
19.0 does not support that. Install valgrind 20.0 from experimental
which supports it.


IMO we should aim for reproducible results, thus we should likely provide tools
containers with a known versions inside, so anyone is able to get same results
using the source code Git hash and tool container version.


Yes that is a good idea. Debian bookworm is now in code freeze phase so 
it should not change much any more, but having a stable container would 
be nice.



Your current approach is highly dynamic, so if you're lucky enough, you might
get a green CI light in the PR branch as the pipeline was run for example 7
days ago, so you're going to merge it into the upstream branch, but then it's
going to fail as meanwhile Debian has bumped several packages and you're going
to get a CI pipeline failure.

IMO there should be a tools container Git repository, where we could build,
test and provide versioned containers, for example:

  ghcr.io/openwrt/ci-tools/native-testing/clang14:20230305
  ghcr.io/openwrt/ci-tools/native-testing/clang15:20230305
  ghcr.io/openwrt/ci-tools/native-testing/gcc-8:20230305
  ghcr.io/openwrt/ci-tools/native-testing/gcc-11:20230305
  ghcr.io/openwrt/ci-tools/native-testing/gcc-12:20230305


I will look into this.


We want to test with with multiple compiler versions as those tested changes
might be backported into stable branches, we should even consider to have
stable branches in every project so we could CI test them there as well, folks
would simply create a backport PR in the respective project.


Often we only create a stable branch when we really need it in OpenWrt, 
many of these repositories do not have one. If we create a stable branch 
we should also have CI on it.





+++ b/.github/workflows/test.yml
@@ -0,0 +1,83 @@
+name: 'Run tests'


We've like 30+ C projects which we should likely cover in the end, thus
considering possible additional 2 stable branches in each, it's around 60+ of
similar workflow files duplicated in various repositories.

I would consider this future maintenance overhead (imagine just a simple
change or a fix being propagated into 60+ repositories/branches), so I would
recommend to create a shareable Github Action instead:

  uses: openwrt/gh-actions-ci-native
  env:
CI_NATIVE_TOOLCHAIN: clang14

  uses: openwrt/gh-actions-ci-sdk
  env:
CI_TARGET_SDK_RELEASE: master
CI_TARGET_SDK: ath79-generic
CI_TARGET_BUILD_DEPENDS: uci

You can take a look at the ucode project for a very dated, but still working
GitHub example, some bits are even present in uci repsitory in the 
.gitlab-ci.yml
file.


I agree with you that we will have a lot of code duplication in the way 
I proposed it now. I will have a look at this.





+  - name: Checkout libubox
+uses: actions/checkout@v3
+with:
+  repository: openwrt/libubox
+  path: libubox


This looks like another source of unreliability, similar to the toolchain
versions above. For the start, I would simply include all those dependencies
in the native toolchain container, thus we would need to have separate
containers for each branch:


If the API changes we would have to update the containers too. I would 
prefer to use master of all components or even check if there is a 
branch with the same name and use that one. I think we recently had some 
changes to iwinfo and then some changes in rpcd which depended on that. 
I would like to support such changes too.



  ghcr.io/openwrt/ci-tools/native-testing/clang14_snapshot:20230305
  ghcr.io/openwrt/ci-tools/native-testing/clang14_openwrt-22.03:20230305
  ghcr.io/openwrt/ci-tools/native-testing/clang14_openwrt-21.02:20230305

  ghcr.io/openwrt/ci-tools/native-testing/distro_snapshot:20230305 (distro 
default gcc12)
  ghcr.io/openwrt/ci-tools/native-testing/distro_21.02:20230305 (gcc8)
  ghcr.io/openwrt/ci-tools/native-testing/distro_22.03:20230305 (gcc11)

So in the end, ideally, interested developer can have the same CI
failure/result locally and debug/fix it faster:

  $ git clone https://github.com/openwrt/uci && cd uci
  $ wget -q https://github.com/openwrt/some-project/raw/master/Makefile -O 
Makefile.ci
  $ make ci-prepare -f Makefile.ci
  $ podman run --rm --tty --interactive --volume $(pwd):/home/build/openwrt \
 ghcr.io/openwrt/ci-tools/native-testing/clang14_snapshot:20230305 \
make ci-native-build -f Makefile.ci

Have a nice weekend.

Cheers,

Petr


Hauke

Re: [PATCH uci 1/2] fuzz: Compile using libstd++

2023-03-12 Thread Hauke Mehrtens 

On 3/11/23 10:01, Petr Štetiar wrote:

Hauke Mehrtens  [2023-03-09 00:18:09]:

Hi,


It looks like libfuzzer is compiled using libstd++ on Debian Bookworm
and not libc++. Using libc++ causes linking errors, use libstd++
instead.


so maybe this should be detected and decided at runtime? Otherwise this seems
to just support Bookworm from now and thus fail to compile elsewhere?

Cheers,

Petr


Hi Petr,

I tried this in a Debian bullseye container too and there it also works 
fine with libstd++.


What libfuzzer did you use in your container in gitlab?

An automatic detection would be nice, but I have no idea how to do it.

Hauke

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [PATCH firmware-utils v1 00/10] Refactor image ingestion to support new formats

2023-03-12 Thread Sander Vanheule 
On Fri, 2023-02-03 at 23:03 +0100, Sander Vanheule wrote:
> TP-Link is playing fast and loose with the safeloader format, having
> resulted in different types of images with their specific quirks.
> 
> A new incompatible format is currently used in the wild, which places
> the payload partition table at a different offset, causing the image
> parsers to fail. [1]
> 
> This series starts by fixing a bug or two and cleaning up the code a
> tiny bit, and then refactors the different image ingestion options to
> use one common parser.
> 
> Finally, support for the QNEW and Cloud images types is added through the
> new parser. The latter doesn't really need explicit support at the
> moment, so the patch serves mostly as documentation.
> 
> [1] https://forum.openwrt.org/t/148982
> 
> Best,
> Sander
> 
> Sander Vanheule (10):
>   tplink-safeloader: stricter free_image_partition()
>   tplink-safeloader: use enum for table types
>   tplink-safeloader: replace hardcoded offsets
>   tplink-safeloader: stop at nameless partition
>   tplink-safeloader: don't end-pad sysupgrade file
>   tplink-safeloader: ignore NULLs in version info
>   tplink-safeloader: refactor image ingestion
>   tplink-safeloader: add vendor info support
>   tplink-safeloader: add QNEW image detection
>   tplink-safeloader: add Cloud image detection

If there are no objections, I'll merge these patches in the coming days.

Best,
Sander

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

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

2023-03-12 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:   https://github.com/sdwalker/sdwalker.github.io
  Commit: e5548ca4a727e9cb83a091a2df62ce350d6eb786
  
https://github.com/sdwalker/sdwalker.github.io/commit/e5548ca4a727e9cb83a091a2df62ce350d6eb786
  Author: Stephen Walker 
  Date:   2023-03-12 (Sun, 12 Mar 2023)

  Changed paths:
M uscan/index-21.02.html
M uscan/index-22.03.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