Re: [PATCH 1/4] at91bootstrap: update to v3.10.4, v4.0.1

2022-02-20 Thread claudiu 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 ---
On 19.02.2022 12:04, Petr Štetiar wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the 
> content is safe
> 
> Hi, resend patch 3 didn't made it to patchwork 
> https://patchwork.ozlabs.org/project/openwrt/list/?series=284474

Hi,

When I initially send the series I got a reply message saying that patch 3
is bigger than expected and it needs approval from admin. To bypass that
would it be ok to split patch 3 in multiple patches? Or should I contact
the admin (I don't know who he/she is). I kept it as 1 patch as it adds
kernel support for SAMA7G5 platform that I'm trying to address here.

Thank you,
Claudiu Beznea

> 
> Claudiu Beznea  [2022-02-04 16:47:43]:
> 
>> 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.
>> AT91Bootstrap version 4 is available only for SAM9X60, SAMA5D2, SAMA5D3,
>> SAMA5D4, SAMA7G5. Thus use v4.0.1 for the above targets and v3.10.4 for
>> the rest of them. With the switch to v4 AT91Bootstrap binaries are now
>> on build/binaries. Take also this into account. Also, patches directory
>> is not needed anymore with the version update.
>>
>> Signed-off-by: Claudiu Beznea 
>> ---
>>  package/boot/at91bootstrap/Makefile   | 17 +++--
>>  package/boot/at91bootstrap/at91bootstrap.mk   |  2 +-
>>  ...ile-Remove-nostartfiles-from-LDFLAGS.patch | 38 ---
>>  3 files changed, 15 insertions(+), 42 deletions(-)
>>  delete mode 04 package/boot/at91bootstrap/patches
>>  delete mode 100644 
>> package/boot/at91bootstrap/patches/001-Makefile-Remove-nostartfiles-from-LDFLAGS.patch
>>
>> diff --git a/package/boot/at91bootstrap/Makefile 
>> b/package/boot/at91bootstrap/Makefile
>> index 2d77f7099721..a06eea90a416 100644
>> --- a/package/boot/at91bootstrap/Makefile
>> +++ b/package/boot/at91bootstrap/Makefile
>> @@ -9,13 +9,24 @@
>>  include $(TOPDIR)/rules.mk
>>
>>  PKG_NAME:=at91bootstrap
>> -PKG_VERSION:=v3.9.3
>> +PKG_VERSION:=v4.0.1
>> +PKG_MIRROR_HASH:=3d45a4bcb52162097d4cdf042b8fe1ccf53e88b512e7541f42a23f2a73692a69
>> +PKG_SOURCE_VERSION:=4d41296e9ae12379555fb46a941897e7264600a2
>> +BINARIES_DIR:=build/binaries
>> +
>> +ifdef CONFIG_TARGET_at91_sam9x
>> +  ifndef CONFIG_TARGET_at91_sam9x_DEVICE_microchip_sam9x60ek
>> +PKG_VERSION=v3.10.4
>> +
>> PKG_MIRROR_HASH=6fe61fe90838e785917383bb9e887fa05e1bd061a6725954242f504e38b5c426
>> +PKG_SOURCE_VERSION=404846dd283894367a015ca59189bcf927d92e11
>> +BINARIES_DIR=binaries
>> +  endif
>> +endif
>> +
>>  PKG_RELEASE:=2
>>
>>  PKG_SOURCE_PROTO:=git
>>  PKG_SOURCE_URL:=https://github.com/linux4sam/at91bootstrap.git
>> -PKG_MIRROR_HASH:=06753d673756edc9753932db00f4e5b8c1f9fa7708337c4d6ce280573efb86b4
>> -PKG_SOURCE_VERSION:=d96833a4b6680b237708eb4dc9f10708b9e709d8
>>  PKG_BUILD_DIR = \
>>   $(BUILD_DIR)/$(PKG_NAME)-$(BUILD_VARIANT)/$(PKG_NAME)-$(PKG_VERSION)
>>
>> diff --git a/package/boot/at91bootstrap/at91bootstrap.mk 
>> b/package/boot/at91bootstrap/at91bootstrap.mk
>> index fe6577f58927..d4e807d9a219 100644
>> --- a/package/boot/at91bootstrap/at91bootstrap.mk
>> +++ b/package/boot/at91bootstrap/at91bootstrap.mk
>> @@ -5,7 +5,7 @@ PKG_FLAGS:=nonshared
>>  export GCC_HONOUR_COPTS=s
>>
>>  define Package/at91bootstrap/install/default
>> - $(CP) -avL $(PKG_BUILD_DIR)/binaries/at91bootstrap.bin $(1)/
>> + $(CP) -avL $(PKG_BUILD_DIR)/$(BINARIES_DIR)/at91bootstrap.bin $(1)/
>>  endef
>>
>>  Package/at91bootstrap/install = $(Package/at91bootstrap/install/default)
>> diff --git 
>> a/package/boot/at91bootstrap/patches/001-Makefile-Remove-nostartfiles-from-LDFLAGS.patch
>>  
>> b/package/boot/at91bootstrap/patches/001-Makefile-Remove-nostartfiles-from-LDFLAGS.patch
>> deleted file mode 100644
>> index 9d48758bdad2..
>> --- 
>> a/package/boot/at91bootstrap/patches/001-Makefile-Remove-nostartfiles-from-LDFLAGS.patch
>> +++ /dev/null
>> @@ -1,38 +0,0 @@
>> -From 59c8963d8e6a08222616d1b384e1009ba05e6b82 Mon Sep 17 00:00:00 2001
>> -From: Chris Elledge 
>> -Date: Tue, 8 Jun 2021 14:01:14 -0400
>> -Subject: Makefile: Remove -nostartfiles from LDFLAGS
>> -
>> -Binutils linker ld does not support the flag -nostartfiles.
>> -This is interpreted as "-n -o startfiles" which fortunately has no impact
>> -on the build process. Removing -nostartfiles has no impact on the build.
>> -
>> -Binutils 2.36 and later ld has improved flag parsing and throws an error if
>> --nostartfiles is passed as an argument. Removing the flag fixes the problem.
>> -
>> -Details on the Binutils ML:
>> 

Re: [PATCH v3 2/2] iproute2: add support for cpu set

2022-02-20 Thread Daniel Golle
On Mon, Feb 21, 2022 at 01:37:10AM +0100, Ansuel Smith wrote:
> >
> > On Thu, Feb 03, 2022 at 01:44:12AM +0100, Ansuel Smith wrote:
> > > Add support for cpu set useful to set CPU port for dsa devices.
> >
> > Please also document the newly added 'cpu' parameter in the command-
> > line output -- the manpage isn't even installed/available for OpenWrt
> > users.
> >
> 
> Should I wait for other review or should I send v3?

Give it a test-run and make sure
ip link XXX set cpu YYY
actually works -- when I tried it gave me
RTNETLINK answers: Not supported
eventhough the DSA driver does set the .port_change_cpu_port
function. If it works for you with whatever DSA driver you are trying
with, I will figure why it didn't work on MT7530...


> 
> > >
> > > Signed-off-by: Ansuel Smith 
> > > ---
> > >  ...101-iplink_allow_to_change_cpu_value.patch | 81 +++
> > >  1 file changed, 81 insertions(+)
> > >  create mode 100644 
> > > package/network/utils/iproute2/patches/101-iplink_allow_to_change_cpu_value.patch
> > >
> > > diff --git 
> > > a/package/network/utils/iproute2/patches/101-iplink_allow_to_change_cpu_value.patch
> > >  
> > > b/package/network/utils/iproute2/patches/101-iplink_allow_to_change_cpu_value.patch
> > > new file mode 100644
> > > index ..1bb2bb1f
> > > --- /dev/null
> > > +++ 
> > > b/package/network/utils/iproute2/patches/101-iplink_allow_to_change_cpu_value.patch
> > > @@ -0,0 +1,81 @@
> > > +From 8642516618b60a2827215f2bed54d4d0aa1da48a Mon Sep 17 00:00:00 2001
> > > +From: Ansuel Smith 
> > > +Date: Sun, 23 Jan 2022 00:31:49 +0100
> > > +Subject: [PATCH] iplink: allow to change cpu of dsa device
> > > +
> > > +Allow to change the cpu port linked to a given dsa interface.
> > > +This is useful in the case of multi-CPU port DSA to assign the correct
> > > +port to the different user ports.
> > > +
> > > +Signed-off-by: Ansuel Smith 
> > > +---
> > > + include/uapi/linux/if_link.h | 1 +
> > > + ip/iplink.c  | 7 +++
> > > + man/man8/ip-link.8.in| 7 +++
> > > + 3 files changed, 15 insertions(+)
> > > +
> > > +diff --git a/include/uapi/linux/if_link.h b/include/uapi/linux/if_link.h
> > > +index 41708e26..901b5544 100644
> > > +--- a/include/uapi/linux/if_link.h
> > >  b/include/uapi/linux/if_link.h
> > > +@@ -341,6 +341,7 @@ enum {
> > > + IFLA_ALT_IFNAME, /* Alternative ifname */
> > > + IFLA_PERM_ADDRESS,
> > > + IFLA_PROTO_DOWN_REASON,
> > > ++IFLA_CPU,
> > > +
> > > + /* device (sysfs) name as parent, used instead
> > > +  * of IFLA_LINK where there's no parent netdev
> > > +diff --git a/ip/iplink.c b/ip/iplink.c
> > > +index a3ea775d..254c35c5 100644
> > > +--- a/ip/iplink.c
> > >  b/ip/iplink.c
> > > +@@ -595,6 +595,7 @@ int iplink_parse(int argc, char **argv, struct 
> > > iplink_req *req, char **type)
> > > + int index = 0;
> > > + int group = -1;
> > > + int addr_len = 0;
> > > ++int cpu = -1;
> > > + int err;
> > > +
> > > + ret = argc;
> > > +@@ -625,6 +626,12 @@ int iplink_parse(int argc, char **argv, struct 
> > > iplink_req *req, char **type)
> > > + } else if (matches(*argv, "link") == 0) {
> > > + NEXT_ARG();
> > > + link = *argv;
> > > ++} else if (matches(*argv, "cpu") == 0) {
> > > ++NEXT_ARG();
> > > ++cpu = ll_name_to_index(*argv);
> > > ++if (!cpu)
> > > ++return nodev(*argv);
> > > ++addattr32(>n, sizeof(*req), IFLA_CPU, cpu);
> > > + } else if (matches(*argv, "address") == 0) {
> > > + NEXT_ARG();
> > > + addr_len = ll_addr_a2n(abuf, sizeof(abuf), *argv);
> > > +diff --git a/man/man8/ip-link.8.in b/man/man8/ip-link.8.in
> > > +index 19a0c9ca..406db8ad 100644
> > > +--- a/man/man8/ip-link.8.in
> > >  b/man/man8/ip-link.8.in
> > > +@@ -152,6 +152,9 @@ ip-link \- network device configuration
> > > + .br
> > > + .RB "[ " nomaster " ]"
> > > + .br
> > > ++.RB "[ " cpu
> > > ++.IR DEVICE " ]"
> > > ++.br
> > > + .RB "[ " vrf
> > > + .IR NAME " ]"
> > > + .br
> > > +@@ -2299,6 +2302,10 @@ set master device of the device (enslave device).
> > > + .BI nomaster
> > > + unset master device of the device (release device).
> > > +
> > > ++.TP
> > > ++.BI cpu " DEVICE"
> > > ++set cpu device of the dsa device.
> > > ++
> > > + .TP
> > > + .BI addrgenmode " eui64|none|stable_secret|random"
> > > + set the IPv6 address generation mode
> > > +--
> > > +2.33.1
> > > +
> > > --
> > > 2.34.1
> > >
> > >
> > > ___
> > > 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


[PATCH 21.02] ramips: mt7621: do memory detection on KSEG1

2022-02-20 Thread Szabolcs Hubai
From: Chuanhong Guo 

It's reported that current memory detection code occasionally detects
larger memory under some bootloaders.
Current memory detection code tests whether address space wraps around
on KSEG0, which is unreliable because it's cached.

Rewrite memory size detection to perform the same test on KSEG1 instead.
While at it, this patch also does the following two things:
1. use a fixed pattern instead of a random function pointer as the magic
   value.
2. add an additional memory write and a second comparison as part of the
   test to prevent possible smaller memory detection result due to
   leftover values in memory.

Fixes: 6d91ddf517 ("ramips: mt7621: add support for memory detection")
Reported-by: Rui Salvaterra 
Tested-by: Rui Salvaterra 
Signed-off-by: Chuanhong Guo 
(cherry picked from commit 2f024b79331141e2a62c9bf3601c803b26bde77b)
[backport for OpenWrt 21.02 as it was reproducible with Kernel 5.4, see [1]]
[1]: https://forum.openwrt.org/t/113081
Tested-by: Dimitri Souza  [mt7621/archer-c6-v3]
Signed-off-by: Szabolcs Hubai 
---
 .../325-mt7621-fix-memory-detect.patch| 62 +++
 1 file changed, 62 insertions(+)
 create mode 100644 
target/linux/ramips/patches-5.4/325-mt7621-fix-memory-detect.patch

diff --git a/target/linux/ramips/patches-5.4/325-mt7621-fix-memory-detect.patch 
b/target/linux/ramips/patches-5.4/325-mt7621-fix-memory-detect.patch
new file mode 100644
index 00..f8616c31fc
--- /dev/null
+++ b/target/linux/ramips/patches-5.4/325-mt7621-fix-memory-detect.patch
@@ -0,0 +1,62 @@
+--- a/arch/mips/ralink/mt7621.c
 b/arch/mips/ralink/mt7621.c
+@@ -58,7 +58,9 @@
+ #define MT7621_GPIO_MODE_SDHCI_SHIFT  18
+ #define MT7621_GPIO_MODE_SDHCI_GPIO   1
+ 
+-static void *detect_magic __initdata = detect_memory_region;
++#define MT7621_MEM_TEST_PATTERN 0xaaaa
++
++static u32 detect_magic __initdata;
+ 
+ static struct rt2880_pmx_func uart1_grp[] =  { FUNC("uart1", 0, 1, 2) };
+ static struct rt2880_pmx_func i2c_grp[] =  { FUNC("i2c", 0, 3, 2) };
+@@ -144,26 +146,34 @@ static struct clk *__init mt7621_add_sys
+   return clk;
+ }
+ 
++static bool __init mt7621_addr_wraparound_test(phys_addr_t size)
++{
++  void *dm = (void *)KSEG1ADDR(_magic);
++  if (CPHYSADDR(dm + size) >= MT7621_LOWMEM_MAX_SIZE)
++  return true;
++  __raw_writel(MT7621_MEM_TEST_PATTERN, dm);
++  if (__raw_readl(dm) != __raw_readl(dm + size))
++  return false;
++  __raw_writel(!MT7621_MEM_TEST_PATTERN, dm);
++  return __raw_readl(dm) == __raw_readl(dm + size);
++}
++
+ void __init mt7621_memory_detect(void)
+ {
+-  void *dm = _magic;
+   phys_addr_t size;
+ 
+-  for (size = 32 * SZ_1M; size < 256 * SZ_1M; size <<= 1) {
+-  if (!__builtin_memcmp(dm, dm + size, sizeof(detect_magic)))
+-  break;
++  for (size = 32 * SZ_1M; size <= 256 * SZ_1M; size <<= 1) {
++  if (mt7621_addr_wraparound_test(size)) {
++  add_memory_region(MT7621_LOWMEM_BASE, size, 
BOOT_MEM_RAM);
++  return;
++  }
+   }
+ 
+-  if ((size == 256 * SZ_1M) &&
+-  (CPHYSADDR(dm + size) < MT7621_LOWMEM_MAX_SIZE) &&
+-  __builtin_memcmp(dm, dm + size, sizeof(detect_magic))) {
+-  add_memory_region(MT7621_LOWMEM_BASE, MT7621_LOWMEM_MAX_SIZE,
+-BOOT_MEM_RAM);
+-  add_memory_region(MT7621_HIGHMEM_BASE, MT7621_HIGHMEM_SIZE,
+-BOOT_MEM_RAM);
+-  } else {
+-  add_memory_region(MT7621_LOWMEM_BASE, size, BOOT_MEM_RAM);
+-  }
++  /* addr doesn't wrap around at dm + 256M, assume 512M memory. */
++  add_memory_region(MT7621_LOWMEM_BASE, MT7621_LOWMEM_MAX_SIZE,
++BOOT_MEM_RAM);
++  add_memory_region(MT7621_HIGHMEM_BASE, MT7621_HIGHMEM_SIZE,
++BOOT_MEM_RAM);
+ }
+ 
+ void __init ralink_clk_init(void)
-- 
2.25.1


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


[PATCH v2] ath79: add Zyxel EMG2926-Q10A

2022-02-20 Thread Alex Henrie
The Zyxel EMG2926-Q10A is 99% the Zyxel NBG6716, but the bootloader
expects a different product name when flashing over TFTP. Also, the
EMG2926-Q10A always has 128 MiB of NAND flash whereas the NBG6716
reportedly can have either 128 MiB or 256 MiB.

Signed-off-by: Alex Henrie 
---
v2: Avoid duplication in nand.mk
---
 .../base-files/etc/hotplug.d/ieee80211/00-wifi-migration  | 1 +
 target/linux/ath79/dts/qca9558_zyxel_emg2926_q10a.dts | 8 
 target/linux/ath79/image/nand.mk  | 7 +++
 target/linux/ath79/nand/base-files/etc/board.d/02_network | 1 +
 .../base-files/etc/hotplug.d/firmware/11-ath10k-caldata   | 1 +
 .../base-files/etc/hotplug.d/ieee80211/10-fix-wifi-mac| 1 +
 .../ath79/nand/base-files/lib/preinit/10_fix_eth_mac.sh   | 1 +
 7 files changed, 20 insertions(+)
 create mode 100644 target/linux/ath79/dts/qca9558_zyxel_emg2926_q10a.dts

diff --git 
a/target/linux/ath79/base-files/etc/hotplug.d/ieee80211/00-wifi-migration 
b/target/linux/ath79/base-files/etc/hotplug.d/ieee80211/00-wifi-migration
index d2df0533fe..35e7c4452c 100644
--- a/target/linux/ath79/base-files/etc/hotplug.d/ieee80211/00-wifi-migration
+++ b/target/linux/ath79/base-files/etc/hotplug.d/ieee80211/00-wifi-migration
@@ -16,6 +16,7 @@ migrate_wifi_path() {
case "$board" in
tplink,archer-c7-v1|\
tplink,archer-c7-v2|\
+   zyxel,emg2926-q10a|\
zyxel,nbg6716)
path="pci:00/:00:00.0"
WIFI_PATH_CHANGED=1
diff --git a/target/linux/ath79/dts/qca9558_zyxel_emg2926_q10a.dts 
b/target/linux/ath79/dts/qca9558_zyxel_emg2926_q10a.dts
new file mode 100644
index 00..c00109a5b4
--- /dev/null
+++ b/target/linux/ath79/dts/qca9558_zyxel_emg2926_q10a.dts
@@ -0,0 +1,8 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+
+#include "qca9558_zyxel_nbg6716.dts"
+
+/ {
+   compatible = "zyxel,emg2926-q10a", "zyxel,nbg6716", "qca,qca9558";
+   model = "ZyXEL EMG2926-Q10A";
+};
diff --git a/target/linux/ath79/image/nand.mk b/target/linux/ath79/image/nand.mk
index 2d7892db94..9f209368e4 100644
--- a/target/linux/ath79/image/nand.mk
+++ b/target/linux/ath79/image/nand.mk
@@ -344,3 +344,10 @@ define Device/zyxel_nbg6716
   UBINIZE_OPTS := -E 5
 endef
 TARGET_DEVICES += zyxel_nbg6716
+
+define Device/zyxel_emg2926_q10a
+  $(Device/zyxel_nbg6716)
+  DEVICE_MODEL := EMG2926-Q10A
+  RAS_BOARD := AAVK-EMG2926Q10A
+endef
+TARGET_DEVICES += zyxel_emg2926_q10a
diff --git a/target/linux/ath79/nand/base-files/etc/board.d/02_network 
b/target/linux/ath79/nand/base-files/etc/board.d/02_network
index e26a5e4ddf..2c6e676ae9 100644
--- a/target/linux/ath79/nand/base-files/etc/board.d/02_network
+++ b/target/linux/ath79/nand/base-files/etc/board.d/02_network
@@ -49,6 +49,7 @@ ath79_setup_interfaces()
ucidef_add_switch "switch0" \
"0@eth0" "1:lan:4" "2:lan:3" "3:lan:2" "5:lan:1"
;;
+   zyxel,emg2926-q10a|\
zyxel,nbg6716)
ucidef_add_switch "switch0" \
"0@eth0" "1:lan" "2:lan" "3:lan" "4:lan" "5:wan" 
"6@eth1"
diff --git 
a/target/linux/ath79/nand/base-files/etc/hotplug.d/firmware/11-ath10k-caldata 
b/target/linux/ath79/nand/base-files/etc/hotplug.d/firmware/11-ath10k-caldata
index d47e296853..e5c26d6bb5 100644
--- 
a/target/linux/ath79/nand/base-files/etc/hotplug.d/firmware/11-ath10k-caldata
+++ 
b/target/linux/ath79/nand/base-files/etc/hotplug.d/firmware/11-ath10k-caldata
@@ -21,6 +21,7 @@ case "$FIRMWARE" in
netgear,r6100)
caldata_extract "caldata" 0x5000 0x844
;;
+   zyxel,emg2926-q10a|\
zyxel,nbg6716)
caldata_extract "art" 0x5000 0x844
ath10k_patch_mac $(macaddr_add $(mtd_get_mac_ascii u-boot-env 
ethaddr) 1)
diff --git 
a/target/linux/ath79/nand/base-files/etc/hotplug.d/ieee80211/10-fix-wifi-mac 
b/target/linux/ath79/nand/base-files/etc/hotplug.d/ieee80211/10-fix-wifi-mac
index 730a5f9943..20974248c1 100644
--- a/target/linux/ath79/nand/base-files/etc/hotplug.d/ieee80211/10-fix-wifi-mac
+++ b/target/linux/ath79/nand/base-files/etc/hotplug.d/ieee80211/10-fix-wifi-mac
@@ -15,6 +15,7 @@ case $board in
[ "$PHYNBR" -eq 0 ] && \
macaddr_add $(mtd_get_mac_binary art 0x0) 2 > 
/sys${DEVPATH}/macaddress
;;
+   zyxel,emg2926-q10a|\
zyxel,nbg6716)
# Set mac address for 2.4g device
[ "$PHYNBR" -eq 1 ] && \
diff --git a/target/linux/ath79/nand/base-files/lib/preinit/10_fix_eth_mac.sh 
b/target/linux/ath79/nand/base-files/lib/preinit/10_fix_eth_mac.sh
index fdd8381f56..4e501496be 100644
--- a/target/linux/ath79/nand/base-files/lib/preinit/10_fix_eth_mac.sh
+++ 

