Re: kernel 5.10: Wireguard wants some love
Okay, addressed some review comments and opened a dedicated pull request for kernel module fixes for 5.10 (including wireguard): https://github.com/openwrt/openwrt/pull/3885 On Tue, Feb 16, 2021 at 4:22 PM Ansuel Smith wrote: > > The compat module is no longer required and complains > about wireguard included in kernel from version 5.6. > > ___ > 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.
On Wed, Feb 17, 2021 at 8:11 PM 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. [..] ... > > For other mailing lists that do not modify email subject and body, > > Patchwork has no problems with DMARC. Example: > > https://patchwork.ozlabs.org/project/netfilter-devel/patch/a355cb9d-9b07-4d62-a228-a37c2660c...@apple.com/ > > for mailing list: netfilter-de...@vger.kernel.org > > I don't know which headers Patchwork requires in order to be able to > process an email correctly, but if it requires a non-empty "Subject:" > header, then see: 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 Brian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: missing email header
(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 ;) Brian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Patchwork and DMARC emails.
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. This might seem odd, but it is a very common and reasonable workaround for a fundamental flaw in DMARC. See: DMARC introduces the concept of aligned identifiers. Briefly, it means the domain in the RFC5322.From header must match the domain in the "d=" tag in the DKIM signature for DKIM alignment, and/or match the domain in the RFC5321.MailFrom field for SPF alignment. [..] Unfortunately this conflicts with the ways a number of mailing lists and other services have operated for many years. A number of approaches have been proposed: [..] 3. Take ownership of the email message by changing the RFC5322.From address to one in the mailing list's domain, and adding a DKIM signature for that domain. [For example:] B. Replace From: address, set Reply-To: to message author - Change the RFC5322.From address to an address within the mailing list's domain: u...@example.com => addr...@mailinglistdomain.com . - Set or change the RFC5322.ReplyTo address to the message author. - Add DKIM signature using the mailing list's domain. Source: https://dmarc.org/wiki/FAQ#I_operate_a_mailing_list_and_I_want_to_interoperate_with_DMARC.2C_what_should_I_do.3F Also see: https://wiki.list.org/DEV/DMARC > For other mailing lists that do not modify email subject and body, > Patchwork has no problems with DMARC. Example: > https://patchwork.ozlabs.org/project/netfilter-devel/patch/a355cb9d-9b07-4d62-a228-a37c2660c...@apple.com/ > for mailing list: netfilter-de...@vger.kernel.org I don't know which headers Patchwork requires in order to be able to process an email correctly, but if it requires a non-empty "Subject:" header, then see: https://mail.python.org/archives/list/mailman-us...@python.org/thread/ZVM6I4UTDKHY4EKNLIBIWE4JNC2PYLIS/ 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
[PATCH] openssl: always build with GOST engine support
The packages feed has a proposed package for a GOST engine, which needs support from the main openssl library. It is a default option in OpenSSL. All that needs to be done here is to not disable it. Package increases by a net 1-byte, so it is not really really worth keeping this optional. This commit also includes a commented-out example engine configuration in openssl.cnf, as it is done for other available engines. Signed-off-by: Eneas U de Queiroz --- Run tested in WRT3200ACM (mvebu), with and without gost-engine 1.1.0.3. GOST engine PR: https://github.com/openwrt/packages/pull/14765 diff --git a/package/libs/openssl/Config.in b/package/libs/openssl/Config.in index d1281ec6fa..bc2f0584b6 100644 --- a/package/libs/openssl/Config.in +++ b/package/libs/openssl/Config.in @@ -293,15 +293,4 @@ config OPENSSL_WITH_ASYNC initiate crypto operations asynchronously. In order to work this will require the presence of an async capable engine. -config OPENSSL_WITH_GOST - bool - prompt "Prepare library for GOST engine" - depends on OPENSSL_ENGINE - help - This option prepares the library to accept engine support - for Russian GOST crypto algorithms. - The gost engine is not included in standard openwrt feeds. - To build such engine yourself, see: - https://github.com/gost-engine/engine - endif diff --git a/package/libs/openssl/Makefile b/package/libs/openssl/Makefile index 4fb4cb2784..378545ac43 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:=j PKG_VERSION:=$(PKG_BASE)$(PKG_BUGFIX) -PKG_RELEASE:=1 +PKG_RELEASE:=2 PKG_USE_MIPS16:=0 ENGINES_DIR=engines-1.1 @@ -50,7 +50,6 @@ PKG_CONFIG_DEPENDS:= \ CONFIG_OPENSSL_WITH_DTLS \ CONFIG_OPENSSL_WITH_EC2M \ CONFIG_OPENSSL_WITH_ERROR_MESSAGES \ - CONFIG_OPENSSL_WITH_GOST \ CONFIG_OPENSSL_WITH_IDEA \ CONFIG_OPENSSL_WITH_MDC2 \ CONFIG_OPENSSL_WITH_NPN \ @@ -287,10 +286,6 @@ else OPENSSL_OPTIONS += no-engine endif -ifndef CONFIG_OPENSSL_WITH_GOST - OPENSSL_OPTIONS += no-gost -endif - ifndef CONFIG_OPENSSL_WITH_DTLS OPENSSL_OPTIONS += no-dtls endif diff --git a/package/libs/openssl/patches/150-openssl.cnf-add-engines-conf.patch b/package/libs/openssl/patches/150-openssl.cnf-add-engines-conf.patch index 81d41963c6..c90fce2442 100644 --- a/package/libs/openssl/patches/150-openssl.cnf-add-engines-conf.patch +++ b/package/libs/openssl/patches/150-openssl.cnf-add-engines-conf.patch @@ -1,6 +1,6 @@ --- a/apps/openssl.cnf +++ b/apps/openssl.cnf -@@ -22,6 +22,82 @@ oid_section = new_oids +@@ -22,6 +22,99 @@ oid_section = new_oids # (Alternatively, use a configuration file that has only # X.509v3 extensions in its main [= default] section.) @@ -14,6 +14,7 @@ +#devcrypto=devcrypto +#afalg=afalg +#padlock=padlock ++##gost=gost + +[afalg] +# Leave this alone and configure algorithms with CIPERS/DIGESTS below @@ -79,6 +80,22 @@ + +[padlock] +default_algorithms = ALL ++ ++[gost] ++default_algorithms = ALL ++# CRYPT_PARAMS: OID of default GOST 28147-89 parameters It allows the ++# user to choose between different parameter sets of symmetric cipher ++# algorithm. RFC 4357 specifies several parameters for the ++# GOST 28147-89 algorithm, but OpenSSL doesn't provide user interface ++# to choose one when encrypting. So use engine configuration parameter ++# instead. ++# Value of this parameter can be either short name, defined in OpenSSL ++# obj_dat.h header file or numeric representation of OID, defined in ++# RFC 4357. Defaults to id-tc26-gost-28147-param-Z ++#CRYPT_PARAMS = id-tc26-gost-28147-param-Z ++ ++# PBE_PARAMS: Shortname of default digest alg for PBE ++#PBE_PARAMS = + [ new_oids ] ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Upcoming 19.07.7 release
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, 00:03, "openwrt-devel on behalf of Baptiste Jonglez" wrote: > > My patches don't end up in Patchwork for some reason. > > It seems to be caused by DMARC, maybe try with another email address. Thanks for the suggestion. Wouldn't this lead to incorrect author info in Git, though? DMARC and Patchwork work fine with other mailing lists! See https://begriffs.com/posts/2018-09-18-dmarc-mailing-list.html > > If those are acceptable, be sure to take the latest submission for the > > patches that were submitted multiple times. > > They didn't make into 19.07.7. > > This is not my area of expertise, but at first glance it looks too > ambitious for a backport. We typically only backport bug fixes and > sometimes device support; backporting new features would need a very good > reason, especially in core software like hostapd. I haven't looked at > your patches in details though. > > Baptiste Thanks for the explanation on the backport policy. My patches don't fall into either 'bug fixes' or 'device support' category. They have already been accepted into OpenWrt master, so I assume they are everywhere where it is still possible to add them. Etan --- End Message --- ___ 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
Also interesting: https://github.com/openwrt/openwrt/pull/1773#issuecomment-459230119 On 2/17/21 11:02 AM, David Bauer wrote: Hi, On 2/17/21 9:20 AM, Perry wrote: Hello, I thought the kernel size issue was resolved by 1e41de2f48e284c9d6658f9403365651178f6826 Also, the linked PR #1773 has a happy ending. Is the simpleImage no longer a viable solution? Could you explain why not? the issue was resolved for v5.4 with using a different PPC bootwrapper. However, as the kernel grew again with v5.10, this was already back then set to break again in the future, as the bootwrapper only enables a more efficient compression but does not by itself read from the flash. Best wishes David Greetings Perry On February 17, 2021 5:59:28 AM GMT+01:00, David Bauer wrote: Hi Daniel, On 2/17/21 4:21 AM, Daniel Golle wrote: On Tue, Feb 16, 2021 at 11:48:04PM +0100, David Bauer wrote: Tested on: Sophos RED 15W The TP-Link WL-WDR4900 needs to be disabled when 5.10 becomes the default kernel. That's sad. Why? See the next sentence ;) as well as this GitHub issue: https://github.com/openwrt/openwrt/pull/1773 Best David ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Upcoming 19.07.7 release
On 08-02-21, Etan Kissling (IC) wrote: > I have posted a few backports to 19.07 from master a few weeks back, with > these subjects: > > 1. [PATCH 19.07] mbedtls: add config option to compile with hkdf > 2. [PATCH 19.07] hostapd: add multicast_to_unicast and per_sta_vif > 3. [PATCH 19.07] hostapd: enable CTRL_IFACE_MIB for hostapd-full > 4. [PATCH 19.07] nf-conntrack: allow querying conntrack info in nfqueue > 5. [PATCH 19.07] libnetfilter-queue: update to 1.0.5 > > My patches don't end up in Patchwork for some reason. It seems to be caused by DMARC, maybe try with another email address. > If those are acceptable, be sure to take the latest submission for the > patches that were submitted multiple times. They didn't make into 19.07.7. This is not my area of expertise, but at first glance it looks too ambitious for a backport. We typically only backport bug fixes and sometimes device support; backporting new features would need a very good reason, especially in core software like hostapd. I haven't looked at your patches in details though. Baptiste signature.asc Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] ramips: mt7621: add TP-Link EAP235-Wall support
Hi Adrian,
Thanks for the review. I'll fix the naming issues in a v2, some extra
comments below.
On Wed, 2021-02-17 at 01:47 +0100, Adrian Schmutzler wrote:
> > Known issues with this device:
> > The MT7613BE radio is currently not well supported by the mt7615
> > driver:
> > - The EEPROM blob is not recognized, so (Tx) power levels aren't
> > useful.
> > Patch sent to linux-wireless:
> > https://lore.kernel.org/linux-wireless/20210202085953.9564-1-
> > san...@svanheule.net/
> > - DFS support is incomplete (known issue for MT7613)
> > - Radio stops responding after a while when idling, reboot required
> > to
> > bring it to life. Reported by Stijn, appears to be introduced by
> > 2021-01-27 bump of mt76.
>
> Please add the known issues to the preserved part of the commit
> message, I think it's valuable information also for others.
The first issue has been resolved by now, and maybe also the last. I'll
add an updated list to the commit message.
>
> > + leds {
> > + compatible = "gpio-leds";
> > +
> > + led_status: status {
> > + label = "white:status";
> > + color = ;
> > + function = LED_FUNCTION_STATUS;
>
> Note that color/function do not work right now, so label is actually
> required.
> I'm fine with keeping both color/function and label, though.
I was aware that color and function aren't used at the moment. Since
label has been deprecated, I figured I would already include them to
'prepare' the DTS for 5.10.
> > +
> > + 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?
>
>
> 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'?
> > +
> > +&pcie0 {
> > + mt76@0,0 {
>
> wifi@0,0
>
> > + reg = <0x 0 0 0 0>;
> > + mediatek,mtd-eeprom = <&radio 0x0>;
> > + mtd-mac-address = <&info 0x8>;
> > + };
> > +};
> > +
> > +&pcie1 {
> > + mt76@0,0 {
> > + reg = <0x 0 0 0 0>;
> > + mediatek,mtd-eeprom = <&radio 0x8000>;
> > + ieee80211-freq-limit = <500 600>;
> > + mtd-mac-address = <&info 0x8>;
> > + mtd-mac-address-increment = <1>;
> > + };
> > +};
Renamed both mt76@0,0 nodes to wifi@0,0.
> > +
> > +&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.
> > + };
> > +
> > + port@1 {
> > + status = "okay";
> > + label = "lan3";
> > + };
> > +
> > + port@2 {
> > + status = "okay";
> > + label = "lan2";
> > + };
> > +
> > + port@3 {
> > + status = "okay";
> > + label = "lan1";
> > + };
> > + };
> > +};
> > 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.
Best,
Sander
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[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. 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
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. Mathias ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH v2] lantiq: vr9: set the usb led trigger via devicetree
Assign the usbdev trigger via devicetree and drop the userspace
handling of the usb leds.
Drop the now unused userspace helper code as well.
Signed-off-by: Mathias Kresin
---
Changes in v2:
- drop the now unused userspace helper code
.../files/arch/mips/boot/dts/lantiq/vr9.dtsi | 14 ++
.../mips/boot/dts/lantiq/vr9_lantiq_easy80920.dtsi | 12 +++-
.../mips/boot/dts/lantiq/vr9_tplink_tdw89x0.dtsi | 10 ++
.../mips/boot/dts/lantiq/vr9_tplink_vr200.dtsi | 7 +++
.../boot/dts/lantiq/vr9_zyxel_p-2812hnu-f1.dts | 13 ++---
.../lantiq/xrx200/base-files/etc/board.d/01_leds | 6 --
6 files changed, 36 insertions(+), 26 deletions(-)
diff --git a/target/linux/lantiq/files/arch/mips/boot/dts/lantiq/vr9.dtsi
b/target/linux/lantiq/files/arch/mips/boot/dts/lantiq/vr9.dtsi
index 60f7f7a4c0..85c584c1f1 100644
--- a/target/linux/lantiq/files/arch/mips/boot/dts/lantiq/vr9.dtsi
+++ b/target/linux/lantiq/files/arch/mips/boot/dts/lantiq/vr9.dtsi
@@ -409,6 +409,8 @@
};
usb0: usb@e101000 {
+ #address-cells = <1>;
+ #size-cells = <0>;
status = "disabled";
compatible = "lantiq,xrx200-usb";
reg = <0xe101000 0x1000
@@ -418,9 +420,16 @@
dr_mode = "host";
phys = <&usb_phy0>;
phy-names = "usb2-phy";
+
+ ehci_port1: port@1 {
+ reg = <1>;
+ #trigger-source-cells = <0>;
+ };
};
usb1: usb@e106000 {
+ #address-cells = <1>;
+ #size-cells = <0>;
status = "disabled";
compatible = "lantiq,xrx200-usb";
reg = <0xe106000 0x1000>;
@@ -429,6 +438,11 @@
dr_mode = "host";
phys = <&usb_phy1>;
phy-names = "usb2-phy";
+
+ ehci_port2: port@1 {
+ reg = <1>;
+ #trigger-source-cells = <0>;
+ };
};
eth0: eth@e108000 {
diff --git
a/target/linux/lantiq/files/arch/mips/boot/dts/lantiq/vr9_lantiq_easy80920.dtsi
b/target/linux/lantiq/files/arch/mips/boot/dts/lantiq/vr9_lantiq_easy80920.dtsi
index f5b0b4f2a1..9cac3e6ec0 100644
---
a/target/linux/lantiq/files/arch/mips/boot/dts/lantiq/vr9_lantiq_easy80920.dtsi
+++
b/target/linux/lantiq/files/arch/mips/boot/dts/lantiq/vr9_lantiq_easy80920.dtsi
@@ -15,9 +15,6 @@
led-failsafe = &power;
led-running = &power;
led-upgrade = &power;
-
- led-usb = &led_usb1;
- led-usb2 = &led_usb2;
};
memory@0 {
@@ -64,13 +61,18 @@
label = "green:fxo";
gpios = <&stp 19 GPIO_ACTIVE_HIGH>;
};
- led_usb1: usb1 {
+ usb1 {
label = "green:usb1";
gpios = <&stp 18 GPIO_ACTIVE_HIGH>;
+ trigger-sources = <&ehci_port1>;
+ linux,default-trigger = "usbport";
};
- led_usb2: usb2 {
+
+ usb2 {
label = "green:usb2";
gpios = <&stp 15 GPIO_ACTIVE_HIGH>;
+ trigger-sources = <&ehci_port2>;
+ linux,default-trigger = "usbport";
};
sd {
label = "green:sd";
diff --git
a/target/linux/lantiq/files/arch/mips/boot/dts/lantiq/vr9_tplink_tdw89x0.dtsi
b/target/linux/lantiq/files/arch/mips/boot/dts/lantiq/vr9_tplink_tdw89x0.dtsi
index aa6c308ffe..d33b817f2d 100644
---
a/target/linux/lantiq/files/arch/mips/boot/dts/lantiq/vr9_tplink_tdw89x0.dtsi
+++
b/target/linux/lantiq/files/arch/mips/boot/dts/lantiq/vr9_tplink_tdw89x0.dtsi
@@ -18,8 +18,6 @@
led-dsl = &led_dsl;
led-internet = &led_internet;
led-wifi = &led_wifi;
- led-usb = &led_usb0;
- led-usb2 = &led_usb2;
};
memory@0 {
@@ -67,14 +65,18 @@
gpios = <&gpio 5 GPIO_ACTIVE_HIGH>;
};
- led_usb0: usb0 {
+ usb0 {
label = "green:usb";
gpios = <&gpio 19 GPIO_ACTIVE_HIGH>;
+ trigger-sources = <&ehci_port1>;
+ linux,default-trigger = "usbport";
};
- led_usb2: usb2 {
+ usb2 {
label = "green:usb2";
gpios = <&gpio 20 GPIO_ACTIVE_HIGH>;
+ trigger-sources = <&
Re: [PATCH] lantiq: vr9: set the usb led trigger via devicetree
2/16/21 10:51 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] lantiq: vr9: set the usb led trigger via devicetree Assign the usbdev trigger via devicetree and drop the userspace handling of the usb leds. Nice. This should allow to drop the relevant lines from xrx200/base-files/etc/board.d/01_leds as well. Best Adrian Good point. Will send a v2. Mathias ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH v2] mvebu/omnia: enable hardware buffer management
Backport (and fix [1]) the required device tree changes in order to support
hardware buffer management on the Turris Omnia.
[1] https://lore.kernel.org/linux-arm-kernel/20210217164232.25a77...@kernel.org/
Signed-off-by: Rui Salvaterra
---
...is-omnia-enable-HW-buffer-management.patch | 83 +++
1 file changed, 83 insertions(+)
create mode 100644
target/linux/mvebu/patches-5.4/317-ARM-dts-turris-omnia-enable-HW-buffer-management.patch
diff --git
a/target/linux/mvebu/patches-5.4/317-ARM-dts-turris-omnia-enable-HW-buffer-management.patch
b/target/linux/mvebu/patches-5.4/317-ARM-dts-turris-omnia-enable-HW-buffer-management.patch
new file mode 100644
index 00..3420edf075
--- /dev/null
+++
b/target/linux/mvebu/patches-5.4/317-ARM-dts-turris-omnia-enable-HW-buffer-management.patch
@@ -0,0 +1,83 @@
+From 23f0ff99446cf27cdc73f794a9d767e6af05e11c Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Marek=20Beh=C3=BAn?=
+Date: Sun, 15 Nov 2020 14:59:17 +0100
+Subject: [PATCH 1/2] ARM: dts: turris-omnia: enable HW buffer management
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+The buffer manager is available on Turris Omnia but needs to be
+described in device-tree to be used.
+
+Signed-off-by: Marek Behún
+Fixes: 26ca8b52d6e1 ("ARM: dts: add support for Turris Omnia")
+Cc: linux-arm-ker...@lists.infradead.org
+Cc: Uwe Kleine-König
+Cc: Jason Cooper
+Cc: Gregory CLEMENT
+Cc: Andreas Färber
+Cc: Andrew Lunn
+Cc: Rob Herring
+Cc: devicet...@vger.kernel.org
+Signed-off-by: Gregory CLEMENT
+Signed-off-by: Rui Salvaterra
+---
+ arch/arm/boot/dts/armada-385-turris-omnia.dts | 17 +
+ 1 file changed, 17 insertions(+)
+
+--- a/arch/arm/boot/dts/armada-385-turris-omnia.dts
b/arch/arm/boot/dts/armada-385-turris-omnia.dts
+@@ -31,7 +31,8 @@
+ ranges = ;
++MBUS_ID(0x09, 0x15) 0 0xf111 0x1
++MBUS_ID(0x0c, 0x04) 0 0xf120 0x10>;
+
+ internal-regs {
+
+@@ -84,12 +85,23 @@
+ };
+ };
+
++&bm {
++ status = "okay";
++};
++
++&bm_bppi {
++ status = "okay";
++};
++
+ /* Connected to 88E6176 switch, port 6 */
+ ð0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&ge0_rgmii_pins>;
+ status = "okay";
+ phy-mode = "rgmii";
++ buffer-manager = <&bm>;
++ bm,pool-long = <0>;
++ bm,pool-short = <3>;
+
+ fixed-link {
+ speed = <1000>;
+@@ -103,6 +115,9 @@
+ pinctrl-0 = <&ge1_rgmii_pins>;
+ status = "okay";
+ phy-mode = "rgmii";
++ buffer-manager = <&bm>;
++ bm,pool-long = <1>;
++ bm,pool-short = <3>;
+
+ fixed-link {
+ speed = <1000>;
+@@ -115,6 +130,9 @@
+ status = "okay";
+ phy-mode = "sgmii";
+ phy = <&phy1>;
++ buffer-manager = <&bm>;
++ bm,pool-long = <2>;
++ bm,pool-short = <3>;
+ };
+
+ &i2c0 {
--
2.30.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] mvebu/omnia: enable hardware buffer management
Oops! Fat-fingered. I'll resend with a proper description.
On Wed, 17 Feb 2021 at 15:52, Rui Salvaterra wrote:
>
> Signed-off-by: Rui Salvaterra
> ---
> ...is-omnia-enable-HW-buffer-management.patch | 83 +++
> 1 file changed, 83 insertions(+)
> create mode 100644
> target/linux/mvebu/patches-5.4/317-ARM-dts-turris-omnia-enable-HW-buffer-management.patch
>
> diff --git
> a/target/linux/mvebu/patches-5.4/317-ARM-dts-turris-omnia-enable-HW-buffer-management.patch
>
> b/target/linux/mvebu/patches-5.4/317-ARM-dts-turris-omnia-enable-HW-buffer-management.patch
> new file mode 100644
> index 00..3420edf075
> --- /dev/null
> +++
> b/target/linux/mvebu/patches-5.4/317-ARM-dts-turris-omnia-enable-HW-buffer-management.patch
> @@ -0,0 +1,83 @@
> +From 23f0ff99446cf27cdc73f794a9d767e6af05e11c Mon Sep 17 00:00:00 2001
> +From: =?UTF-8?q?Marek=20Beh=C3=BAn?=
> +Date: Sun, 15 Nov 2020 14:59:17 +0100
> +Subject: [PATCH 1/2] ARM: dts: turris-omnia: enable HW buffer management
> +MIME-Version: 1.0
> +Content-Type: text/plain; charset=UTF-8
> +Content-Transfer-Encoding: 8bit
> +
> +The buffer manager is available on Turris Omnia but needs to be
> +described in device-tree to be used.
> +
> +Signed-off-by: Marek Behún
> +Fixes: 26ca8b52d6e1 ("ARM: dts: add support for Turris Omnia")
> +Cc: linux-arm-ker...@lists.infradead.org
> +Cc: Uwe Kleine-König
> +Cc: Jason Cooper
> +Cc: Gregory CLEMENT
> +Cc: Andreas Färber
> +Cc: Andrew Lunn
> +Cc: Rob Herring
> +Cc: devicet...@vger.kernel.org
> +Signed-off-by: Gregory CLEMENT
> +Signed-off-by: Rui Salvaterra
> +---
> + arch/arm/boot/dts/armada-385-turris-omnia.dts | 17 +
> + 1 file changed, 17 insertions(+)
> +
> +--- a/arch/arm/boot/dts/armada-385-turris-omnia.dts
> b/arch/arm/boot/dts/armada-385-turris-omnia.dts
> +@@ -31,7 +31,8 @@
> + ranges = + MBUS_ID(0x01, 0x1d) 0 0xfff0 0x10
> + MBUS_ID(0x09, 0x19) 0 0xf110 0x1
> +-MBUS_ID(0x09, 0x15) 0 0xf111 0x1>;
> ++MBUS_ID(0x09, 0x15) 0 0xf111 0x1
> ++MBUS_ID(0x0c, 0x04) 0 0xf120 0x10>;
> +
> + internal-regs {
> +
> +@@ -84,12 +85,23 @@
> + };
> + };
> +
> ++&bm {
> ++ status = "okay";
> ++};
> ++
> ++&bm_bppi {
> ++ status = "okay";
> ++};
> ++
> + /* Connected to 88E6176 switch, port 6 */
> + ð0 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&ge0_rgmii_pins>;
> + status = "okay";
> + phy-mode = "rgmii";
> ++ buffer-manager = <&bm>;
> ++ bm,pool-long = <0>;
> ++ bm,pool-short = <3>;
> +
> + fixed-link {
> + speed = <1000>;
> +@@ -103,6 +115,9 @@
> + pinctrl-0 = <&ge1_rgmii_pins>;
> + status = "okay";
> + phy-mode = "rgmii";
> ++ buffer-manager = <&bm>;
> ++ bm,pool-long = <1>;
> ++ bm,pool-short = <3>;
> +
> + fixed-link {
> + speed = <1000>;
> +@@ -115,6 +130,9 @@
> + status = "okay";
> + phy-mode = "sgmii";
> + phy = <&phy1>;
> ++ buffer-manager = <&bm>;
> ++ bm,pool-long = <2>;
> ++ bm,pool-short = <3>;
> + };
> +
> + &i2c0 {
> --
> 2.30.1
>
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH] mvebu/omnia: enable hardware buffer management
Signed-off-by: Rui Salvaterra
---
...is-omnia-enable-HW-buffer-management.patch | 83 +++
1 file changed, 83 insertions(+)
create mode 100644
target/linux/mvebu/patches-5.4/317-ARM-dts-turris-omnia-enable-HW-buffer-management.patch
diff --git
a/target/linux/mvebu/patches-5.4/317-ARM-dts-turris-omnia-enable-HW-buffer-management.patch
b/target/linux/mvebu/patches-5.4/317-ARM-dts-turris-omnia-enable-HW-buffer-management.patch
new file mode 100644
index 00..3420edf075
--- /dev/null
+++
b/target/linux/mvebu/patches-5.4/317-ARM-dts-turris-omnia-enable-HW-buffer-management.patch
@@ -0,0 +1,83 @@
+From 23f0ff99446cf27cdc73f794a9d767e6af05e11c Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Marek=20Beh=C3=BAn?=
+Date: Sun, 15 Nov 2020 14:59:17 +0100
+Subject: [PATCH 1/2] ARM: dts: turris-omnia: enable HW buffer management
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+The buffer manager is available on Turris Omnia but needs to be
+described in device-tree to be used.
+
+Signed-off-by: Marek Behún
+Fixes: 26ca8b52d6e1 ("ARM: dts: add support for Turris Omnia")
+Cc: linux-arm-ker...@lists.infradead.org
+Cc: Uwe Kleine-König
+Cc: Jason Cooper
+Cc: Gregory CLEMENT
+Cc: Andreas Färber
+Cc: Andrew Lunn
+Cc: Rob Herring
+Cc: devicet...@vger.kernel.org
+Signed-off-by: Gregory CLEMENT
+Signed-off-by: Rui Salvaterra
+---
+ arch/arm/boot/dts/armada-385-turris-omnia.dts | 17 +
+ 1 file changed, 17 insertions(+)
+
+--- a/arch/arm/boot/dts/armada-385-turris-omnia.dts
b/arch/arm/boot/dts/armada-385-turris-omnia.dts
+@@ -31,7 +31,8 @@
+ ranges = ;
++MBUS_ID(0x09, 0x15) 0 0xf111 0x1
++MBUS_ID(0x0c, 0x04) 0 0xf120 0x10>;
+
+ internal-regs {
+
+@@ -84,12 +85,23 @@
+ };
+ };
+
++&bm {
++ status = "okay";
++};
++
++&bm_bppi {
++ status = "okay";
++};
++
+ /* Connected to 88E6176 switch, port 6 */
+ ð0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&ge0_rgmii_pins>;
+ status = "okay";
+ phy-mode = "rgmii";
++ buffer-manager = <&bm>;
++ bm,pool-long = <0>;
++ bm,pool-short = <3>;
+
+ fixed-link {
+ speed = <1000>;
+@@ -103,6 +115,9 @@
+ pinctrl-0 = <&ge1_rgmii_pins>;
+ status = "okay";
+ phy-mode = "rgmii";
++ buffer-manager = <&bm>;
++ bm,pool-long = <1>;
++ bm,pool-short = <3>;
+
+ fixed-link {
+ speed = <1000>;
+@@ -115,6 +130,9 @@
+ status = "okay";
+ phy-mode = "sgmii";
+ phy = <&phy1>;
++ buffer-manager = <&bm>;
++ bm,pool-long = <2>;
++ bm,pool-short = <3>;
+ };
+
+ &i2c0 {
--
2.30.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[no subject]
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 08.02.21, 10:33, "openwrt-devel on behalf of Rosen Penev" wrote: > > My patches don't end up in Patchwork for some reason. > It's because of DMARC. See: > > The sender domain has a DMARC Reject/Quarantine policy which disallows > sending mailing list messages using the original "From" header. Thanks for the hint about DMARC leading to Patchwork issues. DMARC is a security standard for accessing email authenticity. It seems that the OpenWrt mailing list breaks the signature by adding the 'openwrt-devel mailing list' footer. For other mailing lists that do not modify email subject and body, Patchwork has no problems with DMARC. Example: https://patchwork.ozlabs.org/project/netfilter-devel/patch/a355cb9d-9b07-4d62-a228-a37c2660c...@apple.com/ for mailing list: netfilter-de...@vger.kernel.org DMARC settings are beyond my control (and possibly similar for others). --- End Message --- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH] autotools.mk: fix gettext fixup
The update to gettext 0.21 broke packages that use autotools and
gettext because the sed line was failing with the new version. Fix with
a better sed expression.
Signed-off-by: Rosen Penev
---
include/autotools.mk | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/autotools.mk b/include/autotools.mk
index 4b48b38992..eb52b55924 100644
--- a/include/autotools.mk
+++ b/include/autotools.mk
@@ -90,7 +90,7 @@ endef
define gettext_version_target
(cd $(PKG_BUILD_DIR) && \
- GETTEXT_VERSION=$(shell $(STAGING_DIR_HOSTPKG)/bin/gettext -V |
$(STAGING_DIR_HOST)/bin/sed -ne '1s/.*\([0-9]\.[0-9]\{2\}\.[0-9]\).*/\1/p' ) &&
\
+ GETTEXT_VERSION=$(shell $(STAGING_DIR_HOSTPKG)/bin/gettext -V |
$(STAGING_DIR_HOST)/bin/sed -rne '1s/.*\b([0-9]\.[0-9]+(\.[0-9]+)?)\b.*/\1/p' )
&& \
$(STAGING_DIR_HOST)/bin/sed \
-i $(PKG_BUILD_DIR)/configure.ac \
-e
"s/AM_GNU_GETTEXT_VERSION(.*)/AM_GNU_GETTEXT_VERSION(\[GETTEXT_VERSION\])/g"
&& \
--
2.25.1
___
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
Hi, On 2/17/21 9:20 AM, Perry wrote: > Hello, > > I thought the kernel size issue was resolved by > 1e41de2f48e284c9d6658f9403365651178f6826 > > Also, the linked PR #1773 has a happy ending. > > Is the simpleImage no longer a viable solution? Could you explain why not? the issue was resolved for v5.4 with using a different PPC bootwrapper. However, as the kernel grew again with v5.10, this was already back then set to break again in the future, as the bootwrapper only enables a more efficient compression but does not by itself read from the flash. Best wishes David > > Greetings > Perry > > On February 17, 2021 5:59:28 AM GMT+01:00, David Bauer > wrote: >> Hi Daniel, >> >> On 2/17/21 4:21 AM, Daniel Golle wrote: >>> On Tue, Feb 16, 2021 at 11:48:04PM +0100, David Bauer wrote: Tested on: Sophos RED 15W The TP-Link WL-WDR4900 needs to be disabled when 5.10 becomes the default kernel. >>> >>> That's sad. Why? >> >> See the next sentence ;) as well as this GitHub issue: >> https://github.com/openwrt/openwrt/pull/1773 >> >> Best >> David >>> >>> ___ >>> openwrt-devel mailing list >>> openwrt-devel@lists.openwrt.org >>> https://lists.openwrt.org/mailman/listinfo/openwrt-devel >>> >> >> ___ >> openwrt-devel mailing list >> openwrt-devel@lists.openwrt.org >> https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] mpc85xx-p1010: add Kernel 5.10 support
Hello, I thought the kernel size issue was resolved by 1e41de2f48e284c9d6658f9403365651178f6826 Also, the linked PR #1773 has a happy ending. Is the simpleImage no longer a viable solution? Could you explain why not? Greetings Perry On February 17, 2021 5:59:28 AM GMT+01:00, David Bauer wrote: >Hi Daniel, > >On 2/17/21 4:21 AM, Daniel Golle wrote: >> On Tue, Feb 16, 2021 at 11:48:04PM +0100, David Bauer wrote: >>> Tested on: Sophos RED 15W >>> >>> The TP-Link WL-WDR4900 needs to be disabled when 5.10 becomes the >>> default kernel. >> >> That's sad. Why? > >See the next sentence ;) as well as this GitHub issue: >https://github.com/openwrt/openwrt/pull/1773 > >Best >David >> >> ___ >> openwrt-devel mailing list >> openwrt-devel@lists.openwrt.org >> https://lists.openwrt.org/mailman/listinfo/openwrt-devel >> > >___ >openwrt-devel mailing list >openwrt-devel@lists.openwrt.org >https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
