Re: [PATCH] wireguard-tools: Add dependency on kmod-wireguard

[Rosen Penev]

On Thu, Feb 18, 2021 at 8:31 PM Ilya Lipnitskiy
 wrote:
>
> Hi,
> On Thu, Feb 18, 2021 at 5:57 PM Jason A. Donenfeld  wrote:
> >
> > I've backported WireGuard patch-by patch to 5.4, in a series that you
> > can simply apply to your existing 5.4 kernels. I can prepare that for
> > you guys tomorrow. That way, you'll have the kernel module in both 5.4
> > and 5.10 through the same mechanisms with the same code. That might
> > save a lot of the complexity that this discussion is veering toward.
> >
> > How's that sound?
> I've implemented the virtual package way I proposed in an earlier
> email. The changes are part of this pull request:
> https://github.com/openwrt/openwrt/pull/3885
>
> If the reviewers are happy with my changes I think we are done.
> Otherwise, please chime in if we'd rather go the backport way with
> Jason's help.
The backport route is annoying as it means it would need to be
maintained separately from the module.

It's a moot point anyway. The release will be using the module. This
only concerns snapshot which will migrate to 5.10 eventually.
>
> - Ilya
>
> ___
> 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] wireguard-tools: Add dependency on kmod-wireguard

[Ilya Lipnitskiy]

Hi,
On Thu, Feb 18, 2021 at 5:57 PM Jason A. Donenfeld  wrote:
>
> I've backported WireGuard patch-by patch to 5.4, in a series that you
> can simply apply to your existing 5.4 kernels. I can prepare that for
> you guys tomorrow. That way, you'll have the kernel module in both 5.4
> and 5.10 through the same mechanisms with the same code. That might
> save a lot of the complexity that this discussion is veering toward.
>
> How's that sound?
I've implemented the virtual package way I proposed in an earlier
email. The changes are part of this pull request:
https://github.com/openwrt/openwrt/pull/3885

If the reviewers are happy with my changes I think we are done.
Otherwise, please chime in if we'd rather go the backport way with
Jason's help.

- Ilya

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

Re: [PATCH] wireguard-tools: Add dependency on kmod-wireguard

[Jason A. Donenfeld]

I've backported WireGuard patch-by patch to 5.4, in a series that you
can simply apply to your existing 5.4 kernels. I can prepare that for
you guys tomorrow. That way, you'll have the kernel module in both 5.4
and 5.10 through the same mechanisms with the same code. That might
save a lot of the complexity that this discussion is veering toward.

How's that sound?

Jason

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

[PATCH] openssl: update package sources

[David Bauer]

OpenSSL downloads itself are distributed using Akamai CDN, so use these
sources as the highest priority.

Remove a stale mirror which seems to be offline for a longer time
already.

Add fallbacks to the old release path also for the mirrors.

Signed-off-by: David Bauer 
---
 package/libs/openssl/Makefile | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/package/libs/openssl/Makefile b/package/libs/openssl/Makefile
index 4fb4cb2784..7dbbd65026 100644
--- a/package/libs/openssl/Makefile
+++ b/package/libs/openssl/Makefile
@@ -19,11 +19,13 @@ PKG_BUILD_PARALLEL:=1
 
 PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.gz
 PKG_SOURCE_URL:= \
+   http://www.openssl.org/source/ \
+   http://www.openssl.org/source/old/$(PKG_BASE)/ \
http://ftp.fi.muni.cz/pub/openssl/source/ \
-   http://ftp.linux.hr/pub/openssl/source/ \
+   http://ftp.fi.muni.cz/pub/openssl/source/old/$(PKG_BASE)/ \
ftp://ftp.pca.dfn.de/pub/tools/net/openssl/source/ \
-   http://www.openssl.org/source/ \
-   http://www.openssl.org/source/old/$(PKG_BASE)/
+   ftp://ftp.pca.dfn.de/pub/tools/net/openssl/source/old/$(PKG_BASE)/
+
 PKG_HASH:=aaf2fcb575cdf6491b98ab4829abf78a3dec8402b8b81efc8f23c00d443981bf
 
 PKG_LICENSE:=OpenSSL
-- 
2.30.1


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

Re: [PATCH] wireguard-tools: Add dependency on kmod-wireguard

[Ilya Lipnitskiy]

Hi,

On Thu, Feb 18, 2021 at 11:11 AM Hannu Nyman  wrote:
> There the solution was an additional virtual kernel package, which could then
> handle the kernel mainline / oot dependency difference inside the target.
> https://github.com/openwrt/openwrt/pull/3039
Thanks for all the great feedback. How about this:

1. Convert kmod-wireguard into a virtual package;
2. Create kmod-wireguard-oot (for Linux 5.4) and kmod-wireguard-it
(for Linux 5.10);
3. Remove the virtual wireguard package (no one depends on it);
4. When Linux 5.4 support is removed, remove kmod-wireguard and rename
kmod-wireguard-it to kmod-wireguard.

That way, existing kmod-wireguard dependencies don't have to be touched at all.

Ilya

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

Re: uboot-envtools build error in openwrt-21.02.

