Re: [OpenWrt-Devel] [PATCH 1/3] zynq: copy config from kernel 4.19 to 5.4

[Luis Araneda]

Hi,

On Fri, Mar 13, 2020 at 9:34 AM Petr Štetiar  wrote:
>
> Adrian Schmutzler  [2020-03-13 13:17:42]:
>
> > I'm aware of the two-step procedure (1. copy without changes, 2. refresh), I
> > just read the message in a way that the config was refreshed _before_ 
> > copying
> > it?
>
> Yep, Luis did exactly what he described in his commit description, he really
> refreshed the 4.19 config first (IIRC two symbols refreshed?) and copied it to
> 5.4.
>
> That's probably the pedantic way, fixing first 4.19 config, then refresh it
> for 5.4, so the diff for 5.4 contains only symbols related to 5.4, not to 4.19
> cleanup/refresh.

That's exactly what I did.
My apologies if it caused any inconvenience, but I thought that an
additional commit for just two symbols (one removed, one added) was
not necessary.

Please let me know if you want a refresh commit in the future (next
kernel version?) even if it just a couple of symbols.

Regards,
Luis Araneda.

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

Re: [OpenWrt-Devel] [PATCH uhttpd] client: allow keep-alive for POST requests

[Jo-Philipp Wich]

Hi Wes,

> That sounds ideal. Is this with or without the "[OpenWrt-Devel] [PATCH
> ustream-ssl] ustream-openssl: clear error stack before SSL_read/SSL_write" 
> patch?

it is including the error stack patch. Without it, I wasn't even able to fully
load the page most of the time.

Regards,
Jo



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

Re: [OpenWrt-Devel] [PATCH] pkgconf: always retain -I and -L flags

[Rosen Penev]

On Fri, Mar 13, 2020 at 7:55 AM Jo-Philipp Wich  wrote:
>
> The pkgconf fork filters -I and -L flag values from .pc files which match
> pkgconf's builtin system directory value.
>
> During configure, pkgconf derives the default system include and library
> search path values from exec_prefix, which is set to staging_dir/host in
> the host tool build phase.
>
> Due to that, pkgconf will drop all -I and -L flags pointing to
> staging_dir/host/include or staging_dir/host/lib, unless invoked with
> --keep-system-cflags and --keep-system-libs respectively, breaking our
> kernel libelf discovery / stack validation workarounds.
>
> In order to inhibit the filtering, add --keep-system-cflags and
> --keep-system-libs to our pkg-config shell wrapper.
>
> Fixes: GH#2832
> Fixes: 867298cf47 ("tools/pkg-config: Replace with pkgconf")
> Ref: 
> https://lists.infradead.org/pipermail/openwrt-devel/2020-March/022182.html
> Ref: https://git.openwrt.org/fe43969336201f2cc7d103b68fd6e65989bee184
> Signed-off-by: Jo-Philipp Wich 
> ---
>  tools/pkgconf/files/pkg-config | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/tools/pkgconf/files/pkg-config b/tools/pkgconf/files/pkg-config
> index fa1faccc6c..2c6fd08b4a 100755
> --- a/tools/pkgconf/files/pkg-config
> +++ b/tools/pkgconf/files/pkg-config
> @@ -1,6 +1,8 @@
>  #!/bin/sh
>
>  pkg-config.real \
> +--keep-system-cflags \
> +--keep-system-libs \
Any way to make these only used for host builds? I imagine these
options could impact target builds.
>  --define-variable=prefix="${STAGING_PREFIX}" \
>  --define-variable=exec_prefix="${STAGING_PREFIX}" \
>  --define-variable=bindir="${STAGING_PREFIX}/bin" "$@"
> --
> 2.25.1
>
>
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel

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

Re: [OpenWrt-Devel] pkgconf issue with kmods and libelf [Was: Re: tools/pkg-config: Replace with pkgconf]

[Rosen Penev]

On Fri, Mar 13, 2020 at 7:33 AM Petr Štetiar  wrote:
>
> Rosen Penev  [2020-02-28 20:12:45]:
>
> Hi,
>
> > It's more portable and smaller. And as stated, it is still fairly active.
>
> Jo has today brought following issue to my attention:
>
> ## pkgconf
>  $ PATH=$(pwd)/staging_dir/host/bin:$PATH 
> STAGING_PREFIX=$(pwd)/staging_dir/host 
> PKG_CONFIG_PATH=$(pwd)/staging_dir/host/lib/pkgconfig 
> PKG_CONFIG_LIBDIR=$(pwd)/staging_dir/host/lib/pkgconfig pkg-config libelf 
> --libs
>  -lelf
>
> ## pkg-config
>
>  $ PATH=$(pwd)/staging_dir/host/bin:$PATH 
> STAGING_PREFIX=$(pwd)/staging_dir/host 
> PKG_CONFIG_PATH=$(pwd)/staging_dir/host/lib/pkgconfig 
> PKG_CONFIG_LIBDIR=$(pwd)/staging_dir/host/lib/pkgconfig pkg-config libelf 
> --libs
>  -L/home/jow/devel/lede/staging.git/staging_dir/host/lib -lelf
>
> So it looks like pkgconf is filtering out some library paths, causing for
> example following issues:
>
>  make[5]: *** No rule to make target 'tools/objtool/objtool', needed by 
> '/home/jow/devel/lede/staging.git/build_dir/target-x86_64_musl/linux-x86_64/siit-1.2/siit.o'.
>   Stop.
>
> < jow> the main kernel build will skip building objtool (and forcibly disable 
> CONFIG_STACK_VALIDATION) because it cannot link libelf
> < jow> any external kmod will assume CONFIG_STACK_VALIDATION is enabled and 
> kbuild will try to invoke objtool which doesn't exist in the precompiled 
> kernel soure tree
>
> Possibly caused by:
>
>  ## linker flags optimization
>
>  As previously mentioned, pkgconf makes optimizations to the linker flags in
>  both the case of static and shared linking in order to avoid overlinking
>  binaries and also simplifies the `CFLAGS` and `LIBS` output of the pkgconf
>  tool for improved readability.
>
> Ref: https://github.com/openwrt/openwrt/pull/2832
Never seen this. Then again, I've only dealt with target packages.
>
> -- ynezz

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

Re: [OpenWrt-Devel] [PATCH 2/5] toolchain/gcc: make GCC9 by default for archs38

[Evgeniy Didin]

Also forgot to mention, that at GCC 8.4.0 it fails as well. I can try to find 
missing patches between 8.4.0 and 9.2.0 and add them.
What should I better do?

-Evgeniy

From: openwrt-devel  On Behalf Of 
Evgeniy Didin
Sent: Friday, March 13, 2020 5:26 PM
To: Hauke Mehrtens ; openwrt-devel@lists.openwrt.org
Cc: Petr Štetiar ; Alexey Brodkin ; John 
Crispin 
Subject: Re: [OpenWrt-Devel] [PATCH 2/5] toolchain/gcc: make GCC9 by default 
for archs38

Hi Hauke,

This problem reproduces only for ARC(ARM is ok) and Linux v5.4 (v4.19 is ok).


Best regards,
Evgeniy Didin


From: Hauke Mehrtens mailto:ha...@hauke-m.de>>
Sent: Thursday, March 12, 2020 6:33 PM
To: Evgeniy Didin mailto:di...@synopsys.com>>; 
openwrt-devel@lists.openwrt.org 
mailto:openwrt-devel@lists.openwrt.org>>
Cc: Alexey Brodkin mailto:abrod...@synopsys.com>>; Petr 
Štetiar mailto:yn...@true.cz>>; John Crispin 
mailto:j...@phrozen.org>>
Subject: Re: [PATCH 2/5] toolchain/gcc: make GCC9 by default for archs38

On 3/12/20 2:34 PM, Evgeniy Didin wrote:
> It is necessary to use GCC9 for building Linux 5.4.x version for
> archs38, in GCC8 the critical fixes are missing and ICE appears
> during building.

Is this problem specific to OpenWrt or is there a general problem with
arc Linux and gcc 8.3?

Should it work with gcc 8.4?

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

Re: [OpenWrt-Devel] [PATCH] ath79: use downstream ag71xx for Kernel 5.4

[David Bauer]

Hello,

On 3/13/20 1:29 PM, Petr Štetiar wrote:
> Bjørn Mork  [2020-03-13 09:29:49]:
> 
>> David Bauer  writes:
>>
>>> --- 
>>> a/target/linux/ath79/files-4.19/drivers/net/ethernet/atheros/ag71xx/ag71xx_main.c
>>> +++ 
>>> b/target/linux/ath79/files/drivers/net/ethernet/atheros/ag71xx/ag71xx_main.c
>>> @@ -1581,7 +1581,7 @@ static int ag71xx_probe(struct platform_device *pdev)
>>> ag->stop_desc->next = (u32) ag->stop_desc_dma;
>>>  
>>> mac_addr = of_get_mac_address(np);
>>> -   if (mac_addr)
>>> +   if (mac_addr && !IS_ERR(mac_addr))
>>
>> bikeshedding...
> 
> Not bikeshedding at all, good catch. It's an issue which should be fixed.
> 
> It should be just `if (!IS_ERR(mac_addr))` because it's either valid pointer
> or ERR_PTR since 5.2 via commit d01f449c008a ("of_net: add NVMEM support to
> of_get_mac_address"). I would simply copy the fragment from upstream
> ag71xx.c.

And we would need to wrap this statement in precompile conditions depending on 
the
kernel version. I like this idea compared to the current "solution".

> 681-NET-add-of_get_mac_address_mtd.patch needs to be updated for 5.4, that
> of_get_mac_address_mtd() shouldn't return NULL, but ERR_PTR instead.

I'm not quite sure about that. of_get_mac_address is the only caller and all 
other
sub-methods before of_get_mac_addr_nvmem there return NULL in case no valid MAC
address can be determined. As long as we are evaluating of_get_mac_address_mtd 
result
prior to the result of of_get_mac_addr_nvmem we should be okay.

Best wishes
David

> 
> -- ynezz
> 

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

Re: [OpenWrt-Devel] [PATCH uhttpd] client: allow keep-alive for POST requests

[Wes Turner]

On Fri, Mar 13, 2020, 12:39 PM Jo-Philipp Wich  wrote:

> Hi Wes,
>
> > Are there *new* security implications of allowing keep-alive?
>
> I don't see any immediate concerns. You can trigger resource intensive
> calls
> via GET, HEAD, PATCH, PUT or DELETE as well, all of them were allowed for
> keep-alive previously, only POST was filtered for unknown reasons.
>
> > Slowloris DoS comes to mind:
> > https://en.wikipedia.org/wiki/Slowloris_(computer_security)
>
> The DoS susceptibility should be same with or without this patch.
>
> > Older devices are likely somewhat trivially DoS-able without this patch;
> but
> > maybe include a config option to disable keep-alive?
>


> Disabling keep-alive has always been supported, either use
> uci set uhttpd.main.http_keepalive=0 or alternatively uhttpd -k 0
>

Thanks


> > What happens to RAM and CPU usage when there are multiple tabs open with
> > keep-alive on?
>
> Testing with 6 open browser tabs, all refreshing the main status page:
>
> With POST keep-alive:uhttpd VSZ 4316K, CPU 5% usr, 6% sys
> Without POST keep-alive: uhttpd VSZ 4756K, CPU 11% usr, 8% sys
>
> Thats not a scientific benchmark though. In general you trade CPU (TLS
> setup,
> TCP connects) for memory (resident established connections).
>
> In case of non-malicious clients (like normal browser tabs background
> refreshing data) the memory resource consumption seems to be even lower
> because there's less active TLS sessions at every point in time. And
> almost no
> TLS connection attempts once all requires sessions are established.
>

That sounds ideal. Is this with or without the "[OpenWrt-Devel] [PATCH
ustream-ssl] ustream-openssl: clear error stack before SSL_read/SSL_write"
patch?
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH uhttpd] client: allow keep-alive for POST requests

[Jo-Philipp Wich]

Hi Wes,

> Are there *new* security implications of allowing keep-alive?

I don't see any immediate concerns. You can trigger resource intensive calls
via GET, HEAD, PATCH, PUT or DELETE as well, all of them were allowed for
keep-alive previously, only POST was filtered for unknown reasons.

> Slowloris DoS comes to mind:
> https://en.wikipedia.org/wiki/Slowloris_(computer_security)

The DoS susceptibility should be same with or without this patch.

> Older devices are likely somewhat trivially DoS-able without this patch; but
> maybe include a config option to disable keep-alive?

Disabling keep-alive has always been supported, either use
uci set uhttpd.main.http_keepalive=0 or alternatively uhttpd -k 0

> What happens to RAM and CPU usage when there are multiple tabs open with
> keep-alive on?

Testing with 6 open browser tabs, all refreshing the main status page:

With POST keep-alive:uhttpd VSZ 4316K, CPU 5% usr, 6% sys
Without POST keep-alive: uhttpd VSZ 4756K, CPU 11% usr, 8% sys

Thats not a scientific benchmark though. In general you trade CPU (TLS setup,
TCP connects) for memory (resident established connections).

In case of non-malicious clients (like normal browser tabs background
refreshing data) the memory resource consumption seems to be even lower
because there's less active TLS sessions at every point in time. And almost no
TLS connection attempts once all requires sessions are established.


Regards,
Jo



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

[OpenWrt-Devel] [PATCH 1/3] base-files: do not source system.sh in functions.sh

[Adrian Schmutzler]

The default_postinst() function in /lib/functions.sh sources
/lib/functions/system.sh before cycling through uci-defaults files.

This creates a pseudo-cyclic dependency as system.sh also uses
functions that are located in functions.sh. Despite that, there
is actually only one uci-defaults file in the entire repo that needs
system.sh, and this one contains an explicit source for system.sh
anyway.

Consequently, this patch removes the sourcing of system.sh in
functions.sh. There are no relevant uses in packages, routing and
luci repositories.
This may require adjustments for downstream, though.

Signed-off-by: Adrian Schmutzler 
---
 package/base-files/Makefile   | 2 +-
 package/base-files/files/lib/functions.sh | 1 -
 2 files changed, 1 insertion(+), 2 deletions(-)

diff --git a/package/base-files/Makefile b/package/base-files/Makefile
index 107d53e74f..8e252153fe 100644
--- a/package/base-files/Makefile
+++ b/package/base-files/Makefile
@@ -12,7 +12,7 @@ include $(INCLUDE_DIR)/version.mk
 include $(INCLUDE_DIR)/feeds.mk
 
 PKG_NAME:=base-files
-PKG_RELEASE:=214
+PKG_RELEASE:=215
 PKG_FLAGS:=nonshared
 
 PKG_FILE_DEPENDS:=$(PLATFORM_DIR)/ $(GENERIC_PLATFORM_DIR)/base-files/
diff --git a/package/base-files/files/lib/functions.sh 
b/package/base-files/files/lib/functions.sh
index fe908f7aa4..a77b669709 100755
--- a/package/base-files/files/lib/functions.sh
+++ b/package/base-files/files/lib/functions.sh
@@ -254,7 +254,6 @@ default_postinst() {
fi
 
if grep -m1 -q -s "^/etc/uci-defaults/" "$filelist"; then
-   . /lib/functions/system.sh
[ -d /tmp/.uci ] || mkdir -p /tmp/.uci
for i in $(grep -s "^/etc/uci-defaults/" "$filelist"); 
do
( [ -f "$i" ] && cd "$(dirname $i)" && . "$i" ) 
&& rm -f "$i"
-- 
2.20.1


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

[OpenWrt-Devel] [PATCH 2/3] base-files: source functions.sh in /lib/functions/system.sh

[Adrian Schmutzler]

The file /lib/functions/system.sh depends on find_mtd_index() and
find_mtd_part() located in /lib/function.sh, so let's source that
file.

Signed-off-by: Adrian Schmutzler 
---
 package/base-files/files/lib/functions/system.sh | 1 +
 1 file changed, 1 insertion(+)

diff --git a/package/base-files/files/lib/functions/system.sh 
b/package/base-files/files/lib/functions/system.sh
index c9f8eb0c31..c7aa7bf75c 100644
--- a/package/base-files/files/lib/functions/system.sh
+++ b/package/base-files/files/lib/functions/system.sh
@@ -1,5 +1,6 @@
 # Copyright (C) 2006-2013 OpenWrt.org
 
+. /lib/functions.sh
 . /usr/share/libubox/jshn.sh
 
 get_mac_binary() {
-- 
2.20.1


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

Re: [OpenWrt-Devel] cyclic dependency for /lib/functions.sh and /lib/functions/system.sh in special case

[Adrian Schmutzler]

Hi,

> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org] On
> Behalf Of mans0n
> Sent: Freitag, 13. März 2020 14:35
> To: Adrian Schmutzler ; openwrt-
> de...@lists.openwrt.org
> Subject: Re: [OpenWrt-Devel] cyclic dependency for /lib/functions.sh and
> /lib/functions/system.sh in special case
> 
> Hi Adrian,
> 
> On 2020-03-13 03:38, mail at adrianschmutzler.de (Adrian Schmutzler) wrote:
>  > Hi,
>  >
>  > I just wanted to source /lib/functions.sh in /lib/functions/system.sh
>  > (base-files package), as several functions in the latter require the
> former and
>  > it's annoying (and untidy) to have to include both files in several
> places.
>  >
>  > However, I realized that currently /lib/functions/system.sh is sourced in
>  > /lib/functions.sh, function default_postinst():
>  >
>  >
> https://github.com/openwrt/openwrt/blob/8df14c229c02a3b9329afc6e3ebf4f8a
> ec5b59ed
>  > /package/base-files/files/lib/functions.sh#L257
>  >
>  > So, currently effectively both files depend on each other in at least
> one case.
>  >
>  > However, in default_postinst(), it looks to me like no function from
> system.sh
>  > is actually used directly, but it's merely put there as an "external
> include"
>  > for the /etc/uci-defaults/* files processed there.
>  >
>  > I'd like to resolve this, both as I think the sourcing of
> /lib/functions.sh in
>  > /lib/functions/system.sh is helpful and tidy and because I think the
> cross
>  > dependency is quite undesirable.
>  >
>  > I see two solutions to that problem:
>  >
>  > 1. Remove the sourcing of /lib/functions/system.sh in
> default_postinst(). That
>  > would be the tidiest way IMO, as dependencies used in a uci-default
> script
>  > should just be put there. But it might break things if people relied
> on it. It
>  > would be relatively easy to fix uci-default scripts in openwrt repos, but
>  > downstream might complain. Still, I'd prefer this solution.
> 
> I like your first solution. It seems there's only one uci-defaults file
> in OpenWrt
> repo which really uses /lib/functions/system.sh. I guess downstream
> projects can
> handle it relatively easily.
> 
> And if we are going to break things, I'd also like to create something like
> /lib/functions/mtd.sh and move all mtd functions to there (and rename
> system.sh
> to macaddr.sh if possible). I don't feel there's no good reason to keep
> find_mtd_part()
> in functions.sh and find_mtd_chardev() in system.sh.
> Then we might even don't need to source /lib/functions.sh in
> /lib/functions/system.sh
> at the first place. (I think /lib/functions.sh is too big to be sourced
> everywhere...)
> But that would really break things heavily, so it's just my thought.

Thanks for your response.

I've actually tried the mtd.sh solution, but it's too painful.

So, I've come up with a smaller solution, still based on option 1 ...

Best

Adrian

> 
> Thanks.
> 
>  >
>  > 2. A second option would be to keep the include, but just move the
> function
>  > default_postinst() out of /lib/functions.sh (from my perspective, it
> doesn't
>  > really match there anyway) into a different library file (which?).
> This would
>  > still resolve my "dependency problem".
>  >
>  > Any opinions?
>  >
>  > Best
>  >
>  > Adrian
>  >
>  >
> 
> 
> ___
> 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] [PATCH 3/3] base-files: move find_mtd_chardev() to /lib/functions.sh

[Adrian Schmutzler]

While find_mtd_index() and find_mtd_part() are located in
/lib/functions.sh, find_mtd_chardev() has been located in
/lib/functions/system.sh.

Move the latter to the former file to keep similar functions
together.

While at it, fix some corresponding includes.

Signed-off-by: Adrian Schmutzler 
---
 package/base-files/Makefile   | 2 +-
 package/base-files/files/lib/functions.sh | 8 
 package/base-files/files/lib/functions/system.sh  | 8 
 .../ath79/base-files/lib/functions/mikrotik-caldata.sh| 2 ++
 .../linux/lantiq/xrx200/base-files/etc/board.d/02_network | 1 +
 5 files changed, 12 insertions(+), 9 deletions(-)

diff --git a/package/base-files/Makefile b/package/base-files/Makefile
index 8e252153fe..87c43fdc0c 100644
--- a/package/base-files/Makefile
+++ b/package/base-files/Makefile
@@ -12,7 +12,7 @@ include $(INCLUDE_DIR)/version.mk
 include $(INCLUDE_DIR)/feeds.mk
 
 PKG_NAME:=base-files
-PKG_RELEASE:=215
+PKG_RELEASE:=216
 PKG_FLAGS:=nonshared
 
 PKG_FILE_DEPENDS:=$(PLATFORM_DIR)/ $(GENERIC_PLATFORM_DIR)/base-files/
diff --git a/package/base-files/files/lib/functions.sh 
b/package/base-files/files/lib/functions.sh
index a77b669709..0438e9e25a 100755
--- a/package/base-files/files/lib/functions.sh
+++ b/package/base-files/files/lib/functions.sh
@@ -302,6 +302,14 @@ find_mtd_part() {
echo "${INDEX:+$PREFIX$INDEX}"
 }
 
+find_mtd_chardev() {
+   local INDEX=$(find_mtd_index "$1")
+   local PREFIX=/dev/mtd
+
+   [ -d /dev/mtd ] && PREFIX=/dev/mtd/
+   echo "${INDEX:+$PREFIX$INDEX}"
+}
+
 group_add() {
local name="$1"
local gid="$2"
diff --git a/package/base-files/files/lib/functions/system.sh 
b/package/base-files/files/lib/functions/system.sh
index c7aa7bf75c..b5c68acb15 100644
--- a/package/base-files/files/lib/functions/system.sh
+++ b/package/base-files/files/lib/functions/system.sh
@@ -53,14 +53,6 @@ get_mac_label() {
echo $macaddr
 }
 
-find_mtd_chardev() {
-   local INDEX=$(find_mtd_index "$1")
-   local PREFIX=/dev/mtd
-
-   [ -d /dev/mtd ] && PREFIX=/dev/mtd/
-   echo "${INDEX:+$PREFIX$INDEX}"
-}
-
 mtd_get_mac_ascii() {
local mtdname="$1"
local key="$2"
diff --git a/target/linux/ath79/base-files/lib/functions/mikrotik-caldata.sh 
b/target/linux/ath79/base-files/lib/functions/mikrotik-caldata.sh
index 9c4016ee5d..81e262d874 100644
--- a/target/linux/ath79/base-files/lib/functions/mikrotik-caldata.sh
+++ b/target/linux/ath79/base-files/lib/functions/mikrotik-caldata.sh
@@ -4,6 +4,8 @@
 # Helper function to extract MAC addresses and calibration data for MikroTik
 #
 
+. /lib/functions/caldata.sh
+
 mikrotik_caldata_extract() {
local part=$1
local offset=$(($2))
diff --git a/target/linux/lantiq/xrx200/base-files/etc/board.d/02_network 
b/target/linux/lantiq/xrx200/base-files/etc/board.d/02_network
index f39898263d..6bb52ccf0c 100755
--- a/target/linux/lantiq/xrx200/base-files/etc/board.d/02_network
+++ b/target/linux/lantiq/xrx200/base-files/etc/board.d/02_network
@@ -3,6 +3,7 @@
 # Copyright (C) 2011-2015 OpenWrt.org
 #
 
+. /lib/functions.sh
 . /lib/functions/uci-defaults.sh
 . /lib/functions/system.sh
 . /lib/functions/lantiq.sh
-- 
2.20.1


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

Re: [OpenWrt-Devel] [PATCH uhttpd] client: allow keep-alive for POST requests

[Wes Turner]

Are there *new* security implications of allowing keep-alive?

Slowloris DoS comes to mind:
https://en.wikipedia.org/wiki/Slowloris_(computer_security)

And the article mentions a number of tools.

Older devices are likely somewhat trivially DoS-able without this patch;
but maybe include a config option to disable keep-alive?

What happens to RAM and CPU usage when there are multiple tabs open with
keep-alive on?

On Fri, Mar 13, 2020, 8:20 AM Jo-Philipp Wich  wrote:

> Allow POST requests via persistent connections to improve performance
> especially when using HTTPS on older devices.
>
> After this change, average page load times in LuCI improve significantly
> once the TLS connections are initiated.
>
> When testing an ar71xx 19.07.2 build on an ethernet connected TL-WR1043nd
> using luci-ssl-openssl and the ustream-openssl backend, the average page
> load time for the main status page decreased to 1.3s compared to 4.7s
> before, the interface and wireless configuration pages loaded in 1.2s
> seconds each compared to the 4.2s and 4.9s respectively before.
>
> Signed-off-by: Jo-Philipp Wich 
> ---
>  client.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/client.c b/client.c
> index 92f7609..2a2393f 100644
> --- a/client.c
> +++ b/client.c
> @@ -194,8 +194,7 @@ static int client_parse_request(struct client *cl,
> char *data)
>
> req->method = h_method;
> req->version = h_version;
> -   if (req->version < UH_HTTP_VER_1_1 || req->method ==
> UH_HTTP_MSG_POST ||
> -   !conf.http_keepalive)
> +   if (req->version < UH_HTTP_VER_1_1 || !conf.http_keepalive)
> req->connection_close = true;
>
> return CLIENT_STATE_HEADER;
> --
> 2.25.1
>
>
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel
>
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH] pkgconf: always retain -I and -L flags

[Jo-Philipp Wich]

The pkgconf fork filters -I and -L flag values from .pc files which match
pkgconf's builtin system directory value.

During configure, pkgconf derives the default system include and library
search path values from exec_prefix, which is set to staging_dir/host in
the host tool build phase.

Due to that, pkgconf will drop all -I and -L flags pointing to
staging_dir/host/include or staging_dir/host/lib, unless invoked with
--keep-system-cflags and --keep-system-libs respectively, breaking our
kernel libelf discovery / stack validation workarounds.

In order to inhibit the filtering, add --keep-system-cflags and
--keep-system-libs to our pkg-config shell wrapper.

Fixes: GH#2832
Fixes: 867298cf47 ("tools/pkg-config: Replace with pkgconf")
Ref: https://lists.infradead.org/pipermail/openwrt-devel/2020-March/022182.html
Ref: https://git.openwrt.org/fe43969336201f2cc7d103b68fd6e65989bee184
Signed-off-by: Jo-Philipp Wich 
---
 tools/pkgconf/files/pkg-config | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/tools/pkgconf/files/pkg-config b/tools/pkgconf/files/pkg-config
index fa1faccc6c..2c6fd08b4a 100755
--- a/tools/pkgconf/files/pkg-config
+++ b/tools/pkgconf/files/pkg-config
@@ -1,6 +1,8 @@
 #!/bin/sh
 
 pkg-config.real \
+--keep-system-cflags \
+--keep-system-libs \
 --define-variable=prefix="${STAGING_PREFIX}" \
 --define-variable=exec_prefix="${STAGING_PREFIX}" \
 --define-variable=bindir="${STAGING_PREFIX}/bin" "$@"
-- 
2.25.1


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

Re: [OpenWrt-Devel] [PATCH] .gitignore: ignore all .config* files

[mans0n]

On 2020-03-13 23:30, Adrian Schmutzler wrote:

-Original Message-
From: mans0n [mailto:man...@gorani.run]
Sent: Freitag, 13. März 2020 14:26
To: Catrinel Catrinescu ; Adrian Schmutzler
; openwrt-devel@lists.openwrt.org
Subject: Re: [OpenWrt-Devel] [PATCH] .gitignore: ignore all .config* files

Hi,

If we are going to accept this patch, I would suggest "/.config.*"


This would require a separate "/.config" though, wouldn't it?


Yes, exactly. That is also my intention.




instead of
"/.config*". That would suffice for all local usages.

Thanks.

On 2020-03-10 21:33, cc at 80211.de (Catrinel Catrinescu) wrote:

Hi Adrian

After successful testing, I always save the .config files, attaching the

revision

number, like .config_r12345.


And it is a cosmetic replacement too.


Thanks
Catrinel




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

[OpenWrt-Devel] pkgconf issue with kmods and libelf [Was: Re: tools/pkg-config: Replace with pkgconf]

[Petr Štetiar]

Rosen Penev  [2020-02-28 20:12:45]:

Hi,

> It's more portable and smaller. And as stated, it is still fairly active.

Jo has today brought following issue to my attention:

## pkgconf
 $ PATH=$(pwd)/staging_dir/host/bin:$PATH 
STAGING_PREFIX=$(pwd)/staging_dir/host 
PKG_CONFIG_PATH=$(pwd)/staging_dir/host/lib/pkgconfig 
PKG_CONFIG_LIBDIR=$(pwd)/staging_dir/host/lib/pkgconfig pkg-config libelf --libs
 -lelf

## pkg-config

 $ PATH=$(pwd)/staging_dir/host/bin:$PATH 
STAGING_PREFIX=$(pwd)/staging_dir/host 
PKG_CONFIG_PATH=$(pwd)/staging_dir/host/lib/pkgconfig 
PKG_CONFIG_LIBDIR=$(pwd)/staging_dir/host/lib/pkgconfig pkg-config libelf --libs
 -L/home/jow/devel/lede/staging.git/staging_dir/host/lib -lelf

So it looks like pkgconf is filtering out some library paths, causing for
example following issues:

 make[5]: *** No rule to make target 'tools/objtool/objtool', needed by 
'/home/jow/devel/lede/staging.git/build_dir/target-x86_64_musl/linux-x86_64/siit-1.2/siit.o'.
  Stop.

< jow> the main kernel build will skip building objtool (and forcibly disable 
CONFIG_STACK_VALIDATION) because it cannot link libelf
< jow> any external kmod will assume CONFIG_STACK_VALIDATION is enabled and 
kbuild will try to invoke objtool which doesn't exist in the precompiled kernel 
soure tree

Possibly caused by:

 ## linker flags optimization

 As previously mentioned, pkgconf makes optimizations to the linker flags in
 both the case of static and shared linking in order to avoid overlinking
 binaries and also simplifies the `CFLAGS` and `LIBS` output of the pkgconf
 tool for improved readability.

Ref: https://github.com/openwrt/openwrt/pull/2832

-- ynezz

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

Re: [OpenWrt-Devel] [PATCH] .gitignore: ignore all .config* files

[Adrian Schmutzler]

> -Original Message-
> From: mans0n [mailto:man...@gorani.run]
> Sent: Freitag, 13. März 2020 14:26
> To: Catrinel Catrinescu ; Adrian Schmutzler
> ; openwrt-devel@lists.openwrt.org
> Subject: Re: [OpenWrt-Devel] [PATCH] .gitignore: ignore all .config* files
> 
> Hi,
> 
> If we are going to accept this patch, I would suggest "/.config.*"

This would require a separate "/.config" though, wouldn't it?

> instead of
> "/.config*". That would suffice for all local usages.
> 
> Thanks.
> 
> On 2020-03-10 21:33, cc at 80211.de (Catrinel Catrinescu) wrote:
> > Hi Adrian
> >
> > After successful testing, I always save the .config files, attaching the
revision
> number, like .config_r12345.
> >
> > And it is a cosmetic replacement too.
> >
> >
> > Thanks
> > Catrinel


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

Re: [OpenWrt-Devel] [PATCH 2/5] toolchain/gcc: make GCC9 by default for archs38

[Evgeniy Didin]

Hi Hauke,

This problem reproduces only for ARC(ARM is ok) and Linux v5.4 (v4.19 is ok).


Best regards,
Evgeniy Didin


From: Hauke Mehrtens 
Sent: Thursday, March 12, 2020 6:33 PM
To: Evgeniy Didin ; openwrt-devel@lists.openwrt.org 

Cc: Alexey Brodkin ; Petr Štetiar ; John 
Crispin 
Subject: Re: [PATCH 2/5] toolchain/gcc: make GCC9 by default for archs38

On 3/12/20 2:34 PM, Evgeniy Didin wrote:
> It is necessary to use GCC9 for building Linux 5.4.x version for
> archs38, in GCC8 the critical fixes are missing and ICE appears
> during building.

Is this problem specific to OpenWrt or is there a general problem with
arc Linux and gcc 8.3?

Should it work with gcc 8.4?

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

Re: [OpenWrt-Devel] cyclic dependency for /lib/functions.sh and /lib/functions/system.sh in special case

[mans0n]

Hi Adrian,

On 2020-03-13 03:38, mail at adrianschmutzler.de (Adrian Schmutzler) wrote:
> Hi,
>
> I just wanted to source /lib/functions.sh in /lib/functions/system.sh
> (base-files package), as several functions in the latter require the 
former and
> it's annoying (and untidy) to have to include both files in several 
places.

>
> However, I realized that currently /lib/functions/system.sh is sourced in
> /lib/functions.sh, function default_postinst():
>
> 
https://github.com/openwrt/openwrt/blob/8df14c229c02a3b9329afc6e3ebf4f8aec5b59ed

> /package/base-files/files/lib/functions.sh#L257
>
> So, currently effectively both files depend on each other in at least 
one case.

>
> However, in default_postinst(), it looks to me like no function from 
system.sh
> is actually used directly, but it's merely put there as an "external 
include"

> for the /etc/uci-defaults/* files processed there.
>
> I'd like to resolve this, both as I think the sourcing of 
/lib/functions.sh in
> /lib/functions/system.sh is helpful and tidy and because I think the 
cross

> dependency is quite undesirable.
>
> I see two solutions to that problem:
>
> 1. Remove the sourcing of /lib/functions/system.sh in 
default_postinst(). That
> would be the tidiest way IMO, as dependencies used in a uci-default 
script
> should just be put there. But it might break things if people relied 
on it. It

> would be relatively easy to fix uci-default scripts in openwrt repos, but
> downstream might complain. Still, I'd prefer this solution.

I like your first solution. It seems there's only one uci-defaults file 
in OpenWrt
repo which really uses /lib/functions/system.sh. I guess downstream 
projects can

handle it relatively easily.

And if we are going to break things, I'd also like to create something like
/lib/functions/mtd.sh and move all mtd functions to there (and rename 
system.sh
to macaddr.sh if possible). I don't feel there's no good reason to keep 
find_mtd_part()

in functions.sh and find_mtd_chardev() in system.sh.
Then we might even don't need to source /lib/functions.sh in 
/lib/functions/system.sh
at the first place. (I think /lib/functions.sh is too big to be sourced 
everywhere...)

But that would really break things heavily, so it's just my thought.

Thanks.

>
> 2. A second option would be to keep the include, but just move the 
function
> default_postinst() out of /lib/functions.sh (from my perspective, it 
doesn't
> really match there anyway) into a different library file (which?). 
This would

> still resolve my "dependency problem".
>
> Any opinions?
>
> Best
>
> Adrian
>
>


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

Re: [OpenWrt-Devel] [PATCH] .gitignore: ignore all .config* files

[mans0n]

Hi,

If we are going to accept this patch, I would suggest "/.config.*" 
instead of

"/.config*". That would suffice for all local usages.

Thanks.

On 2020-03-10 21:33, cc at 80211.de (Catrinel Catrinescu) wrote:

Hi Adrian

After successful testing, I always save the .config files, attaching the 
revision number, like .config_r12345.

And it is a cosmetic replacement too.


Thanks
Catrinel


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

Re: [OpenWrt-Devel] [PATCH 1/3] zynq: copy config from kernel 4.19 to 5.4

[Petr Štetiar]

Adrian Schmutzler  [2020-03-13 13:17:42]:

> I'm aware of the two-step procedure (1. copy without changes, 2. refresh), I
> just read the message in a way that the config was refreshed _before_ copying
> it?

Yep, Luis did exactly what he described in his commit description, he really
refreshed the 4.19 config first (IIRC two symbols refreshed?) and copied it to
5.4. 

That's probably the pedantic way, fixing first 4.19 config, then refresh it
for 5.4, so the diff for 5.4 contains only symbols related to 5.4, not to 4.19
cleanup/refresh.

-- ynezz

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

Re: [OpenWrt-Devel] [PATCH] ath79: use downstream ag71xx for Kernel 5.4

[Petr Štetiar]

Bjørn Mork  [2020-03-13 09:29:49]:

> David Bauer  writes:
> 
> > --- 
> > a/target/linux/ath79/files-4.19/drivers/net/ethernet/atheros/ag71xx/ag71xx_main.c
> > +++ 
> > b/target/linux/ath79/files/drivers/net/ethernet/atheros/ag71xx/ag71xx_main.c
> > @@ -1581,7 +1581,7 @@ static int ag71xx_probe(struct platform_device *pdev)
> > ag->stop_desc->next = (u32) ag->stop_desc_dma;
> >  
> > mac_addr = of_get_mac_address(np);
> > -   if (mac_addr)
> > +   if (mac_addr && !IS_ERR(mac_addr))
> 
> bikeshedding...

Not bikeshedding at all, good catch. It's an issue which should be fixed.

It should be just `if (!IS_ERR(mac_addr))` because it's either valid pointer
or ERR_PTR since 5.2 via commit d01f449c008a ("of_net: add NVMEM support to
of_get_mac_address"). I would simply copy the fragment from upstream
ag71xx.c.

681-NET-add-of_get_mac_address_mtd.patch needs to be updated for 5.4, that
of_get_mac_address_mtd() shouldn't return NULL, but ERR_PTR instead.

-- ynezz

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

[OpenWrt-Devel] [PATCH uhttpd] client: allow keep-alive for POST requests

[Jo-Philipp Wich]

Allow POST requests via persistent connections to improve performance
especially when using HTTPS on older devices.

After this change, average page load times in LuCI improve significantly
once the TLS connections are initiated.

When testing an ar71xx 19.07.2 build on an ethernet connected TL-WR1043nd
using luci-ssl-openssl and the ustream-openssl backend, the average page
load time for the main status page decreased to 1.3s compared to 4.7s
before, the interface and wireless configuration pages loaded in 1.2s
seconds each compared to the 4.2s and 4.9s respectively before.

Signed-off-by: Jo-Philipp Wich 
---
 client.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/client.c b/client.c
index 92f7609..2a2393f 100644
--- a/client.c
+++ b/client.c
@@ -194,8 +194,7 @@ static int client_parse_request(struct client *cl, char 
*data)
 
req->method = h_method;
req->version = h_version;
-   if (req->version < UH_HTTP_VER_1_1 || req->method == UH_HTTP_MSG_POST ||
-   !conf.http_keepalive)
+   if (req->version < UH_HTTP_VER_1_1 || !conf.http_keepalive)
req->connection_close = true;
 
return CLIENT_STATE_HEADER;
-- 
2.25.1


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

Re: [OpenWrt-Devel] [PATCH 1/3] zynq: copy config from kernel 4.19 to 5.4

[Adrian Schmutzler]

Hi Petr,

> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org] On
> Behalf Of Petr Štetiar
> Sent: Freitag, 13. März 2020 13:14
> To: Adrian Schmutzler 
> Cc: openwrt-devel@lists.openwrt.org; 'Luis Araneda' 
> Subject: Re: [OpenWrt-Devel] [PATCH 1/3] zynq: copy config from kernel 4.19 to
> 5.4
> 
> Adrian Schmutzler  [2020-03-13 13:02:10]:
> 
> BTW, I've already accepted the series and I'm build testing/fixing it
> already[1].
> 
> > I do not see a change to kernel 4.19 config in this patch and why would you
> > refresh the old config before copying to the new kernel?
> 
> Its common step to make review easier, allowing for clear config changes diff
> for 4.19->5.4 in `zynq: refresh kernel 5.4 config`.

I'm aware of the two-step procedure (1. copy without changes, 2. refresh), I
just read the message in a way that the config was refreshed _before_ copying
it?
May it's a language issue, though ...

Best

Adrian

> 
> 1. https://gitlab.com/ynezz/openwrt/-/jobs/470651723
> 
> -- ynezz
> 
> ___
> 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: [OpenWrt-Devel] [PATCH 1/3] zynq: copy config from kernel 4.19 to 5.4

[Petr Štetiar]

Adrian Schmutzler  [2020-03-13 13:02:10]:

BTW, I've already accepted the series and I'm build testing/fixing it
already[1].

> I do not see a change to kernel 4.19 config in this patch and why would you
> refresh the old config before copying to the new kernel? 

Its common step to make review easier, allowing for clear config changes diff
for 4.19->5.4 in `zynq: refresh kernel 5.4 config`.

1. https://gitlab.com/ynezz/openwrt/-/jobs/470651723

-- ynezz

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

Re: [OpenWrt-Devel] [PATCH 1/3] zynq: copy config from kernel 4.19 to 5.4

[Adrian Schmutzler]

> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org] On
> Behalf Of Luis Araneda
> Sent: Freitag, 13. März 2020 04:23
> To: openwrt-devel@lists.openwrt.org
> Cc: Luis Araneda 
> Subject: [OpenWrt-Devel] [PATCH 1/3] zynq: copy config from kernel 4.19 to 5.4
> 
> Refreshed kernel 4.19 config before copying the file

I do not see a change to kernel 4.19 config in this patch and why would you
refresh the old config before copying to the new kernel? 


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

[OpenWrt-Devel] [PATCH ustream-ssl] ustream-openssl: clear error stack before SSL_read/SSL_write

[Jo-Philipp Wich]

The OpenSSL library uses a global error queue per thread which needs to
be cleared prior to calling I/O functions in order to get reliable error
results.

Failure to do so will lead to stray errors reported by SSL_get_error()
when an unrelated connection within the same thread encountered a TLS
error since the last SSL_read() or SSL_write() on the current connection.

This issue was frequently triggered by Google Chrome which usually
initiates simultaneous TLS connections (presumably for protocol support
probing) and subsequently closes most of them with a "certificate unknown"
TLS error, causing the next SSL_get_error() to report an SSL library error
instead of the expected SSL_WANT_READ or SSL_WANT_WRITE error states.

Solve this issue by invoking ERR_clear_error() prior to invoking SSL_read()
or SSL_write() to ensure that the subsequent SSL_get_error() returns
current valid results.

Signed-off-by: Jo-Philipp Wich 
---
 ustream-openssl.c | 14 --
 1 file changed, 12 insertions(+), 2 deletions(-)

diff --git a/ustream-openssl.c b/ustream-openssl.c
index 049aa40..f8e848d 100644
--- a/ustream-openssl.c
+++ b/ustream-openssl.c
@@ -266,6 +266,8 @@ __hidden enum ssl_conn_status __ustream_ssl_connect(struct 
ustream_ssl *us)
void *ssl = us->ssl;
int r;
 
+   ERR_clear_error();
+
if (us->server)
r = SSL_accept(ssl);
else
@@ -287,7 +289,11 @@ __hidden enum ssl_conn_status __ustream_ssl_connect(struct 
ustream_ssl *us)
 __hidden int __ustream_ssl_write(struct ustream_ssl *us, const char *buf, int 
len)
 {
void *ssl = us->ssl;
-   int ret = SSL_write(ssl, buf, len);
+   int ret;
+
+   ERR_clear_error();
+
+   ret = SSL_write(ssl, buf, len);
 
if (ret < 0) {
int err = SSL_get_error(ssl, ret);
@@ -303,7 +309,11 @@ __hidden int __ustream_ssl_write(struct ustream_ssl *us, 
const char *buf, int le
 
 __hidden int __ustream_ssl_read(struct ustream_ssl *us, char *buf, int len)
 {
-   int ret = SSL_read(us->ssl, buf, len);
+   int ret;
+
+   ERR_clear_error();
+
+   ret = SSL_read(us->ssl, buf, len);
 
if (ret < 0) {
ret = SSL_get_error(us->ssl, ret);
-- 
2.25.1


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

Re: [OpenWrt-Devel] [PATCH] ath79: use downstream ag71xx for Kernel 5.4

[Hauke Mehrtens]

On 3/13/20 1:07 AM, David Bauer wrote:
> The ag71xx driver from Linux 5.4 currently has various shortcomings
> when used with OpenWrt compared to our downstream version.
> 
> For example, the upstream driver does not support modifying the ethernet
> clock and configuring RGMII delays on the MAC side.
> 
> While we should certainly switch to the upstream driver, the amount of
> necessary patches would make it cumbersome to work with. It's also
> highly likely we won't be able to finish patching the upstream driver in
> time for a Linux 5.4 release.
> 
> Tested on Siemens WS-AP3610.
> 
> CC: Hauke Mehrtens 
> Signed-off-by: David Bauer 

Acked-by: Hauke Mehrtens 

We should still try to improve the upstream driver in the upstream
kernel, so we can use it when we switch to the next major kernel version
next year.

We should also improve our device tree files to make them compatible
with both drivers, but all of this will probably take multiple months as
we support over 200 different ath79 boards.

Hauke

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

Re: [OpenWrt-Devel] [PATCH] ath79: use downstream ag71xx for Kernel 5.4

[Bjørn Mork]

David Bauer  writes:

> --- 
> a/target/linux/ath79/files-4.19/drivers/net/ethernet/atheros/ag71xx/ag71xx_main.c
> +++ 
> b/target/linux/ath79/files/drivers/net/ethernet/atheros/ag71xx/ag71xx_main.c
> @@ -1581,7 +1581,7 @@ static int ag71xx_probe(struct platform_device *pdev)
>   ag->stop_desc->next = (u32) ag->stop_desc_dma;
>  
>   mac_addr = of_get_mac_address(np);
> - if (mac_addr)
> + if (mac_addr && !IS_ERR(mac_addr))

bikeshedding...  But how about

   if (!IS_ERR_OR_NULL(mac_addr))

?


>   memcpy(dev->dev_addr, mac_addr, ETH_ALEN);
>   if (!mac_addr || !is_valid_ether_addr(dev->dev_addr)) {
>   dev_err(>dev, "invalid MAC address, using random 
> address\n");


This looks odd to me.  If we needed that !mac_addr test before, then
it will probably have to change to !IS_ERR_OR_NULL as well.

But do we really need to test mac_addr again?  dev was allocated by
devm_alloc_etherdev() a few lines up, so dev->dev_addr is guaranteed to
be all zeros if of_get_mac_address() failed.  Checking for
!is_valid_ether_addr(dev->dev_addr) should be more than sufficient here.

Micro optimizing for the !mac_addr case does not make any sense here
IMHO.


Bjørn

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