Re: [PATCH] ath79: add Zyxel EMG2926-Q10A

2022-02-20 Thread Alex Henrie
On Sat, Feb 19, 2022 at 12:01 PM Petr Štetiar  wrote:
>
> Alex Henrie  [2022-01-20 22:06:07]:
>
> Hi,
>
> it looks like you need just this two variables:
>
>  DEVICE_MODEL := EMG2926-Q10A
>  RAS_BOARD := AAVK-EMG2926Q10A
>
> so following copy seems a bit much against my DRY taste:
>
> > +define Device/zyxel_emg2926_q10a
> > +  SOC := qca9558
> > +  DEVICE_VENDOR := ZyXEL
> > +  DEVICE_MODEL := EMG2926-Q10A
> > +  DEVICE_PACKAGES := kmod-usb2 kmod-usb-ledtrig-usbport kmod-ath10k-ct \
> > + ath10k-firmware-qca988x-ct
> > +  RAS_BOARD := AAVK-EMG2926Q10A
> > +  RAS_ROOTFS_SIZE := 29696k
> > +  RAS_VERSION := "OpenWrt Linux-$(LINUX_VERSION)"
> > +  KERNEL_SIZE := 4096k
> > +  BLOCKSIZE := 128k
> > +  PAGESIZE := 2048
> > +  LOADER_TYPE := bin
> > +  KERNEL := kernel-bin | append-dtb | lzma | loader-kernel | uImage none | 
> > \
> > + zyxel-buildkerneljffs | check-size 4096k
> > +  IMAGES := sysupgrade.tar sysupgrade-4M-Kernel.bin factory.bin
> > +  IMAGE/sysupgrade.tar/squashfs := append-rootfs | pad-to (BLOCKSIZE) 
> > | \
> > + sysupgrade-tar rootfs=@ | append-metadata
> > +  IMAGE/sysupgrade-4M-Kernel.bin/squashfs := append-kernel | \
> > + pad-to (KERNEL_SIZE) | append-ubi | pad-to 263192576 | gzip
> > +  IMAGE/factory.bin := append-kernel | pad-to (KERNEL_SIZE) | 
> > append-ubi | \
> > + zyxel-factory
> > +  UBINIZE_OPTS := -E 5
> > +endef
> > +TARGET_DEVICES += zyxel_emg2926_q10a
>
> so I would simply abstract the common bits into something like this:
>
>  define Device/zyxel_nand_common
> SOC := qca9558
> DEVICE_VENDOR := ZyXEL
> DEVICE_MODEL := EMG2926-Q10A
> DEVICE_PACKAGES := kmod-usb2 kmod-usb-ledtrig-usbport kmod-ath10k-ct \
> ath10k-firmware-qca988x-ct
> ...
>  end
>
> and then do:
>
>  define Device/zyxel_nbg6716
>$(Device/zyxel_nand_common)
>DEVICE_MODEL := NBG6716
>RAS_BOARD := NBG6716
>  endef
>
>  define Device/zyxel_emg2926_q10a
>$(Device/zyxel_nand_common)
>DEVICE_MODEL := EMG2926-Q10A
>RAS_BOARD := AAVK-EMG2926Q10A
>  endef

Thanks for showing me! I didn't know that I could do that. How about
we make Device/zyxel_emg2926_q10a inherit from Device/zyxel_nbg6716,
similar to how qca9558_zyxel_emg2926_q10a.dts inherits from
qca9558_zyxel_nbg6716.dts? I'll send a v2 shortly.

-Alex

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


Re: [PATCH v3 2/2] iproute2: add support for cpu set

2022-02-20 Thread Ansuel Smith
>
> On Thu, Feb 03, 2022 at 01:44:12AM +0100, Ansuel Smith wrote:
> > Add support for cpu set useful to set CPU port for dsa devices.
>
> Please also document the newly added 'cpu' parameter in the command-
> line output -- the manpage isn't even installed/available for OpenWrt
> users.
>

Should I wait for other review or should I send v3?