[Etan Kissling 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.21, 00:11, "openwrt-devel on behalf of Hauke Mehrtens" 
 wrote:

> On 2/18/21 10:40 PM, Etan Kissling wrote:
> > When building openwrt-21.02 I encountered errors in uboot-envtools.
> >
> > The problem appears since a recent u-boot update.
> > https://github.com/u-boot/u-boot/commit/587e4a4296982f85b2a40fc8a704db65079e0aac
>
> I do not see an build problem in the build bots, could you please post
> your error message and your host operating system?
>
> Hauke

OpenWrt specific builds of u-boot versions before the referenced commit
work fine.

I am using macOS Big Sur 11.2.1 (20D74).

Error log:
touch 
/***/openwrt/build_dir/target-arm_***_musl_eabi/u-boot-2021.01/.prepared_e2aad1e41fdd47db834d95447586b48e_6664517399ebbbc92a37c5bb081b5c53
rm -f 
/***/openwrt/build_dir/target-arm_***_musl_eabi/u-boot-2021.01/.configured_*
rm -f 
/***/openwrt/staging_dir/target-arm_***_musl_eabi/stamp/.uboot-envtools_installed
touch 
/***/openwrt/build_dir/target-arm_***_musl_eabi/u-boot-2021.01/include/config.h
mkdir -p 
/***/openwrt/build_dir/target-arm_***_musl_eabi/u-boot-2021.01/include/config
touch 
/***/openwrt/build_dir/target-arm_***_musl_eabi/u-boot-2021.01/include/config/auto.conf
mkdir -p 
/***/openwrt/build_dir/target-arm_***_musl_eabi/u-boot-2021.01/include/generated
touch 
/***/openwrt/build_dir/target-arm_***_musl_eabi/u-boot-2021.01/include/generated/autoconf.h
touch 
/***/openwrt/build_dir/target-arm_***_musl_eabi/u-boot-2021.01/.configured_68b329da9893e34099c7d8ad5cb9c940
rm -f /***/openwrt/build_dir/target-arm_***_musl_eabi/u-boot-2021.01/.built
touch 
/***/openwrt/build_dir/target-arm_***_musl_eabi/u-boot-2021.01/.built_check
CFLAGS="-Os -pipe -fno-caller-saves -fno-plt -fhonour-copts 
-Wno-error=unused-but-set-variable -Wno-error=unused-result -mfloat-abi=hard 
-fmacro-prefix-map=/***/openwrt/build_dir/target-arm_***_musl_eabi/u-boot-2021.01=u-boot-2021.01
 -Wformat -Werror=format-security -fstack-protector -D_FORTIFY_SOURCE=1 
-Wl,-z,now -Wl,-z,relro  
-I/***/openwrt/staging_dir/toolchain-arm_***_gcc-8.4.0_musl_eabi/usr/include 
-I/***/openwrt/staging_dir/toolchain-arm_***_gcc-8.4.0_musl_eabi/include/fortify
 -I/***/openwrt/staging_dir/toolchain-arm_***_gcc-8.4.0_musl_eabi/include " 
CXXFLAGS="-Os -pipe -fno-caller-saves -fno-plt -fhonour-copts 
-Wno-error=unused-but-set-variable -Wno-error=unused-result -mfloat-abi=hard 
-fmacro-prefix-map=/***/openwrt/build_dir/target-arm_***_musl_eabi/u-boot-2021.01=u-boot-2021.01
 -Wformat -Werror=format-security -fstack-protector -D_FORTIFY_SOURCE=1 
-Wl,-z,now -Wl,-z,relro  
-I/***/openwrt/staging_dir/toolchain-arm_***_gcc-8.4.0_musl_eabi/usr/include 
-I/***/openwrt/staging_dir
make[4]: Entering directory 
'/***/openwrt/build_dir/target-arm_***_musl_eabi/u-boot-2021.01'
  HOSTCC  scripts/basic/fixdep
  UPD include/config/uboot.release
  UPD include/generated/version_autogenerated.h
  UPD include/generated/timestamp_autogenerated.h
  COPYtools/version.h
  LD  tools/env/built-in.o
  HOSTCC  tools/env/crc32.o
cc1: note: someone does not honour COPTS correctly, passed 0 times
  HOSTCC  tools/env/ctype.o
cc1: note: someone does not honour COPTS correctly, passed 0 times
  HOSTCC  tools/env/env_attr.o
cc1: note: someone does not honour COPTS correctly, passed 0 times
  HOSTCC  tools/env/env_flags.o
cc1: note: someone does not honour COPTS correctly, passed 0 times
  HOSTCC  tools/env/fw_env.o
cc1: note: someone does not honour COPTS correctly, passed 0 times
  HOSTCC  tools/env/linux_string.o
cc1: note: someone does not honour COPTS correctly, passed 0 times
  AR  tools/env/lib.a
  HOSTCC  tools/env/fw_env_main.o
cc1: note: someone does not honour COPTS correctly, passed 0 times
  HOSTLD  tools/env/fw_printenv
/***/openwrt/staging_dir/toolchain-arm_***_gcc-8.4.0_musl_eabi/lib/gcc/arm-openwrt-linux-muslgnueabi/8.4.0/../../../../arm-openwrt-linux-muslgnueabi/bin/ld:
 cannot find -lgcc_s
/***/openwrt/staging_dir/toolchain-arm_***_gcc-8.4.0_musl_eabi/lib/gcc/arm-openwrt-linux-muslgnueabi/8.4.0/../../../../arm-openwrt-linux-muslgnueabi/bin/ld:
 cannot find -lgcc_s
collect2: error: ld returned 1 exit status
make[5]: *** [scripts/Makefile.host:104: tools/env/fw_printenv] Error 1
make[4]: *** [Makefile:1995: envtools] Error 2
make[4]: Leaving directory 
'/***/openwrt/build_dir/target-arm_***_musl_eabi/u-boot-2021.01'
make[3]: *** [Makefile:82: 
/***/openwrt/build_dir/target-arm_***_musl_eabi/u-boot-2021.01/.built] Error 2
make[3]: Leaving directory '/***/openwrt/package/boot/uboot-envtools'
time: package/boot/uboot-envtools/compile#4.31#3.50#7.75
ERROR: package/boot/uboot-envtools failed to build.
make[2]: *** [package/Makefile:114: package/boot/uboot-envtools/compile] Error 1
make[2

[PATCH] ramips: remove factory image for TP-Link Archer C20 v1

[Stijn Segers]

Similarly to the Archer C2 v1, the Archer C20 v1 will brick when one
tries to flash an OpenWrt factory image through the TP-Link web UI.
The wiki page contains an explicit warning about this [1].

Disable the factory image altogether since it serves no purpose.

[1] https://openwrt.org/toh/tp-link/tp-link_archer_c20_v1#installation

Signed-off-by: Stijn Segers 
---
 target/linux/ramips/image/mt7620.mk | 1 +
 1 file changed, 1 insertion(+)

diff --git a/target/linux/ramips/image/mt7620.mk 
b/target/linux/ramips/image/mt7620.mk
index 7f649aff88..f8905ad2b7 100644
--- a/target/linux/ramips/image/mt7620.mk
+++ b/target/linux/ramips/image/mt7620.mk
@@ -981,6 +981,7 @@ define Device/tplink_archer-c20-v1
   TPLINK_HWID := 0xc201
   TPLINK_HWREV := 0x44
   TPLINK_HWREVADD := 0x1
+  IMAGES := sysupgrade.bin
   DEVICE_MODEL := Archer C20
   DEVICE_VARIANT := v1
   DEVICE_PACKAGES := kmod-mt76x0e kmod-usb2 kmod-usb-ohci \
-- 
2.30.0


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

[PATCH v2] uboot-envtools: add support for ZyXEL GS-1900-8HP v1 and v2

[Stijn Segers]

This adds the necessary nuts and bolts for the uboot settings for both the 
ZyXEL GS1900-8HP v1 and v2.

Signed-off-by: Stijn Segers 
---
Changes in v2: fix syntax error, better English.
---
 package/boot/uboot-envtools/files/realtek | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/package/boot/uboot-envtools/files/realtek 
b/package/boot/uboot-envtools/files/realtek
index b64bb23b07..b415fcedc9 100644
--- a/package/boot/uboot-envtools/files/realtek
+++ b/package/boot/uboot-envtools/files/realtek
@@ -11,6 +11,8 @@ case "$board" in
 d-link,dgs-1210-16|\
 d-link,dgs-1210-28|\
 d-link,dgs-1210-10p|\
+zyxel,gs1900-8hp-v1|\
+zyxel,gs1900-8hp-v2|\
 zyxel,gs1900-10hp)
idx="$(find_mtd_index u-boot-env)"
[ -n "$idx" ] && \
-- 
2.30.0


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

Re: uboot-envtools build error in openwrt-21.02.

[Hauke Mehrtens]

On 2/18/21 10:40 PM, Etan Kissling wrote:

When building openwrt-21.02 I encountered errors in uboot-envtools.

The problem appears since a recent u-boot update.
https://github.com/u-boot/u-boot/commit/587e4a4296982f85b2a40fc8a704db65079e0aac

Etan

Hi,

I do not see an build problem in the build bots, could you please post 
your error message and your host operating system?


Hauke



OpenPGP_signature
Description: OpenPGP digital signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[PATCH] uboot-envtools: add support for ZyXEL GS1900-8HP v1 and v2

[Stijn Segers]

Adds the bits and bolts for the uboot settings for both the ZyXEL
GS1900-8HP v1 and v2.

Signed-off-by: Stijn Segers 
---
 package/boot/uboot-envtools/files/realtek | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/package/boot/uboot-envtools/files/realtek 
b/package/boot/uboot-envtools/files/realtek
index b64bb23b07..6507f34349 100644
--- a/package/boot/uboot-envtools/files/realtek
+++ b/package/boot/uboot-envtools/files/realtek
@@ -11,6 +11,8 @@ case "$board" in
 d-link,dgs-1210-16|\
 d-link,dgs-1210-28|\
 d-link,dgs-1210-10p|\
+zyxel,gs1900-8hp-v1\
+zyxel,gs1900-8hp-v2|\
 zyxel,gs1900-10hp)
idx="$(find_mtd_index u-boot-env)"
[ -n "$idx" ] && \
-- 
2.30.0


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

OpenWrt 19.07.7 service release

[Baptiste Jonglez]

Hi,

The OpenWrt community is proud to announce the seventh service release of
OpenWrt 19.07. It fixes security issues, improves device support, and
brings a few bug fixes.

The main changes from OpenWrt 19.07.6 are:

Security fixes
==

* Security Advisory 2021-02-02-1 - netifd and odhcp6c routing loop on IPv6
  point to point links (CVE-2021-22161)

* Security Advisory 2021-02-02-2 - wolfSSL heap buffer overflow in
  RsaPad_PSS (CVE-2020-36177)

Major bug fixes
===

* Fix dnsmasq error messages such as "failed to send packet: Network
  unreachable" or "failed to send packet: Address family not supported by
  protocol" that could be filling up logs. This was a regression caused by
  the dnsmasq update in 19.07.6.

* Fix opkg so that it purges obsolete packages from its local cache. This
  fixes a long-standing issue in the ImageBuilder where a manual cleanup
  was needed before rebuilding.

Device support
==

* Improve stability of mediatek Ethernet switch (affects many mt7621
  devices)

* Fix Wi-Fi band detection on some Broadcom-based devices

* Fix poor 2.4 GHz Wi-Fi performance on TP-Link Archer C50 v4 due to a
  missing EEPROM chip ID

* Make initramfs image usable out-of-the-box on Turris Omnia

* Use full flash size on Nucom R5010UN v2

* Fix support for TP-Link TL-WR810N v1 in ath79

* Remove broken factory image for TP-Link Archer C2 v1

* Fix unintended failsafe mode during boot on Netgear EX6150

Various fixes and improvements
==

* The ImageBuilder no longer requires compilers (gcc, g++) and
  libncurses-dev. This was partially implemented in 19.07.6 but one part
  was missing to make it actually work.

* Update to a new major version of ksmbd to fix several bugs. This breaks
  compatibility with previous versions of OpenWrt (19.07.0 to 19.07.6): it
  is no longer possible to install a working version of ksmbd-tools on
  previous versions of OpenWrt. Existing installations will keep working,
  but ksmbd-tools should not be upgraded with opkg.

Unfortunately, this ksmbd update introduced a regression: the kernel
module package for ksmbd depends on the non-existant kmod-crypto-arc4.
If you are affected by this issue, see 
https://openwrt.org/releases/19.07/notes-19.07.7#regressions
for a workaround.

LuCI web interface
==

* Fix array sorting on Chrome
* Add nextdns.io and quad 101 providers to luci-app-https-dns-proxy package

Core components
===

* Update Linux kernel from 4.14.215 to 4.14.221

* Update wolfssl from 4.5.0 to 4.6.0


Full release notes and upgrade instructions are available at
https://openwrt.org/releases/19.07/notes-19.07.7

In particular, make sure to read the regressions and known issues before
upgrading:
https://openwrt.org/releases/19.07/notes-19.07.7#regressions

For a very detailed list of all changes since 19.07.6, refer to
https://openwrt.org/releases/19.07/changelog-19.07.7

For latest information about the 19.07 series, refer to the wiki at:
https://openwrt.org/releases/19.07/

To download a OpenWrt 19.07.7 firmware image for your device, head to the
Table of Hardware:
https://openwrt.org/toh/start

Or use the new firmware selector:
https://firmware-selector.openwrt.org/

You can also navigate directly in the list of firmware images:
https://downloads.openwrt.org/releases/19.07.6/targets/

As always, a big thank you goes to all our active package maintainers,
testers, documenters, and supporters.

Have fun!

The OpenWrt Community

---

To stay informed of new OpenWrt releases and security advisories, there
are new channels available:

 * a low-volume mailing list for important announcements:
https://lists.openwrt.org/mailman/listinfo/openwrt-announce

 * a dedicated "announcements" section in the forum:
https://forum.openwrt.org/c/announcements/14

 * other announcement channels (such as RSS feeds) might be added in the
   future, they will be listed at https://openwrt.org/contact


signature.asc
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

uboot-envtools build error in openwrt-21.02.