> >
> > Signed-off-by: Ansuel Smith 
> > ---
> >  ...101-iplink_allow_to_change_cpu_value.patch | 81 +++
> >  1 file changed, 81 insertions(+)
> >  create mode 100644 
> > package/network/utils/iproute2/patches/101-iplink_allow_to_change_cpu_value.patch
> >
> > diff --git 
> > a/package/network/utils/iproute2/patches/101-iplink_allow_to_change_cpu_value.patch
> >  
> > b/package/network/utils/iproute2/patches/101-iplink_allow_to_change_cpu_value.patch
> > new file mode 100644
> > index ..1bb2bb1f
> > --- /dev/null
> > +++ 
> > b/package/network/utils/iproute2/patches/101-iplink_allow_to_change_cpu_value.patch
> > @@ -0,0 +1,81 @@
> > +From 8642516618b60a2827215f2bed54d4d0aa1da48a Mon Sep 17 00:00:00 2001
> > +From: Ansuel Smith 
> > +Date: Sun, 23 Jan 2022 00:31:49 +0100
> > +Subject: [PATCH] iplink: allow to change cpu of dsa device
> > +
> > +Allow to change the cpu port linked to a given dsa interface.
> > +This is useful in the case of multi-CPU port DSA to assign the correct
> > +port to the different user ports.
> > +
> > +Signed-off-by: Ansuel Smith 
> > +---
> > + include/uapi/linux/if_link.h | 1 +
> > + ip/iplink.c  | 7 +++
> > + man/man8/ip-link.8.in| 7 +++
> > + 3 files changed, 15 insertions(+)
> > +
> > +diff --git a/include/uapi/linux/if_link.h b/include/uapi/linux/if_link.h
> > +index 41708e26..901b5544 100644
> > +--- a/include/uapi/linux/if_link.h
> >  b/include/uapi/linux/if_link.h
> > +@@ -341,6 +341,7 @@ enum {
> > + IFLA_ALT_IFNAME, /* Alternative ifname */
> > + IFLA_PERM_ADDRESS,
> > + IFLA_PROTO_DOWN_REASON,
> > ++IFLA_CPU,
> > +
> > + /* device (sysfs) name as parent, used instead
> > +  * of IFLA_LINK where there's no parent netdev
> > +diff --git a/ip/iplink.c b/ip/iplink.c
> > +index a3ea775d..254c35c5 100644
> > +--- a/ip/iplink.c
> >  b/ip/iplink.c
> > +@@ -595,6 +595,7 @@ int iplink_parse(int argc, char **argv, struct 
> > iplink_req *req, char **type)
> > + int index = 0;
> > + int group = -1;
> > + int addr_len = 0;
> > ++int cpu = -1;
> > + int err;
> > +
> > + ret = argc;
> > +@@ -625,6 +626,12 @@ int iplink_parse(int argc, char **argv, struct 
> > iplink_req *req, char **type)
> > + } else if (matches(*argv, "link") == 0) {
> > + NEXT_ARG();
> > + link = *argv;
> > ++} else if (matches(*argv, "cpu") == 0) {
> > ++NEXT_ARG();
> > ++cpu = ll_name_to_index(*argv);
> > ++if (!cpu)
> > ++return nodev(*argv);
> > ++addattr32(>n, sizeof(*req), IFLA_CPU, cpu);
> > + } else if (matches(*argv, "address") == 0) {
> > + NEXT_ARG();
> > + addr_len = ll_addr_a2n(abuf, sizeof(abuf), *argv);
> > +diff --git a/man/man8/ip-link.8.in b/man/man8/ip-link.8.in
> > +index 19a0c9ca..406db8ad 100644
> > +--- a/man/man8/ip-link.8.in
> >  b/man/man8/ip-link.8.in
> > +@@ -152,6 +152,9 @@ ip-link \- network device configuration
> > + .br
> > + .RB "[ " nomaster " ]"
> > + .br
> > ++.RB "[ " cpu
> > ++.IR DEVICE " ]"
> > ++.br
> > + .RB "[ " vrf
> > + .IR NAME " ]"
> > + .br
> > +@@ -2299,6 +2302,10 @@ set master device of the device (enslave device).
> > + .BI nomaster
> > + unset master device of the device (release device).
> > +
> > ++.TP
> > ++.BI cpu " DEVICE"
> > ++set cpu device of the dsa device.
> > ++
> > + .TP
> > + .BI addrgenmode " eui64|none|stable_secret|random"
> > + set the IPv6 address generation mode
> > +--
> > +2.33.1
> > +
> > --
> > 2.34.1
> >
> >
> > ___
> > 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


[PATCH v4 3/3] openssl: configure engines with uci

2022-02-20 Thread Eneas U de Queiroz
This uses uci to configure engines, by generating a list of enabled
engines in /var/etc/ssl/engines.cnf from engines configured in
/etc/config/openssl:

config engine 'devcrypto'
option enabled '1'

Currently the only options implemented are 'enabled', which defaults to
true and enables the named engine, and the 'force' option, that enables
the engine even if the init script thinks the engine does not exist.

The existence test is to check for either a configuration file
/etc/ssl/engines.cnf.d/%ENGINE%.cnf, or a shared object file
/usr/lib/engines-1.1/%ENGINE%.so.

The engine list is generated by an init script which is set to run after
'log' because it informs the engines being enabled or skipped.  It
should run before any service using OpenSSL as the crypto library,
otherwise the service will not use any engine.

Signed-off-by: Eneas U de Queiroz 
---
 package/libs/openssl/Makefile | 13 ++--
 package/libs/openssl/engine.mk| 60 ---
 package/libs/openssl/files/engines.cnf|  7 ---
 package/libs/openssl/files/openssl.init   | 31 ++
 .../150-openssl.cnf-add-engines-conf.patch|  5 +-
 5 files changed, 54 insertions(+), 62 deletions(-)
 delete mode 100644 package/libs/openssl/files/engines.cnf
 create mode 100755 package/libs/openssl/files/openssl.init

diff --git a/package/libs/openssl/Makefile b/package/libs/openssl/Makefile
index 3a0666ff8e..8ca4d83380 100644
--- a/package/libs/openssl/Makefile
+++ b/package/libs/openssl/Makefile
@@ -11,7 +11,7 @@ PKG_NAME:=openssl
 PKG_BASE:=1.1.1
 PKG_BUGFIX:=m
 PKG_VERSION:=$(PKG_BASE)$(PKG_BUGFIX)
-PKG_RELEASE:=2
+PKG_RELEASE:=3
 PKG_USE_MIPS16:=0
 
 PKG_BUILD_PARALLEL:=1
@@ -128,7 +128,6 @@ endef
 
 define Package/libopenssl-conf/conffiles
 /etc/ssl/openssl.cnf
-/etc/ssl/engines.cnf.d/engines.cnf
 $(if 
CONFIG_OPENSSL_ENGINE_BUILTIN_DEVCRYPTO,/etc/ssl/engines.cnf.d/devcrypto.cnf)
 $(if CONFIG_OPENSSL_ENGINE_BUILTIN_PADLOCK,/etc/ssl/engines.cnf.d/padlock.cnf)
 endef
@@ -378,15 +377,17 @@ define Package/libopenssl/install
 endef
 
 define Package/libopenssl-conf/install
-   $(INSTALL_DIR) $(1)/etc/ssl/engines.cnf.d
+   $(INSTALL_DIR) $(1)/etc/ssl/engines.cnf.d $(1)/etc/config 
$(1)/etc/init.d
$(CP) $(PKG_INSTALL_DIR)/etc/ssl/openssl.cnf $(1)/etc/ssl/
-   $(CP) ./files/engines.cnf $(1)/etc/ssl/engines.cnf.d/
+   $(INSTALL_BIN) ./files/openssl.init $(1)/etc/init.d/openssl
+   $(SED) 's!%ENGINES_DIR%!/usr/lib/$(ENGINES_DIR)!' 
$(1)/etc/init.d/openssl
+   touch $(1)/etc/config/openssl
$(if $(CONFIG_OPENSSL_ENGINE_BUILTIN_DEVCRYPTO),
$(CP) ./files/devcrypto.cnf $(1)/etc/ssl/engines.cnf.d/
-   echo devcrypto=devcrypto >> 
$(1)/etc/ssl/engines.cnf.d/engines.cnf)
+   echo -e "config engine 'devcrypto'\n\toption enabled '1'" >> 
$(1)/etc/config/openssl)
$(if $(CONFIG_OPENSSL_ENGINE_BUILTIN_PADLOCK),
$(CP) ./files/padlock.cnf $(1)/etc/ssl/engines.cnf.d/
-   echo padlock=padlock >> $(1)/etc/ssl/engines.cnf.d/engines.cnf)
+   echo -e "\nconfig engine 'padlock'\n\toption enabled '1'" >> 
$(1)/etc/config/openssl)
 endef
 
 define Package/openssl-util/install
diff --git a/package/libs/openssl/engine.mk b/package/libs/openssl/engine.mk
index 482b5ad5e8..973a989904 100644
--- a/package/libs/openssl/engine.mk
+++ b/package/libs/openssl/engine.mk
@@ -23,60 +23,24 @@ define Package/openssl/add-engine
 
   define Package/$$(OSSL_ENG_PKG)/postinst :=
 #!/bin/sh
-# 1 == non-empty: suggest reinstall
-error_out() {
-[ "$1" ] && cat <<- EOF
-   Reinstalling the libopenssl-conf package may fix this:
+OPENSSL_UCI="{IPKG_INSTROOT}/etc/config/openssl"
 
-   opkg install --force-reinstall libopenssl-conf
-   EOF
-cat <<- EOF
+[ -z "{IPKG_INSTROOT}" ] && uci -q get openssl.$(1) >/dev/null && exit 0
 
-   Then, you will have to reinstall this package, and any other engine 
package you have
-   you have previously installed to ensure they are enabled:
+cat << EOF >> "{OPENSSL_UCI}"
 
-   opkg install --force-reinstall $$(OSSL_ENG_PKG) 
[OTHER_ENGINE_PKG]...
+config engine '$(1)'
+   option enabled '1'
+EOF
 
-   EOF
-exit 1
-}
-ENGINES_CNF="{IPKG_INSTROOT}/etc/ssl/engines.cnf.d/engines.cnf"
-OPENSSL_CNF="{IPKG_INSTROOT}/etc/ssl/openssl.cnf"
-if [ ! -f "{OPENSSL_CNF}" ]; then
-echo -e "ERROR: File {OPENSSL_CNF} not found."
-error_out reinstall
-fi
-if ! grep -q "^.include /etc/ssl/engines.cnf.d" "{OPENSSL_CNF}"; then
-cat <<- EOF
-   Your /etc/ssl/openssl.cnf file is not loading engine configuration 
files from
-   /etc/ssl/engines.cnf.d.  You should consider start with a fresh, 
updated OpenSSL config by
-   running:
-
-   opkg install --force-reinstall --force-maintainer libopenssl-conf
-
-   The above command will overwrite any changes you may have made to both 

[PATCH v4 1/3] openssl: config engines in /etc/ssl/engines.cnf.d

2022-02-20 Thread Eneas U de Queiroz
This changes the configuration of engines from the global openssl.cnf to
files in the /etc/ssl/engines.cnf.d directory.  The engines.cnf file has
the list of enabled engines, while each engine has its own configuration
file installed under /etc/ssl/engines.cnf.d.

Patches were refreshed with --zero-commit.

Signed-off-by: Eneas U de Queiroz 
---
 package/libs/openssl/Makefile |  28 +++--
 package/libs/openssl/files/afalg.cnf  |   3 +
 package/libs/openssl/files/devcrypto.cnf  |  31 ++
 package/libs/openssl/files/engines.cnf|   7 ++
 package/libs/openssl/files/padlock.cnf|   3 +
 .../patches/100-Configure-afalg-support.patch |   3 +-
 .../openssl/patches/110-openwrt_targets.patch |   3 +-
 .../120-strip-cflags-from-binary.patch|   3 +-
 .../patches/130-dont-build-tests-fuzz.patch   |   3 +-
 .../patches/140-allow-prefer-chacha20.patch   |   4 +-
 .../150-openssl.cnf-add-engines-conf.patch| 101 +++---
 ...o-save-ioctl-if-EVP_MD_.FLAG_ONESHOT.patch |   3 +-
 ...ypto-add-command-to-dump-driver-info.patch |   3 +-
 ...o-make-the-dev-crypto-engine-dynamic.patch |   4 -
 ...default-to-not-use-digests-in-engine.patch |   1 -
 ...to-ignore-error-when-closing-session.patch |   1 -
 16 files changed, 82 insertions(+), 119 deletions(-)
 create mode 100644 package/libs/openssl/files/afalg.cnf
 create mode 100644 package/libs/openssl/files/devcrypto.cnf
 create mode 100644 package/libs/openssl/files/engines.cnf
 create mode 100644 package/libs/openssl/files/padlock.cnf

diff --git a/package/libs/openssl/Makefile b/package/libs/openssl/Makefile
index 9e7482117d..737123930c 100644
--- a/package/libs/openssl/Makefile
+++ b/package/libs/openssl/Makefile
@@ -146,7 +146,7 @@ endef
 define Package/libopenssl-afalg/description
 This package adds an engine that enables hardware acceleration
 through the AF_ALG kernel interface.
-To use it, you need to configure the engine in /etc/ssl/openssl.cnf
+To use it, you need to enable the engine in /etc/ssl/engines.cnf.d/engines.cnf.
 See 
https://www.openssl.org/docs/man1.1.1/man5/config.html#Engine-Configuration-Module
 and 
https://openwrt.org/docs/techref/hardware/cryptographic.hardware.accelerators
 The engine_id is "afalg"
@@ -163,7 +163,8 @@ endef
 define Package/libopenssl-devcrypto/description
 This package adds an engine that enables hardware acceleration
 through the /dev/crypto kernel interface.
-To use it, you need to configure the engine in /etc/ssl/openssl.cnf
+To use it, you need to enable the engine in 
/etc/ssl/engines.cnf.d/engines.cnf.  You may
+configure the engine by editing /etc/ssl/engines.cnf.d/devcrypto.cnf.
 See 
https://www.openssl.org/docs/man1.1.1/man5/config.html#Engine-Configuration-Module
 and 
https://openwrt.org/docs/techref/hardware/cryptographic.hardware.accelerators
 The engine_id is "devcrypto"
@@ -179,7 +180,7 @@ endef
 
 define Package/libopenssl-padlock/description
 This package adds an engine that enables VIA Padlock hardware acceleration.
-To use it, you need to configure it in /etc/ssl/openssl.cnf.
+To use it, you need to enable the engine in /etc/ssl/engines.cnf.d/engines.cnf.
 See 
https://www.openssl.org/docs/man1.1.1/man5/config.html#Engine-Configuration-Module
 and 
https://openwrt.org/docs/techref/hardware/cryptographic.hardware.accelerators
 The engine_id is "padlock"
@@ -376,8 +377,9 @@ define Package/libopenssl/install
 endef
 
 define Package/libopenssl-conf/install
-   $(INSTALL_DIR) $(1)/etc/ssl
+   $(INSTALL_DIR) $(1)/etc/ssl/engines.cnf.d
$(CP) $(PKG_INSTALL_DIR)/etc/ssl/openssl.cnf $(1)/etc/ssl/
+   $(CP) ./files/engines.cnf $(1)/etc/ssl/engines.cnf.d/
 endef
 
 define Package/openssl-util/install
@@ -386,18 +388,24 @@ define Package/openssl-util/install
 endef
 
 define Package/libopenssl-afalg/install
-   $(INSTALL_DIR) $(1)/usr/lib/$(ENGINES_DIR)
-   $(INSTALL_BIN) $(PKG_INSTALL_DIR)/usr/lib/$(ENGINES_DIR)/afalg.so 
$(1)/usr/lib/$(ENGINES_DIR)
+   $(INSTALL_DIR)  $(1)/etc/ssl/engines.cnf.d \
+   $(1)/usr/lib/$(ENGINES_DIR)
+   $(INSTALL_BIN)  $(PKG_INSTALL_DIR)/usr/lib/$(ENGINES_DIR)/afalg.so 
$(1)/usr/lib/$(ENGINES_DIR)
+   $(INSTALL_DATA) ./files/afalg.cnf $(1)/etc/ssl/engines.cnf.d/
 endef
 
 define Package/libopenssl-devcrypto/install
-   $(INSTALL_DIR) $(1)/usr/lib/$(ENGINES_DIR)
-   $(INSTALL_BIN) $(PKG_INSTALL_DIR)/usr/lib/$(ENGINES_DIR)/devcrypto.so 
$(1)/usr/lib/$(ENGINES_DIR)
+   $(INSTALL_DIR)  $(1)/etc/ssl/engines.cnf.d \
+   $(1)/usr/lib/$(ENGINES_DIR)
+   $(INSTALL_BIN)  $(PKG_INSTALL_DIR)/usr/lib/$(ENGINES_DIR)/devcrypto.so 
$(1)/usr/lib/$(ENGINES_DIR)
+   $(INSTALL_DATA) ./files/devcrypto.cnf $(1)/etc/ssl/engines.cnf.d/
 endef
 
 define Package/libopenssl-padlock/install
-   $(INSTALL_DIR) $(1)/usr/lib/$(ENGINES_DIR)
-   $(INSTALL_BIN) $(PKG_INSTALL_DIR)/usr/lib/$(ENGINES_DIR)/*padlock.so 
$(1)/usr/lib/$(ENGINES_DIR)
+   

[PATCH v4 2/3] openssl: configure engine packages during install

2022-02-20 Thread Eneas U de Queiroz
This enables an engine during its package's installation, by adding it
to the engines list in /etc/ssl/engines.cnf.d/engines.cnf.

The engine build system was reworked, with the addition of an engine.mk
file that groups some of the engine packages' definitions, and could be
used by out of tree engines as well.

Signed-off-by: Eneas U de Queiroz 
---
 package/libs/openssl/Makefile | 58 +
 package/libs/openssl/engine.mk| 82 +++
 package/libs/openssl/files/engines.cnf| 12 +--
 .../150-openssl.cnf-add-engines-conf.patch|  2 +-
 4 files changed, 111 insertions(+), 43 deletions(-)
 create mode 100644 package/libs/openssl/engine.mk

diff --git a/package/libs/openssl/Makefile b/package/libs/openssl/Makefile
index 737123930c..3a0666ff8e 100644
--- a/package/libs/openssl/Makefile
+++ b/package/libs/openssl/Makefile
@@ -11,9 +11,8 @@ PKG_NAME:=openssl
 PKG_BASE:=1.1.1
 PKG_BUGFIX:=m
 PKG_VERSION:=$(PKG_BASE)$(PKG_BUGFIX)
-PKG_RELEASE:=1
+PKG_RELEASE:=2
 PKG_USE_MIPS16:=0
-ENGINES_DIR=engines-1.1
 
 PKG_BUILD_PARALLEL:=1
 
@@ -65,6 +64,7 @@ PKG_CONFIG_DEPENDS:= \
CONFIG_OPENSSL_WITH_WHIRLPOOL
 
 include $(INCLUDE_DIR)/package.mk
+include engine.mk
 
 ifneq ($(CONFIG_CCACHE),)
 HOSTCC=$(HOSTCC_NOCACHE)
@@ -128,6 +128,9 @@ endef
 
 define Package/libopenssl-conf/conffiles
 /etc/ssl/openssl.cnf
+/etc/ssl/engines.cnf.d/engines.cnf
+$(if 
CONFIG_OPENSSL_ENGINE_BUILTIN_DEVCRYPTO,/etc/ssl/engines.cnf.d/devcrypto.cnf)
+$(if CONFIG_OPENSSL_ENGINE_BUILTIN_PADLOCK,/etc/ssl/engines.cnf.d/padlock.cnf)
 endef
 
 define Package/libopenssl-conf/description
@@ -135,52 +138,50 @@ $(call Package/openssl/Default/description)
 This package installs the OpenSSL configuration file /etc/ssl/openssl.cnf.
 endef
 
+$(eval $(call Package/openssl/add-engine,afalg))
 define Package/libopenssl-afalg
   $(call Package/openssl/Default)
-  SUBMENU:=SSL
+  $(call Package/openssl/engine/Default)
   TITLE:=AFALG hardware acceleration engine
-  DEPENDS:=libopenssl @OPENSSL_ENGINE @KERNEL_AIO \
-  +PACKAGE_libopenssl-afalg:kmod-crypto-user +libopenssl-conf 
@!OPENSSL_ENGINE_BUILTIN
+  DEPENDS += @KERNEL_AIO +PACKAGE_libopenssl-afalg:kmod-crypto-user \
+@!OPENSSL_ENGINE_BUILTIN
 endef
 
 define Package/libopenssl-afalg/description
 This package adds an engine that enables hardware acceleration
 through the AF_ALG kernel interface.
-To use it, you need to enable the engine in /etc/ssl/engines.cnf.d/engines.cnf.
 See 
https://www.openssl.org/docs/man1.1.1/man5/config.html#Engine-Configuration-Module
 and 
https://openwrt.org/docs/techref/hardware/cryptographic.hardware.accelerators
 The engine_id is "afalg"
 endef
 
+$(eval $(call Package/openssl/add-engine,devcrypto))
 define Package/libopenssl-devcrypto
   $(call Package/openssl/Default)
-  SUBMENU:=SSL
+  $(call Package/openssl/engine/Default)
   TITLE:=/dev/crypto hardware acceleration engine
-  DEPENDS:=libopenssl @OPENSSL_ENGINE 
+PACKAGE_libopenssl-devcrypto:kmod-cryptodev +libopenssl-conf \
-  @!OPENSSL_ENGINE_BUILTIN
+  DEPENDS += +PACKAGE_libopenssl-devcrypto:kmod-cryptodev 
@!OPENSSL_ENGINE_BUILTIN
 endef
 
 define Package/libopenssl-devcrypto/description
 This package adds an engine that enables hardware acceleration
 through the /dev/crypto kernel interface.
-To use it, you need to enable the engine in 
/etc/ssl/engines.cnf.d/engines.cnf.  You may
-configure the engine by editing /etc/ssl/engines.cnf.d/devcrypto.cnf.
 See 
https://www.openssl.org/docs/man1.1.1/man5/config.html#Engine-Configuration-Module
 and 
https://openwrt.org/docs/techref/hardware/cryptographic.hardware.accelerators
 The engine_id is "devcrypto"
 endef
 
+$(eval $(call Package/openssl/add-engine,padlock))
 define Package/libopenssl-padlock
   $(call Package/openssl/Default)
-  SUBMENU:=SSL
+  $(call Package/openssl/engine/Default)
   TITLE:=VIA Padlock hardware acceleration engine
-  DEPENDS:=libopenssl @OPENSSL_ENGINE @TARGET_x86 
+PACKAGE_libopenssl-padlock:kmod-crypto-hw-padlock \
-  +libopenssl-conf @!OPENSSL_ENGINE_BUILTIN
+  DEPENDS += @TARGET_x86 +PACKAGE_libopenssl-padlock:kmod-crypto-hw-padlock \
+@!OPENSSL_ENGINE_BUILTIN
 endef
 
 define Package/libopenssl-padlock/description
 This package adds an engine that enables VIA Padlock hardware acceleration.
-To use it, you need to enable the engine in /etc/ssl/engines.cnf.d/engines.cnf.
 See 
https://www.openssl.org/docs/man1.1.1/man5/config.html#Engine-Configuration-Module
 and 
https://openwrt.org/docs/techref/hardware/cryptographic.hardware.accelerators
 The engine_id is "padlock"
@@ -380,6 +381,12 @@ define Package/libopenssl-conf/install
$(INSTALL_DIR) $(1)/etc/ssl/engines.cnf.d
$(CP) $(PKG_INSTALL_DIR)/etc/ssl/openssl.cnf $(1)/etc/ssl/
$(CP) ./files/engines.cnf $(1)/etc/ssl/engines.cnf.d/
+   $(if $(CONFIG_OPENSSL_ENGINE_BUILTIN_DEVCRYPTO),
+   $(CP) ./files/devcrypto.cnf $(1)/etc/ssl/engines.cnf.d/

[PATCH v4 0/3] openssl: Engine configuration series

2022-02-20 Thread Eneas U de Queiroz
This series builds upon what was first started by Daniel Danzberger,
with some suggestions by Florian Eckert to enable the engines when they
are installed.

The series split is subject to discussion:
- the first commit does a patch cleanup proposed by Rosen Penev, and
  also splits the configuration from one monolithic file to one file per
  engine, and also an engines list.
- the sencond implements my first proposal, of enabling engines during
  their installation.  It introduces an engine.mk file that provides
  menu placement, basic dependencies and the postinst, postrm functions
  for engine packages, and can be used for out of tree engine packages.
- the third commit introduces uci configuration, and does the engines
  list generation during startup, or when an engine package is
  installed or removed.

The first commit received basic testing on mvebu running master,
covering afalg and devcrpto engines built as modules.

The second and third commits had testing expanded to checking built-in
engine builds.

I have not squashed the commits, but I do think that 2 and 3 may be
squashed if 3 is merged.  The first one is just cleanup, and the second
adds complexity that ended up being removed by the third commit.
Nonetheless, all of them result in a working package.

I thought about expanding uci support to include other configuration
commands, but it would drop the documentation provided by the current
config files.  Besides, each engine has its own options, which would
add complexity to config generation if you are to actually verify them.
Passing unknown commands straight from uci to the config files would be
simple and work, but it would be hard to find what options are
available, compared to just reading the example configs provided
otherwise.

openssl engine -vv would show the commands, with some basic description
of them, but getting the supported arguments may not be straightforward.
For example, gost engine has "CRYPT_PARAMS: OID of default GOST 28147-89
parameters".  All I could do to help was to point to a header file where
the actual list of supported parameters is defined.

After this is merged, I will adapt the two engines in the packages feed.

Changelog:

v1->v2:
- fixed postinst & postrm logic that was failing when building the final
  image
- deleted engine uci section when removing the package
- removed extra files leftover from previous development versions

v2->v3:
- actually removed the extra files that I had promised in v2

v3->v4:
- rebased onto current head
- removed non-applicable options from original afalg engine conf file

Eneas U de Queiroz (3):
  openssl: config engines in /etc/ssl/engines.cnf.d
  openssl: configure engine packages during install
  openssl: configure engines with uci

 package/libs/openssl/Makefile |  55 +-
 package/libs/openssl/engine.mk|  46 
 package/libs/openssl/files/afalg.cnf  |   3 +
 package/libs/openssl/files/devcrypto.cnf  |  31 ++
 package/libs/openssl/files/openssl.init   |  31 ++
 package/libs/openssl/files/padlock.cnf|   3 +
 .../patches/100-Configure-afalg-support.patch |   3 +-
 .../openssl/patches/110-openwrt_targets.patch |   3 +-
 .../120-strip-cflags-from-binary.patch|   3 +-
 .../patches/130-dont-build-tests-fuzz.patch   |   3 +-
 .../patches/140-allow-prefer-chacha20.patch   |   4 +-
 .../150-openssl.cnf-add-engines-conf.patch| 100 +++---
 ...o-save-ioctl-if-EVP_MD_.FLAG_ONESHOT.patch |   3 +-
 ...ypto-add-command-to-dump-driver-info.patch |   3 +-
 ...o-make-the-dev-crypto-engine-dynamic.patch |   4 -
 ...default-to-not-use-digests-in-engine.patch |   1 -
 ...to-ignore-error-when-closing-session.patch |   1 -
 17 files changed, 160 insertions(+), 137 deletions(-)
 create mode 100644 package/libs/openssl/engine.mk
 create mode 100644 package/libs/openssl/files/afalg.cnf
 create mode 100644 package/libs/openssl/files/devcrypto.cnf
 create mode 100755 package/libs/openssl/files/openssl.init
 create mode 100644 package/libs/openssl/files/padlock.cnf

-- 
2.34.1


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


Re: OpenWrt 22.0X release plan

2022-02-20 Thread Fernando Frediani

Thanks for all the work done towards this.

And thankfully SELinux will not be activated by default.

Regards
Fernando

On 20/02/2022 19:57, Hauke Mehrtens wrote:

Hi,

All the major new features for the next OpenWrt major release are 
mostly merged into master. The kernel 5.10 upgrade for the bcm63xx 
target is still missing.


Paul created a issue to track the remaining tasks:
https://github.com/openwrt/openwrt/issues/9248
This will be extended with new problems.

We plan to do a feature freeze of the master branch on 1. March 2022. 
This means we will not add any big changes any more by that date. 
Minor changes like adding support for new boards or adding a new 
package are still ok, big changes like activating SELinux by default 
would not be oḱ.


Around 20. March 2022 we plan to branch off the next major release and 
would prepare for a first release candidate about 1 week later.


Hauke

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


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


Re: [PATCH 19.07] wolfssl: bump to 5.1.1-stable

2022-02-20 Thread Eneas U de Queiroz
On Thu, Feb 17, 2022 at 11:51 AM Petr Štetiar  wrote:
>
> This is amalgamation of backported changes since 4.7.0-stable release:
>
>  Sergey V. Lobanov (2):
>
>   5b13b0b02c70 wolfssl: update to 5.1.1-stable
>   7d376e6e528f libs/wolfssl: add SAN (Subject Alternative Name) support
>
>  Andre Heider (3):
>
>   3f8adcb215ed wolfssl: remove --enable-sha512 configure switch
>   249478ec4850 wolfssl: always build with --enable-reproducible-build
>   4b212b1306a9 wolfssl: build with WOLFSSL_ALT_CERT_CHAINS
>
>  Ivan Pavlov (1):
>
>   16414718f9ae wolfssl: update to 4.8.1-stable
>
>  David Bauer (1):
>
>   f6d8c0cf2b47 wolfssl: always export wc_ecc_set_rng
>
>  Christian Lamparter (1):
>
>   86801bd3d806 wolfssl: fix Ed25519 typo in config prompt
>
> The diff of security related changes we would need to backport would be
> so huge, that there would be a high probability of introducing new
> vulnerabilities, so it was decided, that bumping to latest stable
> release is the prefered way for fixing following security issues:
>
>  * OCSP request/response verification issue. (fixed in 4.8.0)
>  * Incorrectly skips OCSP verification in certain situations CVE-2021-38597 
> (fixed in 4.8.1)
>  * Issue with incorrectly validating a certificate (fixed in 5.0.0)
>  * Hang with DSA signature creation when a specific q value is used (fixed in 
> 5.0.0)
>  * Client side session resumption issue (fixed in 5.1.0)
>  * Potential for DoS attack on a wolfSSL client CVE-2021-44718 (fixed in 
> 5.1.0)
>  * Non-random IV values in certain situations CVE-2022-23408 (fixed in 5.1.1)
>
> Cc: Hauke Mehrtens 
> Cc: Eneas U de Queiroz 
> Signed-off-by: Petr Štetiar 
> ---

Acked-by: Eneas U de Queiroz 

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


OpenWrt 22.0X release plan

2022-02-20 Thread Hauke Mehrtens

Hi,

All the major new features for the next OpenWrt major release are mostly 
merged into master. The kernel 5.10 upgrade for the bcm63xx target is 
still missing.


Paul created a issue to track the remaining tasks:
https://github.com/openwrt/openwrt/issues/9248
This will be extended with new problems.

We plan to do a feature freeze of the master branch on 1. March 2022. 
This means we will not add any big changes any more by that date. Minor 
changes like adding support for new boards or adding a new package are 
still ok, big changes like activating SELinux by default would not be oḱ.


Around 20. March 2022 we plan to branch off the next major release and 
would prepare for a first release candidate about 1 week later.


Hauke

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


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

2022-02-20 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: 773dada3bc67a03aba2d75cee4ce7fba74e49468
  
https://github.com/sdwalker/sdwalker.github.io/commit/773dada3bc67a03aba2d75cee4ce7fba74e49468
  Author: Stephen Walker 
  Date:   2022-02-20 (Sun, 20 Feb 2022)

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


Re: [PATCH] realtek: ZyXEL GS1900-48: drop gpio-restart

2022-02-20 Thread Daniel Golle
On Sun, Feb 20, 2022 at 09:13:24PM +0100, Birger Koblitz wrote:
> Hi,
> 
> during development I came across situations where the RTL839x
> SoC's own reset did not always completely reset its state.
> U-Boot was no longer able to boot via tftp afterwards.
> This is the same situation we see on the RTL838x.
> While users will hopefully never mess up the SoC as during
> development, I would prefer a solution that reliably
> resets the device over a solution that avoids a warning.
> At least we should have a comment in, that states that
> once this is fixed in libgpiod this should be the way
> to reset the device. And we should look into fixing libgpiod.

In the case shown by Sander, gpio-restart isn't used and/or
doesn't have the desired effect of restarting the device anyway,
resulting in the next lower priority restart handler (in this case
the watchdog) to carry out the restart.
Ie. what is there right now is a no-op, at least on the device which
Sander has used to capture the log shown below.


> On 20/02/2022 19:50, Sander Vanheule wrote:
> > GPIO 5 on the RTL8231 can be used to reset the system, but gpio-restart
> > uses gpiod_set_value. This triggers a kernel warning and backtrace for
> > GPIO pins that can sleep, such as the RTL8231's. Two warnings are
> > emitted by libgpiod, and a third warning by gpio-restart itself after it
> > fails to restart the system:
> > 
> > [  106.654008] [ cut here ]
> > [  106.659240] WARNING: CPU: 0 PID: 4279 at drivers/gpio/gpiolib.c:3098 
> > gpiod_set_value+0x7c/0x108
> > [ Stack dump and call trace ]
> > [  106.826218] ---[ end trace d1de50b401f5a153 ]---
> > [  106.962992] [ cut here ]
> > [  106.968208] WARNING: CPU: 0 PID: 4279 at drivers/gpio/gpiolib.c:3098 
> > gpiod_set_value+0x7c/0x108
> > [ Stack dump and call trace ]
> > [  107.136718] ---[ end trace d1de50b401f5a154 ]---
> > [  111.087092] [ cut here ]
> > [  111.092271] WARNING: CPU: 0 PID: 4279 at 
> > drivers/power/reset/gpio-restart.c:46 gpio_restart_notify+0xc0/0xdc
> > [ Stack dump and call trace ]
> > [  111.256629] ---[ end trace d1de50b401f5a155 ]---
> > 
> > By removing gpio-restart from this device, we skip the restart-by-GPIO
> > attempt and rely only on the watchdog for restarts, which is already the
> > de facto behaviour.
> > 
> > Signed-off-by: Sander Vanheule 
> > ---
> >   target/linux/realtek/dts-5.10/rtl8393_zyxel_gs1900-48.dts | 5 -
> >   1 file changed, 5 deletions(-)
> > 
> > diff --git a/target/linux/realtek/dts-5.10/rtl8393_zyxel_gs1900-48.dts 
> > b/target/linux/realtek/dts-5.10/rtl8393_zyxel_gs1900-48.dts
> > index dd392c5a9beb..e0e79068d2bc 100644
> > --- a/target/linux/realtek/dts-5.10/rtl8393_zyxel_gs1900-48.dts
> > +++ b/target/linux/realtek/dts-5.10/rtl8393_zyxel_gs1900-48.dts
> > @@ -39,11 +39,6 @@
> > gpio-controller;
> > };
> > -   gpio-restart {
> > -   compatible = "gpio-restart";
> > -   gpios = < 5 GPIO_ACTIVE_LOW>;
> > -   };
> > -
> > keys {
> > compatible = "gpio-keys-polled";
> > poll-interval = <20>;
> 
> ___
> 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] realtek: ZyXEL GS1900-48: drop gpio-restart

2022-02-20 Thread Birger Koblitz

Hi,

during development I came across situations where the RTL839x
SoC's own reset did not always completely reset its state.
U-Boot was no longer able to boot via tftp afterwards.
This is the same situation we see on the RTL838x.
While users will hopefully never mess up the SoC as during
development, I would prefer a solution that reliably
resets the device over a solution that avoids a warning.
At least we should have a comment in, that states that
once this is fixed in libgpiod this should be the way
to reset the device. And we should look into fixing libgpiod.

Cheers,
  Birger


On 20/02/2022 19:50, Sander Vanheule wrote:

GPIO 5 on the RTL8231 can be used to reset the system, but gpio-restart
uses gpiod_set_value. This triggers a kernel warning and backtrace for
GPIO pins that can sleep, such as the RTL8231's. Two warnings are
emitted by libgpiod, and a third warning by gpio-restart itself after it
fails to restart the system:

[  106.654008] [ cut here ]
[  106.659240] WARNING: CPU: 0 PID: 4279 at drivers/gpio/gpiolib.c:3098 
gpiod_set_value+0x7c/0x108
[ Stack dump and call trace ]
[  106.826218] ---[ end trace d1de50b401f5a153 ]---
[  106.962992] [ cut here ]
[  106.968208] WARNING: CPU: 0 PID: 4279 at drivers/gpio/gpiolib.c:3098 
gpiod_set_value+0x7c/0x108
[ Stack dump and call trace ]
[  107.136718] ---[ end trace d1de50b401f5a154 ]---
[  111.087092] [ cut here ]
[  111.092271] WARNING: CPU: 0 PID: 4279 at 
drivers/power/reset/gpio-restart.c:46 gpio_restart_notify+0xc0/0xdc
[ Stack dump and call trace ]
[  111.256629] ---[ end trace d1de50b401f5a155 ]---

By removing gpio-restart from this device, we skip the restart-by-GPIO
attempt and rely only on the watchdog for restarts, which is already the
de facto behaviour.

Signed-off-by: Sander Vanheule 
---
  target/linux/realtek/dts-5.10/rtl8393_zyxel_gs1900-48.dts | 5 -
  1 file changed, 5 deletions(-)

diff --git a/target/linux/realtek/dts-5.10/rtl8393_zyxel_gs1900-48.dts 
b/target/linux/realtek/dts-5.10/rtl8393_zyxel_gs1900-48.dts
index dd392c5a9beb..e0e79068d2bc 100644
--- a/target/linux/realtek/dts-5.10/rtl8393_zyxel_gs1900-48.dts
+++ b/target/linux/realtek/dts-5.10/rtl8393_zyxel_gs1900-48.dts
@@ -39,11 +39,6 @@
gpio-controller;
};
  
-	gpio-restart {

-   compatible = "gpio-restart";
-   gpios = < 5 GPIO_ACTIVE_LOW>;
-   };
-
keys {
compatible = "gpio-keys-polled";
poll-interval = <20>;


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


Re: [PATCH v3 2/2] iproute2: add support for cpu set

2022-02-20 Thread Daniel Golle
On Thu, Feb 03, 2022 at 01:44:12AM +0100, Ansuel Smith wrote:
> Add support for cpu set useful to set CPU port for dsa devices.

Please also document the newly added 'cpu' parameter in the command-
line output -- the manpage isn't even installed/available for OpenWrt
users.

> 
> Signed-off-by: Ansuel Smith 
> ---
>  ...101-iplink_allow_to_change_cpu_value.patch | 81 +++
>  1 file changed, 81 insertions(+)
>  create mode 100644 
> package/network/utils/iproute2/patches/101-iplink_allow_to_change_cpu_value.patch
> 
> diff --git 
> a/package/network/utils/iproute2/patches/101-iplink_allow_to_change_cpu_value.patch
>  
> b/package/network/utils/iproute2/patches/101-iplink_allow_to_change_cpu_value.patch
> new file mode 100644
> index ..1bb2bb1f
> --- /dev/null
> +++ 
> b/package/network/utils/iproute2/patches/101-iplink_allow_to_change_cpu_value.patch
> @@ -0,0 +1,81 @@
> +From 8642516618b60a2827215f2bed54d4d0aa1da48a Mon Sep 17 00:00:00 2001
> +From: Ansuel Smith 
> +Date: Sun, 23 Jan 2022 00:31:49 +0100
> +Subject: [PATCH] iplink: allow to change cpu of dsa device
> +
> +Allow to change the cpu port linked to a given dsa interface.
> +This is useful in the case of multi-CPU port DSA to assign the correct
> +port to the different user ports.
> +
> +Signed-off-by: Ansuel Smith 
> +---
> + include/uapi/linux/if_link.h | 1 +
> + ip/iplink.c  | 7 +++
> + man/man8/ip-link.8.in| 7 +++
> + 3 files changed, 15 insertions(+)
> +
> +diff --git a/include/uapi/linux/if_link.h b/include/uapi/linux/if_link.h
> +index 41708e26..901b5544 100644
> +--- a/include/uapi/linux/if_link.h
>  b/include/uapi/linux/if_link.h
> +@@ -341,6 +341,7 @@ enum {
> + IFLA_ALT_IFNAME, /* Alternative ifname */
> + IFLA_PERM_ADDRESS,
> + IFLA_PROTO_DOWN_REASON,
> ++IFLA_CPU,
> + 
> + /* device (sysfs) name as parent, used instead
> +  * of IFLA_LINK where there's no parent netdev
> +diff --git a/ip/iplink.c b/ip/iplink.c
> +index a3ea775d..254c35c5 100644
> +--- a/ip/iplink.c
>  b/ip/iplink.c
> +@@ -595,6 +595,7 @@ int iplink_parse(int argc, char **argv, struct 
> iplink_req *req, char **type)
> + int index = 0;
> + int group = -1;
> + int addr_len = 0;
> ++int cpu = -1;
> + int err;
> + 
> + ret = argc;
> +@@ -625,6 +626,12 @@ int iplink_parse(int argc, char **argv, struct 
> iplink_req *req, char **type)
> + } else if (matches(*argv, "link") == 0) {
> + NEXT_ARG();
> + link = *argv;
> ++} else if (matches(*argv, "cpu") == 0) {
> ++NEXT_ARG();
> ++cpu = ll_name_to_index(*argv);
> ++if (!cpu)
> ++return nodev(*argv);
> ++addattr32(>n, sizeof(*req), IFLA_CPU, cpu);
> + } else if (matches(*argv, "address") == 0) {
> + NEXT_ARG();
> + addr_len = ll_addr_a2n(abuf, sizeof(abuf), *argv);
> +diff --git a/man/man8/ip-link.8.in b/man/man8/ip-link.8.in
> +index 19a0c9ca..406db8ad 100644
> +--- a/man/man8/ip-link.8.in
>  b/man/man8/ip-link.8.in
> +@@ -152,6 +152,9 @@ ip-link \- network device configuration
> + .br
> + .RB "[ " nomaster " ]"
> + .br
> ++.RB "[ " cpu
> ++.IR DEVICE " ]"
> ++.br
> + .RB "[ " vrf
> + .IR NAME " ]"
> + .br
> +@@ -2299,6 +2302,10 @@ set master device of the device (enslave device).
> + .BI nomaster
> + unset master device of the device (release device).
> + 
> ++.TP
> ++.BI cpu " DEVICE"
> ++set cpu device of the dsa device.
> ++
> + .TP
> + .BI addrgenmode " eui64|none|stable_secret|random"
> + set the IPv6 address generation mode
> +-- 
> +2.33.1
> +
> -- 
> 2.34.1
> 
> 
> ___
> 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 v3 1/2] linux: introduce multi-cpu dsa patch

2022-02-20 Thread Daniel Golle
On Thu, Feb 03, 2022 at 01:44:11AM +0100, Ansuel Smith wrote:
> Add support for multi-cpu dsa. This is a reworked version of the RFC patch
> proposed some time ago.
> By default every dsa port is connected to the first cpu port and the command
> 'ip link set PORT cpu CPU_PORT' can be used to change the used cpu port at
> runtime.

The current behavior with this patch applied is quite the opposite:
All user ports get assigned to the *last* CPU port.

Apart from that this looks good so far.

> A specific function port_change_cpu_port is required to correctly setup the
> port on cpu change request.
> 
> Signed-off-by: Ansuel Smith 
> ---
>  ...net-dsa-allow-for-multiple-CPU-ports.patch |  97 +++
>  ...add-ndo-for-setting-the-cpu-proprety.patch | 113 ++
>  ...t-ndo_set_cpu-for-changing-DSA-port-.patch | 100 
>  ...clude-net-add-dsa_cpu_ports-function.patch |  39 ++
>  4 files changed, 349 insertions(+)
>  create mode 100644 
> target/linux/generic/hack-5.10/780-1-net-dsa-allow-for-multiple-CPU-ports.patch
>  create mode 100644 
> target/linux/generic/hack-5.10/780-2-net-add-ndo-for-setting-the-cpu-proprety.patch
>  create mode 100644 
> target/linux/generic/hack-5.10/780-3-net-dsa-implement-ndo_set_cpu-for-changing-DSA-port-.patch
>  create mode 100644 
> target/linux/generic/hack-5.10/780-4-include-net-add-dsa_cpu_ports-function.patch
> 
> diff --git 
> a/target/linux/generic/hack-5.10/780-1-net-dsa-allow-for-multiple-CPU-ports.patch
>  
> b/target/linux/generic/hack-5.10/780-1-net-dsa-allow-for-multiple-CPU-ports.patch
> new file mode 100644
> index ..9b4a57c6
> --- /dev/null
> +++ 
> b/target/linux/generic/hack-5.10/780-1-net-dsa-allow-for-multiple-CPU-ports.patch
> @@ -0,0 +1,97 @@
> +From 48d1e9543273c7670ebef15a4d27b13023895a28 Mon Sep 17 00:00:00 2001
> +From: =?UTF-8?q?Marek=20Beh=C3=BAn?= 
> +Date: Sat, 24 Aug 2019 04:42:48 +0200
> +Subject: [PATCH 1/4] net: dsa: allow for multiple CPU ports
> +MIME-Version: 1.0
> +Content-Type: text/plain; charset=UTF-8
> +Content-Transfer-Encoding: 8bit
> +
> +Allow for multiple CPU ports in a DSA switch tree. The default assing
> +logic is still used where the first defined CPU port is selected for all
> +the user ports. The CPU port has to be changed at runtime.
> +
> +Signed-off-by: Marek Behún 
> +---
> + net/dsa/dsa2.c | 22 ++
> + 1 file changed, 14 insertions(+), 8 deletions(-)
> +
> +diff --git a/net/dsa/dsa2.c b/net/dsa/dsa2.c
> +index 183003e45762..4a8de5e2f0f5 100644
> +--- a/net/dsa/dsa2.c
>  b/net/dsa/dsa2.c
> +@@ -240,7 +240,7 @@ static int dsa_tree_setup_default_cpu(struct 
> dsa_switch_tree *dst)
> + return 0;
> + }
> + 
> +-static void dsa_tree_teardown_default_cpu(struct dsa_switch_tree *dst)
> ++static void dsa_tree_teardown_default_cpus(struct dsa_switch_tree *dst)
> + {
> + struct dsa_port *dp;
> + 
> +@@ -553,7 +553,7 @@ static void dsa_tree_teardown_switches(struct 
> dsa_switch_tree *dst)
> + dsa_switch_teardown(dp->ds);
> + }
> + 
> +-static int dsa_tree_setup_master(struct dsa_switch_tree *dst)
> ++static int dsa_tree_setup_masters(struct dsa_switch_tree *dst)
> + {
> + struct dsa_port *dp;
> + int err;
> +@@ -562,14 +562,20 @@ static int dsa_tree_setup_master(struct 
> dsa_switch_tree *dst)
> + if (dsa_port_is_cpu(dp)) {
> + err = dsa_master_setup(dp->master, dp);
> + if (err)
> +-return err;
> ++goto teardown;
> + }
> + }
> + 
> + return 0;
> ++teardown:
> ++list_for_each_entry(dp, >ports, list)
> ++if (dsa_port_is_cpu(dp))
> ++dsa_master_teardown(dp->master);
> ++
> ++return err;
> + }
> + 
> +-static void dsa_tree_teardown_master(struct dsa_switch_tree *dst)
> ++static void dsa_tree_teardown_masters(struct dsa_switch_tree *dst)
> + {
> + struct dsa_port *dp;
> + 
> +@@ -601,7 +607,7 @@ static int dsa_tree_setup(struct dsa_switch_tree *dst)
> + if (err)
> + goto teardown_default_cpu;
> + 
> +-err = dsa_tree_setup_master(dst);
> ++err = dsa_tree_setup_masters(dst);
> + if (err)
> + goto teardown_switches;
> + 
> +@@ -614,7 +620,7 @@ static int dsa_tree_setup(struct dsa_switch_tree *dst)
> + teardown_switches:
> + dsa_tree_teardown_switches(dst);
> + teardown_default_cpu:
> +-dsa_tree_teardown_default_cpu(dst);
> ++dsa_tree_teardown_default_cpus(dst);
> + 
> + return err;
> + }
> +@@ -626,11 +632,11 @@ static void dsa_tree_teardown(struct dsa_switch_tree 
> *dst)
> + if (!dst->setup)
> + return;
> + 
> +-dsa_tree_teardown_master(dst);
> ++dsa_tree_teardown_masters(dst);
> + 
> + dsa_tree_teardown_switches(dst);
> + 
> +-dsa_tree_teardown_default_cpu(dst);
> ++dsa_tree_teardown_default_cpus(dst);
> + 
> + list_for_each_entry_safe(dl, next, >rtable, list) {
> + 

Re: [PATCH] usbmode: add config #0 and delay before actual config

2022-02-20 Thread Henrik Ginstmark
Hi

I have a Huawei ME909s-120.
When I switch directly from configuration #2 to #3, MBIM, the modem
will not respond to any MBIM messages.
I need to go via configuration #0, and a short delay, and then to
configuration #3 to make my modem to
respond.
It´s the same for Huawei ME909s as well.

BR
Henrik

Den lör 19 feb. 2022 kl 11:15 skrev Petr Štetiar :
>
> Henrik Ginstmark  [2022-02-07 22:30:40]:
>
> Hi,
>
> > Add config #0 and a 100milliseconds delay before switching to actual config.
> > Like in USB_ModeSwitch,
> > https://www.draisberghof.de/usb_modeswitch/bb/viewtopic.php?f=4=2710=505ed44b4064fef7009f0c26aac085e2=15
>
> can you be more specific, we need to know, why do you need to add this, is it
> fixing some issue etc. No need to resend, just reply with the answer to 'Why
> are these changes needed?' question, thanks.
>
> Cheers,
>
> Petr

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


[PATCH] realtek: ZyXEL GS1900-48: drop gpio-restart

2022-02-20 Thread Sander Vanheule
GPIO 5 on the RTL8231 can be used to reset the system, but gpio-restart
uses gpiod_set_value. This triggers a kernel warning and backtrace for
GPIO pins that can sleep, such as the RTL8231's. Two warnings are
emitted by libgpiod, and a third warning by gpio-restart itself after it
fails to restart the system:

[  106.654008] [ cut here ]
[  106.659240] WARNING: CPU: 0 PID: 4279 at drivers/gpio/gpiolib.c:3098 
gpiod_set_value+0x7c/0x108
   [ Stack dump and call trace ]
[  106.826218] ---[ end trace d1de50b401f5a153 ]---
[  106.962992] [ cut here ]
[  106.968208] WARNING: CPU: 0 PID: 4279 at drivers/gpio/gpiolib.c:3098 
gpiod_set_value+0x7c/0x108
   [ Stack dump and call trace ]
[  107.136718] ---[ end trace d1de50b401f5a154 ]---
[  111.087092] [ cut here ]
[  111.092271] WARNING: CPU: 0 PID: 4279 at 
drivers/power/reset/gpio-restart.c:46 gpio_restart_notify+0xc0/0xdc
   [ Stack dump and call trace ]
[  111.256629] ---[ end trace d1de50b401f5a155 ]---

By removing gpio-restart from this device, we skip the restart-by-GPIO
attempt and rely only on the watchdog for restarts, which is already the
de facto behaviour.

Signed-off-by: Sander Vanheule 
---
 target/linux/realtek/dts-5.10/rtl8393_zyxel_gs1900-48.dts | 5 -
 1 file changed, 5 deletions(-)

diff --git a/target/linux/realtek/dts-5.10/rtl8393_zyxel_gs1900-48.dts 
b/target/linux/realtek/dts-5.10/rtl8393_zyxel_gs1900-48.dts
index dd392c5a9beb..e0e79068d2bc 100644
--- a/target/linux/realtek/dts-5.10/rtl8393_zyxel_gs1900-48.dts
+++ b/target/linux/realtek/dts-5.10/rtl8393_zyxel_gs1900-48.dts
@@ -39,11 +39,6 @@
gpio-controller;
};
 
-   gpio-restart {
-   compatible = "gpio-restart";
-   gpios = < 5 GPIO_ACTIVE_LOW>;
-   };
-
keys {
compatible = "gpio-keys-polled";
poll-interval = <20>;
-- 
2.35.1


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


[PATCH 1/3] realtek: clean up RTL930x timer DT node

2022-02-20 Thread Sander Vanheule
The Realtek timer node for RTL930x doesn't have any child nodes, making
the use of '#address-cells' quite pointless. It is also not an interrupt
controller, meaning it makes no sense to define '#interrupt-cells'.

The I/O address for this node is also wrong, but this is hidden by the
fact that the driver associated with this node bypasses the usual DT
machinery and does it's own thing. Correct the address to have a sane
value, even though it isn't actually used.

Fixes: a75b9e3ecb61 ("realtek: Adding RTL930X sub-target")
Signed-off-by: Sander Vanheule 
---
 target/linux/realtek/dts-5.10/rtl930x.dtsi | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/target/linux/realtek/dts-5.10/rtl930x.dtsi 
b/target/linux/realtek/dts-5.10/rtl930x.dtsi
index 31c021134261..0ac613454f58 100644
--- a/target/linux/realtek/dts-5.10/rtl930x.dtsi
+++ b/target/linux/realtek/dts-5.10/rtl930x.dtsi
@@ -59,9 +59,7 @@
 
rtl9300clock: rtl9300clock@3200 {
compatible = "realtek,rtl9300clock";
-   reg = <0xb8003200 0x10>;
-   #address-cells = <0>;
-   #interrupt-cells = <1>;
+   reg = <0x3200 0x10>;
 
interrupt-parent = <>;
interrupts = <7 5>, <8 5>;
-- 
2.35.1


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


[PATCH 3/3] realtek: remove debugging code from timer

2022-02-20 Thread Sander Vanheule
Remove some (dead) debugging code from the Realtek timer to clean up the
sources of this driver.

Signed-off-by: Sander Vanheule 
---
 .../files-5.10/arch/mips/kernel/cevt-rtl9300.c | 18 +++---
 1 file changed, 3 insertions(+), 15 deletions(-)

diff --git a/target/linux/realtek/files-5.10/arch/mips/kernel/cevt-rtl9300.c 
b/target/linux/realtek/files-5.10/arch/mips/kernel/cevt-rtl9300.c
index cbbea7d68605..1c8c30de5d57 100644
--- a/target/linux/realtek/files-5.10/arch/mips/kernel/cevt-rtl9300.c
+++ b/target/linux/realtek/files-5.10/arch/mips/kernel/cevt-rtl9300.c
@@ -51,18 +51,12 @@ static irqreturn_t rtl9300_timer_interrupt(int irq, void 
*dev_id)
 {
struct rtl9300_clk_dev *rtl_clk = dev_id;
struct clock_event_device *clk = _clk->clkdev;
-// int cpu = smp_processor_id();
-   static atomic_t count = ATOMIC_INIT(0);
-   unsigned int c;
-   u32 v = readl(rtl_clk->base + RTL9300_TC_INT);
 
-   c = (unsigned int)atomic_inc_return();
+   u32 v = readl(rtl_clk->base + RTL9300_TC_INT);
 
// Acknowledge the IRQ
v |= RTL9300_TC_INT_IP;
writel(v, rtl_clk->base + RTL9300_TC_INT);
-   if (readl(rtl_clk->base + RTL9300_TC_INT) & RTL9300_TC_INT_IP)
-   dump_stack();
 
clk->event_handler(clk);
return IRQ_HANDLED;
@@ -76,10 +70,7 @@ static void rtl9300_clock_stop(void __iomem *base)
 
// Acknowledge possibly pending IRQ
v = readl(base + RTL9300_TC_INT);
-// if (v & RTL9300_TC_INT_IP)
-   writel(v | RTL9300_TC_INT_IP, base + RTL9300_TC_INT);
-   if (readl(base + RTL9300_TC_INT) & RTL9300_TC_INT_IP)
-   dump_stack();
+   writel(v | RTL9300_TC_INT_IP, base + RTL9300_TC_INT);
 }
 
 static void rtl9300_timer_start(void __iomem *base, bool periodic)
@@ -142,10 +133,7 @@ static void rtl9300_clock_setup(void __iomem *base)
 
// Acknowledge possibly pending IRQ
v = readl(base + RTL9300_TC_INT);
-// if (v & RTL9300_TC_INT_IP)
-   writel(v | RTL9300_TC_INT_IP, base + RTL9300_TC_INT);
-   if (readl(base + RTL9300_TC_INT) & RTL9300_TC_INT_IP)
-   dump_stack();
+   writel(v | RTL9300_TC_INT_IP, base + RTL9300_TC_INT);
 
// Setup maximum period (for use as clock-source)
writel(0x0fff, base + RTL9300_TC_DATA);
-- 
2.35.1


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


[PATCH 0/3] realtek: Clean up RTL930x event timer

2022-02-20 Thread Sander Vanheule
The new timer provided to support RTL930x SoCs has evaded proper review
before getting merged, so some clean-ups are now required. These patches
should fix the most glaring issues with the code.

These changes were tested on a ZyXEL XGS1250-12.

Sander Vanheule (3):
  realtek: clean up RTL930x timer DT node
  realtek: use DT provided address for timers
  realtek: remove debugging code from timer

 target/linux/realtek/dts-5.10/rtl930x.dtsi|  4 +-
 .../arch/mips/kernel/cevt-rtl9300.c   | 60 ---
 2 files changed, 25 insertions(+), 39 deletions(-)

-- 
2.35.1


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


[PATCH 2/3] realtek: use DT provided address for timers

2022-02-20 Thread Sander Vanheule
The I/O base address for the timers was hardcoded into the driver,
or derived from the HW IRQ number as an even more horrible hack. All
supported SoC families have these timers, but with hardcoded addresses
the code cannot be reused right now.

Request the timer's base address from the DT specification, and store it
in a private struct for future reference.

Matching the second interrupt specifier, the address range for the
second timer is added to the DT specification.

Signed-off-by: Sander Vanheule 
---
 target/linux/realtek/dts-5.10/rtl930x.dtsi|  2 +-
 .../arch/mips/kernel/cevt-rtl9300.c   | 46 +--
 2 files changed, 24 insertions(+), 24 deletions(-)

diff --git a/target/linux/realtek/dts-5.10/rtl930x.dtsi 
b/target/linux/realtek/dts-5.10/rtl930x.dtsi
index 0ac613454f58..bfde5e6ff6ae 100644
--- a/target/linux/realtek/dts-5.10/rtl930x.dtsi
+++ b/target/linux/realtek/dts-5.10/rtl930x.dtsi
@@ -59,7 +59,7 @@
 
rtl9300clock: rtl9300clock@3200 {
compatible = "realtek,rtl9300clock";
-   reg = <0x3200 0x10>;
+   reg = <0x3200 0x10>, <0x3210 0x10>;
 
interrupt-parent = <>;
interrupts = <7 5>, <8 5>;
diff --git a/target/linux/realtek/files-5.10/arch/mips/kernel/cevt-rtl9300.c 
b/target/linux/realtek/files-5.10/arch/mips/kernel/cevt-rtl9300.c
index cf3a4fe437d8..cbbea7d68605 100644
--- a/target/linux/realtek/files-5.10/arch/mips/kernel/cevt-rtl9300.c
+++ b/target/linux/realtek/files-5.10/arch/mips/kernel/cevt-rtl9300.c
@@ -24,11 +24,6 @@
 #define RTL9300_TC_INT_IP  BIT(16)
 #define RTL9300_TC_INT_IE  BIT(20)
 
-// Clocksource is using timer 0, clock event uses timer 1
-#define TIMER_CLK_SRC  0
-#define TIMER_CLK_EVT  0
-#define TIMER_BLK_EVT  (TIMER_CLK_EVT << 4)
-
 // Timer modes
 #define TIMER_MODE_REPEAT  1
 #define TIMER_MODE_ONCE0
@@ -38,37 +33,35 @@
 
 #define N_BITS 28
 
-#define RTL9300_TC1_IRQ8
 #define RTL9300_CLOCK_RATE 8750
-#define RTL9300_TC0_BASE   (void *)0xb8003200
 
-int irq_tc0 = 7;
+struct rtl9300_clk_dev {
+   struct clock_event_device clkdev;
+   void __iomem *base;
+};
 
 static void __iomem *rtl9300_tc_base(struct clock_event_device *clk)
 {
-   struct irq_desc *desc = irq_to_desc(clk->irq);
-   int tc = desc->irq_data.hwirq - irq_tc0;
+   struct rtl9300_clk_dev *rtl_clk = container_of(clk, struct 
rtl9300_clk_dev, clkdev);
 
-   return RTL9300_TC0_BASE + (tc << 4);
+   return rtl_clk->base;
 }
 
 static irqreturn_t rtl9300_timer_interrupt(int irq, void *dev_id)
 {
-   struct clock_event_device *clk = dev_id;
+   struct rtl9300_clk_dev *rtl_clk = dev_id;
+   struct clock_event_device *clk = _clk->clkdev;
 // int cpu = smp_processor_id();
-   struct irq_desc *desc = irq_to_desc(irq);
-   int tc = desc->irq_data.hwirq - irq_tc0;
-   void __iomem *base = RTL9300_TC0_BASE + (tc << 4);
static atomic_t count = ATOMIC_INIT(0);
unsigned int c;
-   u32 v = readl(base + RTL9300_TC_INT);
+   u32 v = readl(rtl_clk->base + RTL9300_TC_INT);
 
c = (unsigned int)atomic_inc_return();
 
// Acknowledge the IRQ
v |= RTL9300_TC_INT_IP;
-   writel(v, base + RTL9300_TC_INT);
-   if (readl(base + RTL9300_TC_INT) & RTL9300_TC_INT_IP)
+   writel(v, rtl_clk->base + RTL9300_TC_INT);
+   if (readl(rtl_clk->base + RTL9300_TC_INT) & RTL9300_TC_INT_IP)
dump_stack();
 
clk->event_handler(clk);
@@ -158,14 +151,15 @@ static void rtl9300_clock_setup(void __iomem *base)
writel(0x0fff, base + RTL9300_TC_DATA);
 }
 
-static DEFINE_PER_CPU(struct clock_event_device, rtl9300_clockevent);
+static DEFINE_PER_CPU(struct rtl9300_clk_dev, rtl9300_clockevent);
 static DEFINE_PER_CPU(char [18], rtl9300_clock_name);
 
 void rtl9300_clockevent_init(void)
 {
int cpu = smp_processor_id();
int irq;
-   struct clock_event_device *cd = _cpu(rtl9300_clockevent, cpu);
+   struct rtl9300_clk_dev *rtl_clk = _cpu(rtl9300_clockevent, cpu);
+   struct clock_event_device *cd = _clk->clkdev;
unsigned char *name = per_cpu(rtl9300_clock_name, cpu);
unsigned long flags =  IRQF_PERCPU | IRQF_TIMER;
struct device_node *node;
@@ -182,7 +176,13 @@ void rtl9300_clockevent_init(void)
irq = irq_of_parse_and_map(node, cpu);
pr_info("%s using IRQ %d\n", __func__, irq);
 
-   rtl9300_clock_setup(RTL9300_TC0_BASE + TIMER_BLK_EVT + (cpu << 4));
+   rtl_clk->base = of_iomap(node, cpu);
+   if (!rtl_clk->base) {
+   pr_err("cannot map timer for cpu %d", cpu);
+   return;
+   }
+
+   rtl9300_clock_setup(rtl_clk->base);
 
sprintf(name, "rtl9300-counter-%d", cpu);
cd->name= name;
@@ -205,8 +205,8 @@ void 

Re: [PATCH 19.07] wolfssl: bump to 5.1.1-stable

2022-02-20 Thread Hauke Mehrtens

On 2/17/22 15:51, Petr Štetiar wrote:

This is amalgamation of backported changes since 4.7.0-stable release:

  Sergey V. Lobanov (2):

   5b13b0b02c70 wolfssl: update to 5.1.1-stable
   7d376e6e528f libs/wolfssl: add SAN (Subject Alternative Name) support

  Andre Heider (3):

   3f8adcb215ed wolfssl: remove --enable-sha512 configure switch
   249478ec4850 wolfssl: always build with --enable-reproducible-build
   4b212b1306a9 wolfssl: build with WOLFSSL_ALT_CERT_CHAINS

  Ivan Pavlov (1):

   16414718f9ae wolfssl: update to 4.8.1-stable

  David Bauer (1):

   f6d8c0cf2b47 wolfssl: always export wc_ecc_set_rng

  Christian Lamparter (1):

   86801bd3d806 wolfssl: fix Ed25519 typo in config prompt

The diff of security related changes we would need to backport would be
so huge, that there would be a high probability of introducing new
vulnerabilities, so it was decided, that bumping to latest stable
release is the prefered way for fixing following security issues:

  * OCSP request/response verification issue. (fixed in 4.8.0)
  * Incorrectly skips OCSP verification in certain situations CVE-2021-38597 
(fixed in 4.8.1)
  * Issue with incorrectly validating a certificate (fixed in 5.0.0)
  * Hang with DSA signature creation when a specific q value is used (fixed in 
5.0.0)
  * Client side session resumption issue (fixed in 5.1.0)
  * Potential for DoS attack on a wolfSSL client CVE-2021-44718 (fixed in 5.1.0)
  * Non-random IV values in certain situations CVE-2022-23408 (fixed in 5.1.1)

Cc: Hauke Mehrtens 
Cc: Eneas U de Queiroz 
Signed-off-by: Petr Štetiar 


Acked-by: Hauke Mehrtens 


---
  package/libs/wolfssl/Config.in|  6 ++-
  package/libs/wolfssl/Makefile | 23 ++---
  .../patches/100-disable-hardening-check.patch |  2 +-
  .../patches/110-build-with-libtool-2.4.patch  | 13 +
  .../libs/wolfssl/patches/200-ecc-rng.patch| 50 +++
  5 files changed, 86 insertions(+), 8 deletions(-)
  create mode 100644 
package/libs/wolfssl/patches/110-build-with-libtool-2.4.patch
  create mode 100644 package/libs/wolfssl/patches/200-ecc-rng.patch



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


Re: [PATCH] kernel: Disable CONFIG_COMPAT_32BIT_TIME by default

2022-02-20 Thread Hauke Mehrtens

On 2/19/22 20:16, Petr Štetiar wrote:

Linus Walleij  [2021-04-14 15:23:11]:

Hi,


Several targets enable this selectively, probably some of
them should consider disabling it and see what happens.


we're now using musl 1.2.2 so we should be good to go. So if you want to
proceed, can you please update this patch and make it default on all targets,
as we want to be consistent here, otherwise it might be a support nightmare,
thanks.


OpenWrt also supports the option to be build with glibc and by default 
glibc still uses 32 bit time on most 32 bit targets, ARC being the only 
64 bit time glibc target.


There is an option in glibc to switch to 64 bit time on 32 bit targets, 
but we haven't activated it yet.


Hauke


Cc: Arnd Bergmann 
Signed-off-by: Linus Walleij 
---
  target/linux/generic/config-5.10 | 1 +
  1 file changed, 1 insertion(+)

diff --git a/target/linux/generic/config-5.10 b/target/linux/generic/config-5.10
index 120d1d8c3f4a..024d65ba7c8d 100644
--- a/target/linux/generic/config-5.10
+++ b/target/linux/generic/config-5.10
@@ -939,6 +939,7 @@ CONFIG_CMDLINE=""
  CONFIG_COMPACTION=y
  # CONFIG_COMPAL_LAPTOP is not set
  # CONFIG_COMPAT is not set
+# CONFIG_COMPAT_32BIT_TIME is not set
  # CONFIG_COMPAT_BRK is not set
  # CONFIG_COMPILE_TEST is not set
  # CONFIG_CONFIGFS_FS is not set





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


[PATCH] realtek: ZyXEL GS1900-48: fix system LED polarity

2022-02-20 Thread Sander Vanheule
When driven by a GPIO pin, the system LED needs to be configured as
active high. Otherwise the LED switches off after booting and
initialisation.

Fixes: 47f5a0a3eed5 ("realtek: Add support for ZyXEL GS1900-48 Switch")
Signed-off-by: Sander Vanheule 
---
 target/linux/realtek/dts-5.10/rtl8393_zyxel_gs1900-48.dts | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/target/linux/realtek/dts-5.10/rtl8393_zyxel_gs1900-48.dts 
b/target/linux/realtek/dts-5.10/rtl8393_zyxel_gs1900-48.dts
index 9deecd636e31..8cc46635c424 100644
--- a/target/linux/realtek/dts-5.10/rtl8393_zyxel_gs1900-48.dts
+++ b/target/linux/realtek/dts-5.10/rtl8393_zyxel_gs1900-48.dts
@@ -28,7 +28,7 @@
 
led_sys: sys {
label = "green:sys";
-   gpios = < 0 GPIO_ACTIVE_LOW>;
+   gpios = < 0 GPIO_ACTIVE_HIGH>;
};
};
 
-- 
2.35.1


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


[PATCH] realtek: move RTL8231 definitions to board files

2022-02-20 Thread Sander Vanheule
The RTL8231 is an external chip, and not part of the SoC. That means
it is more appropriate to define it in the board specific (base) files,
instead of the DT include for the SoC itself.

Moving the RTL8231 definition also ensures that boards with no GPIO
expander, or an alternative one, don't have a useless gpio1 node label
defined.

Tested on a Netgear GS110TPPv1.

Signed-off-by: Sander Vanheule 
---
 .../dts-5.10/rtl8380_netgear_gigabit.dtsi   | 11 ++-
 .../realtek/dts-5.10/rtl8380_zyxel_gs1900.dtsi  | 17 ++---
 .../dts-5.10/rtl8382_d-link_dgs-1210-10p.dts|  7 +++
 target/linux/realtek/dts-5.10/rtl838x.dtsi  |  9 -
 4 files changed, 23 insertions(+), 21 deletions(-)

diff --git a/target/linux/realtek/dts-5.10/rtl8380_netgear_gigabit.dtsi 
b/target/linux/realtek/dts-5.10/rtl8380_netgear_gigabit.dtsi
index db411def30d7..078f8ff22892 100644
--- a/target/linux/realtek/dts-5.10/rtl8380_netgear_gigabit.dtsi
+++ b/target/linux/realtek/dts-5.10/rtl8380_netgear_gigabit.dtsi
@@ -28,12 +28,13 @@
gpios = < 13 GPIO_ACTIVE_LOW>;
open-source;
};
-};
-
- {
-   status = "okay";
 
-   indirect-access-bus-id = <31>;
+   gpio1: rtl8231-gpio {
+   compatible = "realtek,rtl8231-gpio";
+   #gpio-cells = <2>;
+   gpio-controller;
+   indirect-access-bus-id = <31>;
+   };
 };
 
  {
diff --git a/target/linux/realtek/dts-5.10/rtl8380_zyxel_gs1900.dtsi 
b/target/linux/realtek/dts-5.10/rtl8380_zyxel_gs1900.dtsi
index 7095006454a9..5993c1b798df 100644
--- a/target/linux/realtek/dts-5.10/rtl8380_zyxel_gs1900.dtsi
+++ b/target/linux/realtek/dts-5.10/rtl8380_zyxel_gs1900.dtsi
@@ -39,15 +39,18 @@
gpios = < 0 GPIO_ACTIVE_HIGH>;
};
};
-};
 
- {
-   status = "okay";
+   gpio1: rtl8231-gpio {
+   compatible = "realtek,rtl8231-gpio";
+   #gpio-cells = <2>;
+   gpio-controller;
+   indirect-access-bus-id = <0>;
 
-   poe_enable {
-   gpio-hog;
-   gpios = <13 0>;
-   output-high;
+   poe_enable {
+   gpio-hog;
+   gpios = <13 GPIO_ACTIVE_HIGH>;
+   output-high;
+   };
};
 };
 
diff --git a/target/linux/realtek/dts-5.10/rtl8382_d-link_dgs-1210-10p.dts 
b/target/linux/realtek/dts-5.10/rtl8382_d-link_dgs-1210-10p.dts
index a0f377c4f4a7..3321887c9a5b 100644
--- a/target/linux/realtek/dts-5.10/rtl8382_d-link_dgs-1210-10p.dts
+++ b/target/linux/realtek/dts-5.10/rtl8382_d-link_dgs-1210-10p.dts
@@ -44,6 +44,13 @@
linux,code = ;
};*/
};
+
+   gpio1: rtl8231-gpio {
+   compatible = "realtek,rtl8231-gpio";
+   #gpio-cells = <2>;
+   gpio-controller;
+   indirect-access-bus-id = <0>;
+   };
 };
 
 
diff --git a/target/linux/realtek/dts-5.10/rtl838x.dtsi 
b/target/linux/realtek/dts-5.10/rtl838x.dtsi
index bfe75b8eb241..11cabc3f63cb 100644
--- a/target/linux/realtek/dts-5.10/rtl838x.dtsi
+++ b/target/linux/realtek/dts-5.10/rtl838x.dtsi
@@ -169,15 +169,6 @@
};
};
 
-   gpio1: rtl8231-gpio {
-   compatible = "realtek,rtl8231-gpio";
-   #gpio-cells = <2>;
-   indirect-access-bus-id = <0>;
-   gpio-controller;
-
-   status = "disabled";
-   };
-
pinmux: pinmux@1b001000 {
compatible = "pinctrl-single";
reg = <0x1b001000 0x4>;
-- 
2.35.1


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


[PATCH] realtek: use higher priority for timer interrupts

2022-02-20 Thread Sander Vanheule
The assigned output index for the event timers was quite low, lower even
than the ethernet interrupt. This means that high network load could
preempt timer interrupts, possibly leading to all sorts of strange
behaviour.

Increase the interrupt output index of the event timers to 5, which is
the highest priority output and corresponds to the (otherwise unused)
MIPS CPU timer interrupt.

Fixes: a75b9e3ecb61 ("realtek: Adding RTL930X sub-target")
Signed-off-by: Sander Vanheule 
---
 target/linux/realtek/dts-5.10/rtl930x.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/target/linux/realtek/dts-5.10/rtl930x.dtsi 
b/target/linux/realtek/dts-5.10/rtl930x.dtsi
index 12407a307313..31c021134261 100644
--- a/target/linux/realtek/dts-5.10/rtl930x.dtsi
+++ b/target/linux/realtek/dts-5.10/rtl930x.dtsi
@@ -64,7 +64,7 @@
#interrupt-cells = <1>;
 
interrupt-parent = <>;
-   interrupts = <7 1>, <8 2>;
+   interrupts = <7 5>, <8 5>;
};
 
spi0: spi@1200 {
-- 
2.35.1


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


[PATCH] realtek: ZyXEL GS1900-48: drop status from gpio1

2022-02-20 Thread Sander Vanheule
The default value for a DT node's status property is already "okay", so
there's no need to specify it again. Drop the status property to clean
up the DTS.

Signed-off-by: Sander Vanheule 
---
 target/linux/realtek/dts-5.10/rtl8393_zyxel_gs1900-48.dts | 2 --
 1 file changed, 2 deletions(-)

diff --git a/target/linux/realtek/dts-5.10/rtl8393_zyxel_gs1900-48.dts 
b/target/linux/realtek/dts-5.10/rtl8393_zyxel_gs1900-48.dts
index 8cc46635c424..dd392c5a9beb 100644
--- a/target/linux/realtek/dts-5.10/rtl8393_zyxel_gs1900-48.dts
+++ b/target/linux/realtek/dts-5.10/rtl8393_zyxel_gs1900-48.dts
@@ -37,8 +37,6 @@
#gpio-cells = <2>;
indirect-access-bus-id = <3>;
gpio-controller;
-
-   status = "okay";
};
 
gpio-restart {
-- 
2.35.1


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


[PATCH] realtek: consolidate bootargs again

2022-02-20 Thread Sander Vanheule
Bootargs for devices in the realtek target were previously consolidated
in commit af2cfbda2bf5 ("realtek: Consolidate bootargs"), since all
devices currently use the same arguments.

Commit a75b9e3ecb61 ("realtek: Adding RTL930X sub-target") reverted this
without any argumentation, so let's undo that.

Commit 0b8dfe085180 ("realtek: Add RTL931X sub-target") introduced the
old bootargs also for RTL931x, without providing any actual device
support. Until that is done, let's assume vendors will have done what
they did before, and use a baud rate of 115200.

Fixes: a75b9e3ecb61 ("realtek: Adding RTL930X sub-target")
Signed-off-by: Sander Vanheule 
---
 target/linux/realtek/dts-5.10/rtl8393_zyxel_gs1900-48.dts  | 4 
 target/linux/realtek/dts-5.10/rtl839x.dtsi | 2 +-
 target/linux/realtek/dts-5.10/rtl9302_zyxel_xgs1250-12.dts | 4 
 target/linux/realtek/dts-5.10/rtl930x.dtsi | 2 +-
 target/linux/realtek/dts-5.10/rtl931x.dtsi | 2 +-
 5 files changed, 3 insertions(+), 11 deletions(-)

diff --git a/target/linux/realtek/dts-5.10/rtl8393_zyxel_gs1900-48.dts 
b/target/linux/realtek/dts-5.10/rtl8393_zyxel_gs1900-48.dts
index f72b654b570e..9deecd636e31 100644
--- a/target/linux/realtek/dts-5.10/rtl8393_zyxel_gs1900-48.dts
+++ b/target/linux/realtek/dts-5.10/rtl8393_zyxel_gs1900-48.dts
@@ -21,10 +21,6 @@
reg = <0x0 0x800>;
};
 
-   chosen {
-   bootargs = "console=ttyS0,115200";
-   };
-
leds {
pinctrl-names = "default";
pinctrl-0 = <_disable_sys_led>;
diff --git a/target/linux/realtek/dts-5.10/rtl839x.dtsi 
b/target/linux/realtek/dts-5.10/rtl839x.dtsi
index 19da1c11cbed..3325dd9969cd 100644
--- a/target/linux/realtek/dts-5.10/rtl839x.dtsi
+++ b/target/linux/realtek/dts-5.10/rtl839x.dtsi
@@ -65,7 +65,7 @@
};
 
chosen {
-   bootargs = "console=ttyS0,38400";
+   bootargs = "console=ttyS0,115200";
};
 
lx_clk: lx_clk {
diff --git a/target/linux/realtek/dts-5.10/rtl9302_zyxel_xgs1250-12.dts 
b/target/linux/realtek/dts-5.10/rtl9302_zyxel_xgs1250-12.dts
index 28cace6c108b..d8164fd5c22d 100644
--- a/target/linux/realtek/dts-5.10/rtl9302_zyxel_xgs1250-12.dts
+++ b/target/linux/realtek/dts-5.10/rtl9302_zyxel_xgs1250-12.dts
@@ -10,10 +10,6 @@
compatible = "zyxel,xgs1250-12", "realtek,rtl838x-soc";
model = "Zyxel XGS1250-12 Switch";
 
-   chosen {
-   bootargs = "console=ttyS0,115200";
-   };
-
keys {
compatible = "gpio-keys";
 
diff --git a/target/linux/realtek/dts-5.10/rtl930x.dtsi 
b/target/linux/realtek/dts-5.10/rtl930x.dtsi
index ebacdde68f25..12407a307313 100644
--- a/target/linux/realtek/dts-5.10/rtl930x.dtsi
+++ b/target/linux/realtek/dts-5.10/rtl930x.dtsi
@@ -25,7 +25,7 @@
};
 
chosen {
-   bootargs = "console=ttyS0,38400";
+   bootargs = "console=ttyS0,115200";
};
 
cpuintc: cpuintc {
diff --git a/target/linux/realtek/dts-5.10/rtl931x.dtsi 
b/target/linux/realtek/dts-5.10/rtl931x.dtsi
index 8dd4cfdc928c..29aee1f7b268 100644
--- a/target/linux/realtek/dts-5.10/rtl931x.dtsi
+++ b/target/linux/realtek/dts-5.10/rtl931x.dtsi
@@ -30,7 +30,7 @@
};

chosen {
-   bootargs = "console=ttyS0,38400";
+   bootargs = "console=ttyS0,115200";
};
 
lx_clk: lx_clk {
-- 
2.35.1


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


[PATCH] realtek: fix node addresses for RTL839x

2022-02-20 Thread Sander Vanheule
The address in some node names doesn't match the actual offset specified
in the DT node. Update the names to fix this.

While fixing the node names, also drop the unused node labels.

Fixes: 0a7565e53653 ("realtek: Update rtl839x.dtsi for realtek,rtl-intc, new 
gpio controller remove RTL8231 node")
Signed-off-by: Sander Vanheule 
---
 target/linux/realtek/dts-5.10/rtl839x.dtsi | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/target/linux/realtek/dts-5.10/rtl839x.dtsi 
b/target/linux/realtek/dts-5.10/rtl839x.dtsi
index 3325dd9969cd..cfed68eb9534 100644
--- a/target/linux/realtek/dts-5.10/rtl839x.dtsi
+++ b/target/linux/realtek/dts-5.10/rtl839x.dtsi
@@ -140,7 +140,7 @@
status = "disabled";
};
 
-   gpio0: gpio-controller@b3500 {
+   gpio0: gpio-controller@3500 {
compatible = "realtek,rtl8390-gpio", 
"realtek,otto-gpio";
reg = <0x3500 0x20>;
 
@@ -170,7 +170,7 @@
 
};
 
-   pinmux: pinmux@1b001000 {
+   pinmux@1b04 {
compatible = "pinctrl-single";
reg = <0x1b04 0x4>;
 
@@ -185,7 +185,7 @@
};
 
/* LED_GLB_CTRL */
-   pinmux_led: pinmux@1b00a000 {
+   pinmux@1be4 {
compatible = "pinctrl-single";
reg = <0x1be4 0x4>;
 
-- 
2.35.1


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


Re: [PATCH] ipq40xx: fix LED script

2022-02-20 Thread Robert Marko
On Sun, 20 Feb 2022 at 14:28, Christian Lamparter  wrote:
>
> On 20/02/2022 12:39, Robert Marko wrote:
> > Fix the missing missing ;; after the cAP ac case.
> >
> > Fixes: 93d9119 ("ipq40xx: add MikroTik cAP ac support")
> > Signed-off-by: Robert Marko 
>
> Merged. Thanks! Had to change the SoB as it didn't match
> and openwrt.git doesn't let me push otherwise.

Thanks, I realized that I sent it from the wrong email only after sending it.
Regards,
Robert

>
> Cheers,
> Christian

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


Re: [PATCH] ipq40xx: fix LED script

2022-02-20 Thread Christian Lamparter

On 20/02/2022 12:39, Robert Marko wrote:

Fix the missing missing ;; after the cAP ac case.

Fixes: 93d9119 ("ipq40xx: add MikroTik cAP ac support")
Signed-off-by: Robert Marko 


Merged. Thanks! Had to change the SoB as it didn't match
and openwrt.git doesn't let me push otherwise.

Cheers,
Christian

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


[PATCH] ipq40xx: fix LED script

2022-02-20 Thread Robert Marko
Fix the missing missing ;; after the cAP ac case.

Fixes: 93d9119 ("ipq40xx: add MikroTik cAP ac support")
Signed-off-by: Robert Marko 
---
 target/linux/ipq40xx/base-files/etc/board.d/01_leds | 1 +
 1 file changed, 1 insertion(+)

diff --git a/target/linux/ipq40xx/base-files/etc/board.d/01_leds 
b/target/linux/ipq40xx/base-files/etc/board.d/01_leds
index 03ee053fcc..884b265dcb 100644
--- a/target/linux/ipq40xx/base-files/etc/board.d/01_leds
+++ b/target/linux/ipq40xx/base-files/etc/board.d/01_leds
@@ -59,6 +59,7 @@ mikrotik,cap-ac)
ucidef_set_led_switch "eth2" "ETH2" "green:eth2" "switch0" "0x10"
ucidef_set_led_wlan "wlan2g" "WLAN2G" "green:wlan2g" "phy0tpt"
ucidef_set_led_wlan "wlan5g" "WLAN5G" "green:wlan5g" "phy1tpt"
+   ;;
 mikrotik,hap-ac3)
ucidef_set_led_netdev "wan" "WAN" "green:wan" "eth1"
ucidef_set_led_switch "lan1" "LAN1" "green:lan1" "switch0" "0x10"
-- 
2.35.1


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