[Etan Kissling 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 ---
When building openwrt-21.02 I encountered errors in uboot-envtools.

The problem appears since a recent u-boot update.
https://github.com/u-boot/u-boot/commit/587e4a4296982f85b2a40fc8a704db65079e0aac

Etan




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

[PATCH v2] ramips: mt7621: add TP-Link EAP235-Wall support

[Sander Vanheule]

The TP-Link EAP235-Wall is a wall-mounted, PoE-powered AC1200 access
point with four gigabit ethernet ports.

When connecting to the device's serial port, it is strongly advised to
use an isolated UART adapter. This prevents linking different power
domains created by the PoE power supply, which may damage your devices.

The device's U-Boot supports saving modified environments with
`saveenv`. However, there is no u-boot-env partition, and saving
modifications will cause the partition table to be overwritten. This is
not an issue for running OpenWrt, but will prevent the vendor FW from
functioning properly.

Device specifications:
* SoC: MT7621DAT
* RAM: 128MiB
* Flash: 16MiB SPI-NOR
* Wireless 2.4GHz (MT7603EN): b/g/n, 2x2
* Wireless 5GHz (MT7613BEN): a/n/ac, 2x2
* Ethernet: 4× GbE
  * Back side: ETH0, PoE PD port
  * Bottom side: ETH1, ETH2, ETH3
* Single white device LED
* LED button, reset button (available for failsafe)
* PoE pass-through on port ETH3 (enabled with GPIO)

Datasheet of the flash chip specifies a maximum frequency of 33MHz, but
that didn't work. 20MHz gives no errors with reading (flash dump) or
writing (sysupgrade).

Device mac addresses:
Stock firmware uses the same MAC address for ethernet (on device label)
and 2.4GHz wireless. The 5GHz wireless address is incremented by one.
This address is stored in the 'info' ('default-mac') partition at an
offset of 8 bytes.
From OEM ifconfig:
eth a4:2b:b0:...:88
ra0 a4:2b:b0:...:88
rai0a4:2b:b0:...:89

Flashing instructions:
* Enable SSH in the web interface, and SSH into the target device
* run `cliclientd stopcs`, this should return "success"
* upload the factory image via the web interface

Debricking:
U-boot can be interrupted during boot, serial console is 57600 baud, 8n1
This allows installing a sysupgrade image, or fixing the device in
another way.
* Access serial header from the side of the board, close to ETH3,
  pin-out is (1:TX, 2:RX, 3:GND, 4:3.3V), with pin 1 closest to ETH3.
* Interrupt bootloader by holding '4' during boot, which drops the
  bootloader into its shell
* Change default 'serverip' and 'ipaddr' variables (optional)
* Download initramfs with `tftpboot`, and boot image with `bootm`
# tftpboot 8400 openwrt-initramfs.bin
# bootm

Revert to stock:
Using the tplink-safeloader utility from the firmware-utils package,
TP-Link's firmware image can be converted to an OpenWrt-compatible
sysupgrade image:
  $ ./staging_dir/host/bin/tplink-safeloader -B EAP235-WALL-V1 \
  -z EAP235-WALLv1_XXX_up_signed.bin -o eap235-sysupgrade.bin

This can then be flashed using the OpenWrt sysupgrade interface. The
image will appear to be incompatible and must be force flashed, without
keeping the current configuration.

Known issues:
- DFS support is incomplete (known issue with MT7613)
- MT7613 radio may stop responding when idling, reboot required.
  This was an issue with the ddc75ff704 version of mt76, but appears to
  have improved/disappeared with bc3963764d.
  Error notice example:
  [ 7099.554067] mt7615e :02:00.0: Message 73 (seq 1) timeout

Hardware was kindly provided for porting by Stijn Segers.

Tested-by: Stijn Segers 
Signed-off-by: Sander Vanheule 
---
Changes in v2:
- Added instructions on how to revert to stock in commit message (Stijn)
- Added missing Device/dsa-migration in build recipe
- Make device vendor/model name capitalisation consistent (Adrian)
- Naming improvements in DTS (Adrian)
- Add known issues to commit message (Adrian)
- DTS: state_default node with explicit GPIO selection (Adrian)

 .../dts/mt7621_tplink_eap235-wall-v1.dts  | 180 ++
 target/linux/ramips/image/mt7621.mk   |  13 ++
 .../mt7621/base-files/etc/board.d/02_network  |   3 +
 tools/firmware-utils/src/tplink-safeloader.c  |  29 +++
 4 files changed, 225 insertions(+)
 create mode 100644 target/linux/ramips/dts/mt7621_tplink_eap235-wall-v1.dts

diff --git a/target/linux/ramips/dts/mt7621_tplink_eap235-wall-v1.dts 
b/target/linux/ramips/dts/mt7621_tplink_eap235-wall-v1.dts
new file mode 100644
index 00..17308eb605
--- /dev/null
+++ b/target/linux/ramips/dts/mt7621_tplink_eap235-wall-v1.dts
@@ -0,0 +1,180 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+
+#include "mt7621.dtsi"
+
+#include 
+#include 
+#include 
+
+/ {
+   compatible = "tplink,eap235-wall-v1", "mediatek,mt7621-soc";
+   model = "TP-Link EAP235-Wall v1";
+
+   aliases {
+   label-mac-device = &gmac0;
+   led-boot = &led_status;
+   led-failsafe = &led_status;
+   led-running = &led_status;
+   led-upgrade = &led_status;
+   };
+
+   leds {
+   compatible = "gpio-leds";
+
+   led_status: status {
+   label = "white:status";
+   color = ;
+   function = LED_FUNCTION_STATUS;
+   gpios = <&gpio 12 GPIO_ACTIVE_LOW>;
+   };

Re: [PATCH] wireguard-tools: Add dependency on kmod-wireguard

[Hannu Nyman]

Ilya Lipnitskiy kirjoitti 18.2.2021 klo 19.48:

Hi,

On Thu, Feb 18, 2021 at 9:21 AM Adrian Schmutzler
 wrote:

I don't really get the point of this justification. Either wireguard-tools depends on 
kmod-wireguard, or it doesn't. In the first case, and only then, it should be 
"fixed" (with a proper justification describing that).

Are wireguard-tools useful without the underlying kernel module? It
didn't seem like it to me, although maybe Jason should chime in here,
as maintainer and developer of Wireguard.



As historical reference, please see the discussion in LuCI PR #855 in 2016, 
when that aspect was discussed:


https://github.com/openwrt/luci/issues/855





The idea is to enable in-tree wireguard kernel modules on Linux 5.10
with a plan to phase out the out-of-tree module when 5.4 is taken out.
Reducing cross-repository dependencies makes it easier to accomplish.



It can be cumbersome to make a user-space package depend on alternative 
kernel package variants depending on the kernel version, as  we have some 
package targets where the user-space package build SDK kernel version might 
differ from the target SDK kernel. There were major difficulties with SQM & 
cake a year ago.


See https://github.com/openwrt/packages/issues/12072

There the solution was an additional virtual kernel package, which could then 
handle the kernel mainline / oot dependency difference inside the target.


https://github.com/openwrt/openwrt/pull/3039



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

Re: [PATCH] wireguard-tools: Add dependency on kmod-wireguard

[Ilya Lipnitskiy]

Adrian,

On Thu, Feb 18, 2021 at 10:38 AM Adrian Schmutzler
 wrote:
> > Are wireguard-tools useful without the underlying kernel module? It didn't
> > seem like it to me, although maybe Jason should chime in here, as maintainer
> > and developer of Wireguard.
>
> Then why didn't you use that as the reason for your patch?
Fair enough, I could be better about writing patch messages - still
working on improving that :)
BTW, this particular patch is superseded by the work in
https://github.com/openwrt/openwrt/pull/3885, so please don't merge
this.

I will try to be more clear in the future.

Ilya

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

RE: [PATCH] remove mistaken partition patch

[Adrian Schmutzler]

Hi,

> -Original Message-
> From: Sebastian Careba [mailto:nitrosh...@yahoo.com]
> Sent: Mittwoch, 17. Februar 2021 08:39
> To: openwrt-devel@lists.openwrt.org
> Cc: Sebastian Careba 
> Subject: [PATCH] remove mistaken partition patch
> 
> Signed-off-by: Sebastian Careba 

This lacks a commit message as well.

Apart from it, the title could be less generic and lacks a proper prefix.

https://openwrt.org/submitting-patches

Best

Adrian

> ---
>  .../999-resize mamba kernel.patch | 50 ---
>  1 file changed, 50 deletions(-)
>  delete mode 100644 target/linux/mvebu/patches-5.10/999-resize mamba
> kernel.patch
> 
> diff --git a/target/linux/mvebu/patches-5.10/999-resize mamba kernel.patch
> b/target/linux/mvebu/patches-5.10/999-resize mamba kernel.patch deleted
> file mode 100644 index a4230a4104..00
> --- a/target/linux/mvebu/patches-5.10/999-resize mamba kernel.patch
> +++ /dev/null
> @@ -1,50 +0,0 @@
> -diff --git a/target/linux/mvebu/patches-5.4/999-DNM-dts-mamba-resize-
> 3MB_to_4MB.patch b/target/linux/mvebu/patches-5.4/999-DNM-dts-
> mamba-resize-3MB_to_4MB.patch
> -new file mode 100644
> -index 00..2752a92a3f
>  /dev/null
> -+++ b/target/linux/mvebu/patches-5.4/999-DNM-dts-mamba-resize-
> 3MB_to_4M
> -+++ B.patch
> -@@ -0,0 +1,41 @@
> -From 258233f00bcd013050efee00c5d9128ef8cd62dd Mon Sep 17 00:00:00
> 2001
> -From: Tad 
> -Date: Fri, 5 Feb 2021 22:32:11 -0500
> -Subject: [PATCH] DNM: ARM: dts: armada-xp-linksys-mamba: Increase
> kernel
> - partition to 4MB
> -
> 
> - arch/arm/boot/dts/armada-xp-linksys-mamba.dts | 8 
> - 1 file changed, 4 insertions(+), 4 deletions(-)
> -
> -diff --git a/arch/arm/boot/dts/armada-xp-linksys-mamba.dts
> b/arch/arm/boot/dts/armada-xp-linksys-mamba.dts
> -index d7bc27ae6..20e859021 100644
>  a/arch/arm/boot/dts/armada-xp-linksys-mamba.dts
> -+++ b/arch/arm/boot/dts/armada-xp-linksys-mamba.dts
> -@@ -456,9 +456,9 @@
> - reg = <0xa0 0x280>;  /* 40MB */
> - };
> -
> --partition@d0 {
> -+partition@e0 {
> - label = "rootfs1";
> --reg = <0xd0 0x250>;  /* 37MB */
> -+reg = <0xe0 0x240>;  /* 36MB */
> - };
> -
> - /* kernel2 overlaps with rootfs2 by design */
> -@@ -467,9 +467,9 @@
> - reg = <0x320 0x280>; /* 40MB */
> - };
> -
> --partition@350 {
> -+partition@360 {
> - label = "rootfs2";
> --reg = <0x350 0x250>; /* 37MB */
> -+reg = <0x360 0x240>; /* 36MB */
> - };
> -
> - /*
> ---
> -2.29.2
> -
> ---
> -2.29.2
> -
> --
> 2.30.0
> 


openpgp-digital-signature.asc
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

RE: [PATCH] mvebu: add linux 5.10 support

[Adrian Schmutzler]

Hi,

> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of Tomasz Maciej Nowak
> Sent: Donnerstag, 18. Februar 2021 19:26
> To: Sebastian Careba ; openwrt-
> de...@lists.openwrt.org
> Subject: Re: [PATCH] mvebu: add linux 5.10 support
> 
> Hi Sebastian.
> 
> W dniu 17.02.2021 o 08:00, Sebastian Careba pisze:
> > Signed-off-by: Sebastian Careba 
> 
> You have multiply issues with this kernel bump, some I'll write here, some
> inline.
> 
> The lack of commit message, explaining why You dropped some patches
> when transitioning from 5.4 to 5.10.
> What also missing is: config refresh for cortexa53, cortexa72, and split of 
> files
> because dts for ESPRESSObin got upstreamed.
> For example how to do it better (I don't claim it's proper), You can check
> what I did two weeks ago in this tree:
> https://github.com/tmn505/openwrt/commits/mvebu-next
> the commits lack commit messages (I had intention to add them later), but
> You'll get a gist of the changes, and that way You'll preserve changes
> between major kernel bumps.


like Tomasz says.

In addition, for this target I'd like to see a split into several commits, like 
Tomasz did in his reference, at least:

1. copy config/files/patches
2. refresh patches
3. refresh config
4. do other stuff

That way it's much easier to see what the actual changes are.

Best

Adrian

> 
> > ---
> >  target/linux/mvebu/Makefile   |   8 +-
> >  target/linux/mvebu/config-5.10| 436 ++
> >  .../patches-5.10/002-add_powertables.patch| 770
> ++
> >  .../004-add_sata_disk_activity_trigger.patch  |  39 +
> > ...5-linksys_hardcode_nand_ecc_settings.patch |  17 +
> > ...Mangle-bootloader-s-kernel-arguments.patch | 189 +
> > ...sallow-XDP-program-on-hardware-buffe.patch |  53 ++
> >  .../030-linkstation-poweroff.patch|  20 +
> >  .../patches-5.10/100-find_active_root.patch   |  60 ++
> >  .../patches-5.10/102-revert_i2c_delay.patch   |  15 +
> >  .../205-armada-385-rd-mtd-partitions.patch|  19 +
> >  .../206-ARM-mvebu-385-ap-Add-partitions.patch |  35 +
> > ...-armada-xp-linksys-mamba-broken-idle.patch |  10 +
> >  .../231-armada-xp-linksys-mamba-wan.patch |  11 +
> >  .../patches-5.10/240-linksys-status-led.patch |  50 ++
> >  .../241-linksys-use-eth0-as-cpu-port.patch|  25 +
> >  .../250-adjust-compatible-for-linksys.patch   |  68 ++
> >  .../300-mvneta-tx-queue-workaround.patch  |  26 +
> >  ...dicate-failure-to-enter-deeper-sleep.patch |  40 +
> > ...-pci-mvebu-time-out-reset-on-link-up.patch |  60 ++
> > ...5-PCI-aardvark-Improve-link-training.patch | 135 +++
> > ...06-PCI-aardvark-Issue-PERST-via-GPIO.patch |  57 ++
> >  .../407-PCI-aardvark-Add-PHY-support.patch| 116 +++
> >  ...-t-touch-PCIe-registers-if-no-card-c.patch |  50 ++
> > ...-initialization-with-old-Marvell-s-A.patch |  44 +
> > ...da388-clearfog-emmc-on-clearfog-base.patch |  87 ++
> > ...ts-marvell-armada37xx-Add-eth0-alias.patch |  20 +
> > ...witch-PHY-operation-mode-to-2500base.patch |  20 +
> >  .../560-helios4-dts-status-led-alias.patch|  28 +
> >  ...-mvebu-armada-38x-enable-libata-leds.patch |  10 +
> >  .../999-resize mamba kernel.patch |  50 ++
> >  31 files changed, 2565 insertions(+), 3 deletions(-)  create mode
> > 100644 target/linux/mvebu/config-5.10
> 
> Please copy patches from latest master, which have changed numbering
> according to target/linux/generic/PATCHES, it's easier to track backports.
> 
> >  create mode 100644
> > target/linux/mvebu/patches-5.10/002-add_powertables.patch
> >  create mode 100644
> > target/linux/mvebu/patches-5.10/004-add_sata_disk_activity_trigger.pat
> > ch  create mode 100644
> > target/linux/mvebu/patches-5.10/005-
> linksys_hardcode_nand_ecc_settings
> > .patch  create mode 100644
> > target/linux/mvebu/patches-5.10/006-mvebu-Mangle-bootloader-s-
> kernel-a
> > rguments.patch
> 
> I'm missing a chunk from this patch in init/main.c. If it doesn't apply 
> cleanly, it
> doesn't mean You can delete it, please rework it.
> 
> >  create mode 100644
> > target/linux/mvebu/patches-5.10/022-mvneta-driver-disallow-XDP-
> program
> > -on-hardware-buffe.patch  create mode 100644
> > target/linux/mvebu/patches-5.10/030-linkstation-poweroff.patch
> >  create mode 100644
> > target/linux/mvebu/patches-5.10/100-find_active_root.patch
> >  create mode 100644
> > target/linux/mvebu/patches-5.10/102-revert_i2c_delay.patch
> >  create mode 100644
> > target/linux/mvebu/patches-5.10/205-armada-385-rd-mtd-partitions.patch
> >  create mode 100644
> > target/linux/mvebu/patches-5.10/206-ARM-mvebu-385-ap-Add-
> partitions.pa
> > tch  create mode 100644
> > target/linux/mvebu/patches-5.10/230-armada-xp-linksys-mamba-broken-
> idl
> > e.patch  create mode 100644
> > target/linux/mvebu/patches-5.10/231-armada-xp-linksys-mamba-
> wan.patch
> >  create mode 100644
> > target/linux/mvebu/patches-5.10/240-linksys-status-led.pa

RE: [PATCH] wireguard-tools: Add dependency on kmod-wireguard

[Adrian Schmutzler]

Hi,

> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of Ilya Lipnitskiy
> Sent: Donnerstag, 18. Februar 2021 18:48
> To: Adrian Schmutzler 
> Cc: Jason A . Donenfeld ; openwrt-devel  de...@lists.openwrt.org>
> Subject: Re: [PATCH] wireguard-tools: Add dependency on kmod-wireguard
> 
> Hi,
> 
> On Thu, Feb 18, 2021 at 9:21 AM Adrian Schmutzler
>  wrote:
> > I don't really get the point of this justification. Either wireguard-tools
> depends on kmod-wireguard, or it doesn't. In the first case, and only then, it
> should be "fixed" (with a proper justification describing that).
> Are wireguard-tools useful without the underlying kernel module? It didn't
> seem like it to me, although maybe Jason should chime in here, as maintainer
> and developer of Wireguard.

Then why didn't you use that as the reason for your patch?

> 
> > I don't understand how we need all the strategic discussion to decide this.
> That's probably a discussion for later on.

See above.

Best

Adrian

> The idea is to enable in-tree wireguard kernel modules on Linux 5.10 with a
> plan to phase out the out-of-tree module when 5.4 is taken out.
> Reducing cross-repository dependencies makes it easier to accomplish.
> 
> - Ilya
> 
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel


openpgp-digital-signature.asc
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [PATCH] mvebu: add linux 5.10 support

[Tomasz Maciej Nowak]

Hi Sebastian.

W dniu 17.02.2021 o 08:00, Sebastian Careba pisze:
> Signed-off-by: Sebastian Careba 

You have multiply issues with this kernel bump, some I'll write here, some 
inline.

The lack of commit message, explaining why You dropped some patches when 
transitioning from 5.4 to 5.10.
What also missing is: config refresh for cortexa53, cortexa72, and split of 
files because dts for ESPRESSObin got upstreamed.
For example how to do it better (I don't claim it's proper), You can check what 
I did two weeks ago in this tree: 
https://github.com/tmn505/openwrt/commits/mvebu-next
the commits lack commit messages (I had intention to add them later), but 
You'll get a gist of the changes, and that way You'll preserve changes between 
major kernel bumps.

> ---
>  target/linux/mvebu/Makefile   |   8 +-
>  target/linux/mvebu/config-5.10| 436 ++
>  .../patches-5.10/002-add_powertables.patch| 770 ++
>  .../004-add_sata_disk_activity_trigger.patch  |  39 +
>  ...5-linksys_hardcode_nand_ecc_settings.patch |  17 +
>  ...Mangle-bootloader-s-kernel-arguments.patch | 189 +
>  ...sallow-XDP-program-on-hardware-buffe.patch |  53 ++
>  .../030-linkstation-poweroff.patch|  20 +
>  .../patches-5.10/100-find_active_root.patch   |  60 ++
>  .../patches-5.10/102-revert_i2c_delay.patch   |  15 +
>  .../205-armada-385-rd-mtd-partitions.patch|  19 +
>  .../206-ARM-mvebu-385-ap-Add-partitions.patch |  35 +
>  ...-armada-xp-linksys-mamba-broken-idle.patch |  10 +
>  .../231-armada-xp-linksys-mamba-wan.patch |  11 +
>  .../patches-5.10/240-linksys-status-led.patch |  50 ++
>  .../241-linksys-use-eth0-as-cpu-port.patch|  25 +
>  .../250-adjust-compatible-for-linksys.patch   |  68 ++
>  .../300-mvneta-tx-queue-workaround.patch  |  26 +
>  ...dicate-failure-to-enter-deeper-sleep.patch |  40 +
>  ...-pci-mvebu-time-out-reset-on-link-up.patch |  60 ++
>  ...5-PCI-aardvark-Improve-link-training.patch | 135 +++
>  ...06-PCI-aardvark-Issue-PERST-via-GPIO.patch |  57 ++
>  .../407-PCI-aardvark-Add-PHY-support.patch| 116 +++
>  ...-t-touch-PCIe-registers-if-no-card-c.patch |  50 ++
>  ...-initialization-with-old-Marvell-s-A.patch |  44 +
>  ...da388-clearfog-emmc-on-clearfog-base.patch |  87 ++
>  ...ts-marvell-armada37xx-Add-eth0-alias.patch |  20 +
>  ...witch-PHY-operation-mode-to-2500base.patch |  20 +
>  .../560-helios4-dts-status-led-alias.patch|  28 +
>  ...-mvebu-armada-38x-enable-libata-leds.patch |  10 +
>  .../999-resize mamba kernel.patch |  50 ++
>  31 files changed, 2565 insertions(+), 3 deletions(-)
>  create mode 100644 target/linux/mvebu/config-5.10

Please copy patches from latest master, which have changed numbering according 
to target/linux/generic/PATCHES, it's easier to track backports.

>  create mode 100644 target/linux/mvebu/patches-5.10/002-add_powertables.patch
>  create mode 100644 
> target/linux/mvebu/patches-5.10/004-add_sata_disk_activity_trigger.patch
>  create mode 100644 
> target/linux/mvebu/patches-5.10/005-linksys_hardcode_nand_ecc_settings.patch
>  create mode 100644 
> target/linux/mvebu/patches-5.10/006-mvebu-Mangle-bootloader-s-kernel-arguments.patch

I'm missing a chunk from this patch in init/main.c. If it doesn't apply 
cleanly, it doesn't mean You can delete it, please rework it.

>  create mode 100644 
> target/linux/mvebu/patches-5.10/022-mvneta-driver-disallow-XDP-program-on-hardware-buffe.patch
>  create mode 100644 
> target/linux/mvebu/patches-5.10/030-linkstation-poweroff.patch
>  create mode 100644 target/linux/mvebu/patches-5.10/100-find_active_root.patch
>  create mode 100644 target/linux/mvebu/patches-5.10/102-revert_i2c_delay.patch
>  create mode 100644 
> target/linux/mvebu/patches-5.10/205-armada-385-rd-mtd-partitions.patch
>  create mode 100644 
> target/linux/mvebu/patches-5.10/206-ARM-mvebu-385-ap-Add-partitions.patch
>  create mode 100644 
> target/linux/mvebu/patches-5.10/230-armada-xp-linksys-mamba-broken-idle.patch
>  create mode 100644 
> target/linux/mvebu/patches-5.10/231-armada-xp-linksys-mamba-wan.patch
>  create mode 100644 
> target/linux/mvebu/patches-5.10/240-linksys-status-led.patch
>  create mode 100644 
> target/linux/mvebu/patches-5.10/241-linksys-use-eth0-as-cpu-port.patch
>  create mode 100644 
> target/linux/mvebu/patches-5.10/250-adjust-compatible-for-linksys.patch
>  create mode 100644 
> target/linux/mvebu/patches-5.10/300-mvneta-tx-queue-workaround.patch

Also missing chunk here, please rework it.

>  create mode 100644 
> target/linux/mvebu/patches-5.10/400-cpuidle-mvebu-indicate-failure-to-enter-deeper-sleep.patch
>  create mode 100644 
> target/linux/mvebu/patches-5.10/401-pci-mvebu-time-out-reset-on-link-up.patch

>  create mode 100644 
> target/linux/mvebu/patches-5.10/405-PCI-aardvark-Improve-link-training.patch
>  create mode 100644 
> target/linux/mvebu/patches-5.10/406-PCI-aardvark-Issue-PERST-via-GPIO.patch
>  create mode 100644 
> t

Re: [PATCH] wireguard-tools: Add dependency on kmod-wireguard

[Ilya Lipnitskiy]

Hi,

On Thu, Feb 18, 2021 at 9:21 AM Adrian Schmutzler
 wrote:
> I don't really get the point of this justification. Either wireguard-tools 
> depends on kmod-wireguard, or it doesn't. In the first case, and only then, 
> it should be "fixed" (with a proper justification describing that).
Are wireguard-tools useful without the underlying kernel module? It
didn't seem like it to me, although maybe Jason should chime in here,
as maintainer and developer of Wireguard.

> I don't understand how we need all the strategic discussion to decide this. 
> That's probably a discussion for later on.
The idea is to enable in-tree wireguard kernel modules on Linux 5.10
with a plan to phase out the out-of-tree module when 5.4 is taken out.
Reducing cross-repository dependencies makes it easier to accomplish.

- Ilya

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

Re: [PATCH] mpc85xx-p1010: add Kernel 5.10 support

[David Bauer]

Hi,

On 2/18/21 6:16 PM, Adrian Schmutzler wrote:
> Hi,
> 
>> -Original Message-
>> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
>> On Behalf Of David Bauer
>> Sent: Dienstag, 16. Februar 2021 23:48
>> To: openwrt-devel@lists.openwrt.org
>> Subject: [PATCH] mpc85xx-p1010: add Kernel 5.10 support
> 
> no offense, but I wonder whether bumping by subtargets is really the way to 
> go here?

I'd rater bump a subtarget for which i at least know a board boots with the 
patches
than bump the complete target and break 2/3 subtargets in the process.

Best wishes
David

> 
> Best
> 
> Adrian
> 
>>
>> Tested on: Sophos RED 15W
>>
>> The TP-Link WL-WDR4900 needs to be disabled when 5.10 becomes the
>> default kernel.
>>
>> When building with all kmods enabled, the resulting kernel image exceeds
>> the maximum size the bootloader reads from the flash.
>>
>> For more information, see GitHub issue #1773
>>
>> Signed-off-by: David Bauer 
>> ---
>>  target/linux/mpc85xx/config-5.10  | 280 ++
>>  target/linux/mpc85xx/p1010/target.mk  |   2 +
>>  ...85xx-add-gpio-keys-to-of-match-table.patch |  10 +  ...0-powerpc-85xx-tl-
>> wdr4900-v1-support.patch |  83 ++  .../101-powerpc-85xx-hiveap-330-
>> support.patch |  30 ++
>>  .../102-powerpc-add-cmdline-override.patch|  37 +++
>>  .../103-powerpc-85xx-red-15w-rev1.patch   |  29 ++
>>  ...change-P2020RDB-dts-file-for-OpenWRT.patch | 162 ++
>>  .../105-powerpc-85xx-panda-support.patch  |  30 ++
>>  .../106-powerpc-85xx-ws-ap3710i-support.patch |  30 ++  ...ootwrapper-
>> disable-uImage-generation.patch |  42 +++
>>  11 files changed, 735 insertions(+)
>>  create mode 100644 target/linux/mpc85xx/config-5.10  create mode 100644
>> target/linux/mpc85xx/patches-5.10/001-powerpc-85xx-add-gpio-keys-to-of-
>> match-table.patch
>>  create mode 100644 target/linux/mpc85xx/patches-5.10/100-powerpc-85xx-
>> tl-wdr4900-v1-support.patch
>>  create mode 100644 target/linux/mpc85xx/patches-5.10/101-powerpc-85xx-
>> hiveap-330-support.patch
>>  create mode 100644 target/linux/mpc85xx/patches-5.10/102-powerpc-add-
>> cmdline-override.patch
>>  create mode 100644 target/linux/mpc85xx/patches-5.10/103-powerpc-85xx-
>> red-15w-rev1.patch
>>  create mode 100644 target/linux/mpc85xx/patches-5.10/104-powerpc-
>> mpc85xx-change-P2020RDB-dts-file-for-OpenWRT.patch
>>  create mode 100644 target/linux/mpc85xx/patches-5.10/105-powerpc-85xx-
>> panda-support.patch
>>  create mode 100644 target/linux/mpc85xx/patches-5.10/106-powerpc-85xx-
>> ws-ap3710i-support.patch
>>  create mode 100644 target/linux/mpc85xx/patches-5.10/900-powerpc-
>> bootwrapper-disable-uImage-generation.patch
>>
>> diff --git a/target/linux/mpc85xx/config-5.10 b/target/linux/mpc85xx/config-
>> 5.10
>> new file mode 100644
>> index 00..cb0d08ba91
>> --- /dev/null
>> +++ b/target/linux/mpc85xx/config-5.10
>> @@ -0,0 +1,280 @@
>> +# CONFIG_40x is not set
>> +# CONFIG_44x is not set
>> +# CONFIG_ADVANCED_OPTIONS is not set
>> +CONFIG_AR8216_PHY=y
>> +CONFIG_AR8216_PHY_LEDS=y
>> +CONFIG_ARCH_32BIT_OFF_T=y
>> +CONFIG_ARCH_HIBERNATION_POSSIBLE=y
>> +CONFIG_ARCH_KEEP_MEMBLOCK=y
>> +CONFIG_ARCH_MAY_HAVE_PC_FDC=y
>> +CONFIG_ARCH_MIGHT_HAVE_PC_PARPORT=y
>> +CONFIG_ARCH_MIGHT_HAVE_PC_SERIO=y
>> +CONFIG_ARCH_MMAP_RND_BITS=11
>> +CONFIG_ARCH_MMAP_RND_BITS_MAX=17
>> +CONFIG_ARCH_MMAP_RND_BITS_MIN=11
>> +CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MAX=17
>> +CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MIN=11
>> +CONFIG_ARCH_OPTIONAL_KERNEL_RWX=y
>> +CONFIG_ARCH_SUSPEND_POSSIBLE=y
>> +CONFIG_ARCH_WEAK_RELEASE_ACQUIRE=y
>> +CONFIG_ASN1=y
>> +CONFIG_AUDIT_ARCH=y
>> +CONFIG_BLK_MQ_PCI=y
>> +CONFIG_BOOKE=y
>> +CONFIG_BOOKE_WDT=y
>> +# CONFIG_BSC9131_RDB is not set
>> +# CONFIG_BSC9132_QDS is not set
>> +# CONFIG_C293_PCIE is not set
>> +CONFIG_CLONE_BACKWARDS=y
>> +CONFIG_CLZ_TAB=y
>> +CONFIG_CMDLINE="console=ttyS0,115200"
>> +CONFIG_CMDLINE_FROM_BOOTLOADER=y
>> +# CONFIG_CMDLINE_OVERRIDE is not set
>> +# CONFIG_COMMON_CLK is not set
>> +CONFIG_COMPAT_32BIT_TIME=y
>> +# CONFIG_CORENET_GENERIC is not set
>> +# CONFIG_CPM2 is not set
>> +CONFIG_CPU_BIG_ENDIAN=y
>> +CONFIG_CRYPTO_AEAD=y
>> +CONFIG_CRYPTO_AEAD2=y
>> +# CONFIG_CRYPTO_AES_PPC_SPE is not set
>> +CONFIG_CRYPTO_AKCIPHER=y
>> +CONFIG_CRYPTO_AKCIPHER2=y
>> +CONFIG_CRYPTO_AUTHENC=y
>> +CONFIG_CRYPTO_HASH=y
>> +CONFIG_CRYPTO_HASH2=y
>> +CONFIG_CRYPTO_HW=y
>> +CONFIG_CRYPTO_LIB_POLY1305_RSIZE=1
>> +CONFIG_CRYPTO_MANAGER=y
>> +CONFIG_CRYPTO_MANAGER2=y
>> +# CONFIG_CRYPTO_MD5_PPC is not set
>> +CONFIG_CRYPTO_NULL=y
>> +CONFIG_CRYPTO_NULL2=y
>> +CONFIG_CRYPTO_RNG=y
>> +CONFIG_CRYPTO_RNG2=y
>> +CONFIG_CRYPTO_RSA=y
>> +# CONFIG_CRYPTO_SHA1_PPC is not set
>> +# CONFIG_CRYPTO_SHA1_PPC_SPE is not set #
>> CONFIG_CRYPTO_SHA256_PPC_SPE
>> +is not set
>> +CONFIG_DATA_SHIFT=12
>> +CONFIG_DEBUG_BUGVERBOSE=y
>> +CONFIG_DNOTIFY=y
>> +CONFIG_DTC=y
>> +# CONFIG_E200 is not set
>> +CONFIG_E500=y
>> +# CONFIG_E5500_CPU is not set
>> +# CONFIG_E6500_

Re: missing email header

[Sam Kuper]

On Thu, Feb 18, 2021 at 07:46:47AM -0800, Brian Norris wrote:
> On Thu, Feb 18, 2021 at 1:57 AM David Woodhouse wrote:
>> On Wed, 2021-02-17 at 21:52 -0800, Brian Norris wrote:
>>> They've suggested the mailman admin apply a patch ;)
>>
>> I believe I did so yesterday.
> 
> [..] Awesome, thanks.

Thank you, David, for this.  (And for maintaining infradead generally!)

Best,

Sam

-- 
A: When it messes up the order in which people normally read text.
Q: When is top-posting a bad thing?

()  ASCII ribbon campaign. Please avoid HTML emails & proprietary
/\  file formats. (Why? See e.g. https://v.gd/jrmGbS ). Thank you.

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

RE: Patchwork and DMARC emails.

[Adrian Schmutzler]

Hi,

> You are right, sorry for not being clear enough. The wrapping is the
> workaround to avoid breaking the signature. However, it is also possible to
> just forward DKIM messages as is (no changes to From, Subject, Body).
> In that case, the footer would have to be removed. This only works with
> DKIM present, it doesn't when DMARC and SPF are used but no DKIM. Not
> sure how popular that problematic combination is, though.

Unfortunately, finding a provider and client that supports DKIM is really hard 
unless you want to host e-mail yourself.

In contrast, SPF and/or DMARC is doable with semi-professional providers and 
does not have client-constraints at all.

However, this is why I personally do not enforce my SPF in DMARC, since there 
is always some list around that breaks it, and DKIM is impractical ...

Best

Adrian 



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

RE: [PATCH] wireguard-tools: Add dependency on kmod-wireguard

[Adrian Schmutzler]

Hi,

> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of Ilya Lipnitskiy
> Sent: Mittwoch, 17. Februar 2021 21:25
> To: openwrt-devel@lists.openwrt.org
> Cc: Jason A . Donenfeld ; Ilya Lipnitskiy
> 
> Subject: [PATCH] wireguard-tools: Add dependency on kmod-wireguard
> 
> Prepares for wireguard migration to Linux 5.10. The plan is to make luci
> packages depend only on wireguard-tools, then to change the existing
> kmod-wireguard to kmod-wireguard-oot and add the in-tree module for
> 5.10. But for those changes to be made, wireguard-tools needs to depend on
> kmod-wireguard to enable luci repo changes.

I don't really get the point of this justification. Either wireguard-tools 
depends on kmod-wireguard, or it doesn't. In the first case, and only then, it 
should be "fixed" (with a proper justification describing that).
I don't understand how we need all the strategic discussion to decide this. 
That's probably a discussion for later on.

Best

Adrian

> 
> https://github.com/openwrt/openwrt/pull/3876#discussion_r577901541
> 
> Cc: Jason A. Donenfeld 
> Signed-off-by: Ilya Lipnitskiy 
> ---
>  package/network/utils/wireguard-tools/Makefile | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/package/network/utils/wireguard-tools/Makefile
> b/package/network/utils/wireguard-tools/Makefile
> index 3cdbaa785c..3194d3d2a7 100644
> --- a/package/network/utils/wireguard-tools/Makefile
> +++ b/package/network/utils/wireguard-tools/Makefile
> @@ -36,7 +36,7 @@ define Package/wireguard-tools
>URL:=https://www.wireguard.com
>MAINTAINER:=Jason A. Donenfeld 
>TITLE:=WireGuard userspace control program (wg)
> -  DEPENDS:=+@BUSYBOX_CONFIG_IP
> +@BUSYBOX_CONFIG_FEATURE_IP_LINK
> +  DEPENDS:=+@BUSYBOX_CONFIG_IP
> +@BUSYBOX_CONFIG_FEATURE_IP_LINK
> + +kmod-wireguard
>  endef
> 
>  define Package/wireguard-tools/description
> --
> 2.30.1
> 
> 
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel


openpgp-digital-signature.asc
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

RE: [PATCH] mpc85xx-p1010: add Kernel 5.10 support

[Adrian Schmutzler]

Hi,

> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of David Bauer
> Sent: Dienstag, 16. Februar 2021 23:48
> To: openwrt-devel@lists.openwrt.org
> Subject: [PATCH] mpc85xx-p1010: add Kernel 5.10 support

no offense, but I wonder whether bumping by subtargets is really the way to go 
here?

Best

Adrian

> 
> Tested on: Sophos RED 15W
> 
> The TP-Link WL-WDR4900 needs to be disabled when 5.10 becomes the
> default kernel.
> 
> When building with all kmods enabled, the resulting kernel image exceeds
> the maximum size the bootloader reads from the flash.
> 
> For more information, see GitHub issue #1773
> 
> Signed-off-by: David Bauer 
> ---
>  target/linux/mpc85xx/config-5.10  | 280 ++
>  target/linux/mpc85xx/p1010/target.mk  |   2 +
>  ...85xx-add-gpio-keys-to-of-match-table.patch |  10 +  ...0-powerpc-85xx-tl-
> wdr4900-v1-support.patch |  83 ++  .../101-powerpc-85xx-hiveap-330-
> support.patch |  30 ++
>  .../102-powerpc-add-cmdline-override.patch|  37 +++
>  .../103-powerpc-85xx-red-15w-rev1.patch   |  29 ++
>  ...change-P2020RDB-dts-file-for-OpenWRT.patch | 162 ++
>  .../105-powerpc-85xx-panda-support.patch  |  30 ++
>  .../106-powerpc-85xx-ws-ap3710i-support.patch |  30 ++  ...ootwrapper-
> disable-uImage-generation.patch |  42 +++
>  11 files changed, 735 insertions(+)
>  create mode 100644 target/linux/mpc85xx/config-5.10  create mode 100644
> target/linux/mpc85xx/patches-5.10/001-powerpc-85xx-add-gpio-keys-to-of-
> match-table.patch
>  create mode 100644 target/linux/mpc85xx/patches-5.10/100-powerpc-85xx-
> tl-wdr4900-v1-support.patch
>  create mode 100644 target/linux/mpc85xx/patches-5.10/101-powerpc-85xx-
> hiveap-330-support.patch
>  create mode 100644 target/linux/mpc85xx/patches-5.10/102-powerpc-add-
> cmdline-override.patch
>  create mode 100644 target/linux/mpc85xx/patches-5.10/103-powerpc-85xx-
> red-15w-rev1.patch
>  create mode 100644 target/linux/mpc85xx/patches-5.10/104-powerpc-
> mpc85xx-change-P2020RDB-dts-file-for-OpenWRT.patch
>  create mode 100644 target/linux/mpc85xx/patches-5.10/105-powerpc-85xx-
> panda-support.patch
>  create mode 100644 target/linux/mpc85xx/patches-5.10/106-powerpc-85xx-
> ws-ap3710i-support.patch
>  create mode 100644 target/linux/mpc85xx/patches-5.10/900-powerpc-
> bootwrapper-disable-uImage-generation.patch
> 
> diff --git a/target/linux/mpc85xx/config-5.10 b/target/linux/mpc85xx/config-
> 5.10
> new file mode 100644
> index 00..cb0d08ba91
> --- /dev/null
> +++ b/target/linux/mpc85xx/config-5.10
> @@ -0,0 +1,280 @@
> +# CONFIG_40x is not set
> +# CONFIG_44x is not set
> +# CONFIG_ADVANCED_OPTIONS is not set
> +CONFIG_AR8216_PHY=y
> +CONFIG_AR8216_PHY_LEDS=y
> +CONFIG_ARCH_32BIT_OFF_T=y
> +CONFIG_ARCH_HIBERNATION_POSSIBLE=y
> +CONFIG_ARCH_KEEP_MEMBLOCK=y
> +CONFIG_ARCH_MAY_HAVE_PC_FDC=y
> +CONFIG_ARCH_MIGHT_HAVE_PC_PARPORT=y
> +CONFIG_ARCH_MIGHT_HAVE_PC_SERIO=y
> +CONFIG_ARCH_MMAP_RND_BITS=11
> +CONFIG_ARCH_MMAP_RND_BITS_MAX=17
> +CONFIG_ARCH_MMAP_RND_BITS_MIN=11
> +CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MAX=17
> +CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MIN=11
> +CONFIG_ARCH_OPTIONAL_KERNEL_RWX=y
> +CONFIG_ARCH_SUSPEND_POSSIBLE=y
> +CONFIG_ARCH_WEAK_RELEASE_ACQUIRE=y
> +CONFIG_ASN1=y
> +CONFIG_AUDIT_ARCH=y
> +CONFIG_BLK_MQ_PCI=y
> +CONFIG_BOOKE=y
> +CONFIG_BOOKE_WDT=y
> +# CONFIG_BSC9131_RDB is not set
> +# CONFIG_BSC9132_QDS is not set
> +# CONFIG_C293_PCIE is not set
> +CONFIG_CLONE_BACKWARDS=y
> +CONFIG_CLZ_TAB=y
> +CONFIG_CMDLINE="console=ttyS0,115200"
> +CONFIG_CMDLINE_FROM_BOOTLOADER=y
> +# CONFIG_CMDLINE_OVERRIDE is not set
> +# CONFIG_COMMON_CLK is not set
> +CONFIG_COMPAT_32BIT_TIME=y
> +# CONFIG_CORENET_GENERIC is not set
> +# CONFIG_CPM2 is not set
> +CONFIG_CPU_BIG_ENDIAN=y
> +CONFIG_CRYPTO_AEAD=y
> +CONFIG_CRYPTO_AEAD2=y
> +# CONFIG_CRYPTO_AES_PPC_SPE is not set
> +CONFIG_CRYPTO_AKCIPHER=y
> +CONFIG_CRYPTO_AKCIPHER2=y
> +CONFIG_CRYPTO_AUTHENC=y
> +CONFIG_CRYPTO_HASH=y
> +CONFIG_CRYPTO_HASH2=y
> +CONFIG_CRYPTO_HW=y
> +CONFIG_CRYPTO_LIB_POLY1305_RSIZE=1
> +CONFIG_CRYPTO_MANAGER=y
> +CONFIG_CRYPTO_MANAGER2=y
> +# CONFIG_CRYPTO_MD5_PPC is not set
> +CONFIG_CRYPTO_NULL=y
> +CONFIG_CRYPTO_NULL2=y
> +CONFIG_CRYPTO_RNG=y
> +CONFIG_CRYPTO_RNG2=y
> +CONFIG_CRYPTO_RSA=y
> +# CONFIG_CRYPTO_SHA1_PPC is not set
> +# CONFIG_CRYPTO_SHA1_PPC_SPE is not set #
> CONFIG_CRYPTO_SHA256_PPC_SPE
> +is not set
> +CONFIG_DATA_SHIFT=12
> +CONFIG_DEBUG_BUGVERBOSE=y
> +CONFIG_DNOTIFY=y
> +CONFIG_DTC=y
> +# CONFIG_E200 is not set
> +CONFIG_E500=y
> +# CONFIG_E5500_CPU is not set
> +# CONFIG_E6500_CPU is not set
> +CONFIG_EARLY_PRINTK=y
> +CONFIG_EDAC_ATOMIC_SCRUB=y
> +CONFIG_EDAC_SUPPORT=y
> +CONFIG_ENABLE_MUST_CHECK=y
> +CONFIG_FIXED_PHY=y
> +CONFIG_FSL_BOOKE=y
> +CONFIG_FSL_EMB_PERFMON=y
> +# CONFIG_FSL_ENETC_MDIO is not set
> +# CONFIG_FSL_FMAN is not set
> +CONFIG_FSL_LBC=y
> +CONFIG_FSL_PCI=y
> +CONFIG_FSL_PQ_MDIO=y
> +CONFIG_FSL_SOC=y
> +CONFIG_FSL_S

RE: [PATCH] ramips: mt7621: add TP-Link EAP235-Wall support

[Adrian Schmutzler]

Hi,

> > > +
> > > +   gpio-export {
> > > +   compatible = "gpio-export";
> > > +
> > > +   poe_passthrough {
> > > +   gpio-export,name = "tp-link:poe-
> > > passthrough:enable";
> >
> > I'd consider to drop the prefix, although we have no policy on this,
> > so it's pure matter of taste.
> > Actually, I'd drop this led-label-mimic entirely, and just call it
> > "poe-passthrough".
> 
> Will update.
> This was the same label as I used earlier for the EAP225-Wall. Maybe we
> should change that one too then?

Touching the old ones will require migration, so I would not do that unless we 
really agree on a commen scheme (which is unprobable for a downstream 
solution). This this is totally inconsistent anyway, I'd still go with the 
short version here, but you are totally free to choose what you prefer.

> 
> >
> >
> > state_default is missing?
> 
> It appears to work correctly without an explicit state_default. Is there and
> advantage (e.g. power saving) to setting unused functions to 'gpio'?

I'm talking about the gpios used by leds/keys/gpio-export.

I've also observed defining them was not necessary for leds/keys to work in 
several cases, but it's still the way to go.

> > > +
> > > +&gmac0 {
> > > +   mtd-mac-address = <&info 0x8>; };
> > > +
> > > +&switch0 {
> > > +   ports {
> > > +   port@0 {
> > > +   status = "okay";
> > > +   label = "lan0";
> >
> > Is the zero-based indexing founded on some labels? If not, one-based
> > would be the common way to do it.
> 
> The port on the back of the device is actually labelled 'eth0', so I chose the
> lanX naming to reflect that. That's also why the order of the other port 
> labels
> is reversed compared to their HW index.

Okay.

> > > diff --git a/target/linux/ramips/image/mt7621.mk
> > > b/target/linux/ramips/image/mt7621.mk
> > > index 203ca1b908..6efda9eb90 100644
> > > --- a/target/linux/ramips/image/mt7621.mk
> > > +++ b/target/linux/ramips/image/mt7621.mk
> > > @@ -1114,6 +1114,18 @@ define Device/totolink_x5000r  endef
> > > TARGET_DEVICES += totolink_x5000r
> > >
> > > +define Device/tplink_eap235-wall-v1
> >
> > dsa-migration needs to be added for new devices as well, so all
> > mt7621
> > start with compat version 1.1.
> 
> I realised this already while trying to sysupgrade the device. I originally
> thought as this was named 'migration', it wouldn't be needed since this
> device had always been a DSA device.

Yes, this was actually the least annoying of two options. The other would have 
been to have a big switch case for setting the compat-level in board.d.

Best

Adrian

> 
> 
> Best,
> Sander
> 
> 
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel


openpgp-digital-signature.asc
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

RE: [PATCH] ltq-vdsl-app: fix -Wundef warnings

[Adrian Schmutzler]

> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of Mathias Kresin
> Sent: Mittwoch, 17. Februar 2021 21:20
> To: Adrian Schmutzler ; openwrt-
> de...@lists.openwrt.org
> Subject: Re: [PATCH] ltq-vdsl-app: fix -Wundef warnings
> 
> 2/16/21 10:54 PM, Adrian Schmutzler:
> > Hi,
> >
> >> -Original Message-
> >> From: openwrt-devel [mailto:openwrt-devel-
> boun...@lists.openwrt.org]
> >> On Behalf Of Mathias Kresin
> >> Sent: Dienstag, 16. Februar 2021 19:35
> >> To: openwrt-devel@lists.openwrt.org
> >> Subject: [PATCH] ltq-vdsl-app: fix -Wundef warnings
> >>
> >> The following warnings are shown during build:
> >>
> >> /usr/include/vdsl/cmv_message_format.h:33:6: warning:
> >> "MEI_SUPPORT_DEBUG_STREAMS" is not defined, evaluates to 0 [-
> Wundef]
> >> #if (MEI_SUPPORT_DEBUG_STREAMS == 1)
> >>^
> >> /usr/include/vdsl/drv_mei_cpe_interface.h:2256:6: warning:
> >> "MEI_SUPPORT_OPTIMIZED_FW_DL" is not defined, evaluates to 0 [-
> >> Wundef]  #if (MEI_SUPPORT_OPTIMIZED_FW_DL == 1)
> >>^~~
> >>
> >> The headers are provided by the MEI driver, but the defines are never
> >> set by the vdsl app. While the struct with the
> >> MEI_SUPPORT_OPTIMIZED_FW_DL conditional isn't used by the vdsl app,
> >> however CMV_USED_PAYLOAD_8BIT_SIZE which value depends on
> >> MEI_SUPPORT_DEBUG_STREAMS is.
> >>
> >> Since the MEI driver doesn't provide an autogenerated header with
> >> compile flags, the flags are hardcoded for the vdsl app.
> >>
> >> Set them for the MEI driver as well, to indicate a relation to the
> >> values used for the vdsl app and to be not surprised by a changed
> >> default in case the MEI driver gets updated. Use the current default
> >> values defined in the MEI driver.
> >
> > does this need PKG_RELEASE bump or is it really limited to altering
> compilation parameters?
> 
> The change is limited to compile parameters without an intended change.
> 
> But due to
> 
>  > ... isn't used by the vdsl app, however CMV_USED_PAYLOAD_8BIT_SIZE  >
> which value depends on MEI_SUPPORT_DEBUG_STREAMS is
> 
> a different binary is produced.
> 
> I still tend to not bump the PKG_RELEASE but let me hear what you think
> about it.
> 

Maybe the reproducible people will care.

Personally, I can live with both.

Best

Adrian


> Mathias
> 
> ___
> 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: Patchwork and DMARC emails.

[Brian Norris]

On Thu, Feb 18, 2021 at 2:50 AM Bjørn Mork  wrote:
> Brian Norris  writes:
> > I've necromanced that thread to bug the infradead admin -- maybe he
> > can be convinced to try that patch:
> > http://lists.openwrt.org/pipermail/openwrt-devel/2021-February/033849.html
>
> Would be great to have that fixed. The missing subject is extremely
> annyoing in any email client.  It's not just about patchwork.  I scan
> quickly over mailing lists and my eyes tend to ignore any email with
> subject "(none)", which is what Gnus uses in summary buffers.

Agreed.

To close this out: it seems like David applied said patch in the last
day or two, and the subject line is working again:
http://lists.openwrt.org/pipermail/openwrt-devel/2021-February/033858.html

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

Re: missing email header

[Brian Norris]

On Thu, Feb 18, 2021 at 1:57 AM David Woodhouse  wrote:
> On Wed, 2021-02-17 at 21:52 -0800, Brian Norris wrote:
> > It turns out a bug report was filed, and fixed:
> >
> > https://mail.python.org/archives/list/mailman-us...@python.org/thread/ZVM6I4UTDKHY4EKNLIBIWE4JNC2PYLIS/
> > https://bugs.launchpad.net/mailman/+bug/1915655
> >
> > They've suggested the mailman admin apply a patch ;)
>
> I believe I did so yesterday.

Ah! I suspected that might be the case after I sent my previous email,
as I then searched my mailbox for those DMARC-wrapping headers and
finally found a single message from Etan that finally had a correct
Subject line. And there have been more since. So that part seems to
work now.

Awesome, thanks.

Brian

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

Re: [PATCH] wireguard-tools: Add dependency on kmod-wireguard

[Ilya Lipnitskiy]

Hi Andrey,

On Thu, Feb 18, 2021 at 3:32 AM Andrey Jr. Melnikov
 wrote:
> This is broken when compiled package ip-full
iproute2 does not depend on kmod-wireguard, so I can't see how it can
be related to my change.

Ilya

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

Re: Patchwork and DMARC emails.

[Etan Kissling 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 18.02.21, 05:15, "openwrt-devel on behalf of Sam Kuper" 
 
wrote:

> On Wed, Feb 17, 2021 at 02:47:57PM +0100, Etan Kissling wrote:
> > On 08.02.21, 10:33, Rosen Penev wrote:
> >>> My patches don't end up in Patchwork for some reason.
> >> It's because of DMARC. [..]
> >
> > Thanks for the hint about DMARC leading to Patchwork issues. [..]
> >
> > It seems that the OpenWrt mailing list breaks the signature by adding
> > the 'openwrt-devel mailing list' footer.
>
> IIUC, the OpenWrt mailing list software (Mailman 2.1.29, last time I
> checked) does not "break the signature".
>
> Instead, it wraps the original message and modifies the "From:" header
> before distributing the mail to list subscribers.  That wrapped message
> is then (either by Mailman or by the MTA, I'm not sure) provided with a
> new signature that is valid for the domain in the new "From:" header.

Thanks for looking into this!

You are right, sorry for not being clear enough. The wrapping is the
workaround to avoid breaking the signature. However, it is also possible
to just forward DKIM messages as is (no changes to From, Subject, Body).
In that case, the footer would have to be removed. This only works with
DKIM present, it doesn't when DMARC and SPF are used but no DKIM. Not
sure how popular that problematic combination is, though.

This blog post adds some more background as well:
https://begriffs.com/posts/2018-09-18-dmarc-mailing-list.html

Either variant should work:

- Wrapping of the message (openwrt-devel behaviour)
- Mangling 'From' header (dnsmasq-discuss behaviour)
- Keep From / Subject / Body as-is (netfilter-devel behaviour)

On openwrt-devel the empty subject, loss of thread hierarchy in the web
archive as well as Patchwork problems seem to arise. Hoping that the fix
for empty subjects will make Patchwork problems go away.

On dnsmasq-discuss _sometimes_ the message still ends up in junk,
especially when it goes through moderation queue (e.g., long message).
I don't think they use Patchwork, so not sure how Patchwork likes the
mangled from headers and subject line prefix that they add.

On netfilter-devel, I never had any problems regarding junk filtering
or Patchwork. Linux kernel mailing lists can feel a bit slow sometimes
but it does not seem to be related to email authentication.
 Authentication-results: apple.com; spf=pass
 smtp.mailfrom=netfilter-devel-ow...@vger.kernel.org;   dkim=pass
 header.s=20180706 header.d=apple.com

Cheers

Etan




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

[PATCH v2] ramips: overwrite reset gpio properties in DIR-860L DTS

[Stijn Segers]

As suggested by Sergio, this adds GPIOs 19 and 8 explicitly into the
DIR-860L DTS, so the PCI-E ports get reset and the N radio (radio1)
on PCI-E port 1 comes up reliably.

Fixes the following error that popped up in dmesg:

[1.638942] mt7621-pci 1e14.pcie: pcie1 no card, disable it (RST & 
CLK)

Suggested-by: Sergio Paracuellos 
Signed-off-by: Stijn Segers 
---
 target/linux/ramips/dts/mt7621_dlink_dir-860l-b1.dts | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/target/linux/ramips/dts/mt7621_dlink_dir-860l-b1.dts 
b/target/linux/ramips/dts/mt7621_dlink_dir-860l-b1.dts
index 5d1c336736..f843f62801 100644
--- a/target/linux/ramips/dts/mt7621_dlink_dir-860l-b1.dts
+++ b/target/linux/ramips/dts/mt7621_dlink_dir-860l-b1.dts
@@ -143,6 +143,9 @@
 
 &pcie {
status = "okay";
+
+   reset-gpios = <&gpio 19 GPIO_ACTIVE_LOW>,
+ <&gpio 8 GPIO_ACTIVE_LOW>;
 };
 
 &pcie0 {
-- 
2.30.0


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

Re: [PATCH] wireguard-tools: Add dependency on kmod-wireguard

[Andrey Jr. Melnikov]

Ilya Lipnitskiy  wrote:
> Prepares for wireguard migration to Linux 5.10. The plan is to make luci
> packages depend only on wireguard-tools, then to change the existing
> kmod-wireguard to kmod-wireguard-oot and add the in-tree module for
> 5.10. But for those changes to be made, wireguard-tools needs to depend
> on kmod-wireguard to enable luci repo changes.

> https://github.com/openwrt/openwrt/pull/3876#discussion_r577901541

> Cc: Jason A. Donenfeld 
> Signed-off-by: Ilya Lipnitskiy 
> ---
>  package/network/utils/wireguard-tools/Makefile | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

> diff --git a/package/network/utils/wireguard-tools/Makefile 
> b/package/network/utils/wireguard-tools/Makefile
> index 3cdbaa785c..3194d3d2a7 100644
> --- a/package/network/utils/wireguard-tools/Makefile
> +++ b/package/network/utils/wireguard-tools/Makefile
> @@ -36,7 +36,7 @@ define Package/wireguard-tools
>URL:=https://www.wireguard.com
>MAINTAINER:=Jason A. Donenfeld 
>TITLE:=WireGuard userspace control program (wg)
> -  DEPENDS:=+@BUSYBOX_CONFIG_IP +@BUSYBOX_CONFIG_FEATURE_IP_LINK
> +  DEPENDS:=+@BUSYBOX_CONFIG_IP +@BUSYBOX_CONFIG_FEATURE_IP_LINK 
> +kmod-wireguard
This is broken when compiled package ip-full


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

Re: Patchwork and DMARC emails.

[Bjørn Mork]

Brian Norris  writes:

> I'm pretty sure Patchwork expects some kind of subject, so yes that's
> most likely a problem.
>
>> https://mail.python.org/archives/list/mailman-us...@python.org/thread/ZVM6I4UTDKHY4EKNLIBIWE4JNC2PYLIS/
>
> Oh, nice, thanks for filing the bug report! This came up before but
> wasn't resolved:
> http://lists.openwrt.org/pipermail/openwrt-devel/2020-August/030819.html
>
> I've necromanced that thread to bug the infradead admin -- maybe he
> can be convinced to try that patch:
> http://lists.openwrt.org/pipermail/openwrt-devel/2021-February/033849.html

Would be great to have that fixed. The missing subject is extremely
annyoing in any email client.  It's not just about patchwork.  I scan
quickly over mailing lists and my eyes tend to ignore any email with
subject "(none)", which is what Gnus uses in summary buffers.



Bjørn

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

Re: missing email header

[David Woodhouse]

On Wed, 2021-02-17 at 21:52 -0800, Brian Norris wrote:
> (CC a few)
> 
> On Tue, Aug 11, 2020 at 6:59 AM David Woodhouse  wrote:
> > On Mon, 2020-08-10 at 10:13 -0300, Henrique de Moraes Holschuh wrote:
> > > Agreed.  HOWEVER, anything that is being relayed due to too-strict SPF
> > > is being relayed with an *EMPTY* subject, and *THAT* is extremely 
> > > annoying.
> > 
> > Hm, didn't that get fixed?
> 
> It would seem not. Mailing list participants have been complaining
> very recently:
> 
> http://lists.openwrt.org/pipermail/openwrt-devel/2021-February/033848.html
> 
> It turns out a bug report was filed, and fixed:
> 
> https://mail.python.org/archives/list/mailman-us...@python.org/thread/ZVM6I4UTDKHY4EKNLIBIWE4JNC2PYLIS/
> https://bugs.launchpad.net/mailman/+bug/1915655
> 
> They've suggested the mailman admin apply a patch ;)

I believe I did so yesterday.



smime.p7s
Description: S/MIME cryptographic signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel