Re: [OpenWrt-Devel] package mt76 fails to compile under certain configuration [Was: Compilation error on master / mt7620]

2019-08-02 Thread Joan Moreau 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 ---
well maybe 

Bottom line : mt76 is not usable in master or 19.07. 

So far 

- DebugFS creates compilation error 

- SquashFS does not include LZO and creates compilation errors 


On 2019-08-03 09:57, Rosen Penev wrote:


On Fri, Aug 2, 2019 at 5:55 PM Joan Moreau via openwrt-devel
 wrote: 


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.

-- Forwarded message --
From: Joan Moreau 
To: "Petr Štetiar" 
Cc: openwrt-devel@lists.openwrt.org
Bcc:
Date: Sat, 03 Aug 2019 08:54:45 +0800
Subject: Re: [OpenWrt-Devel] package mt76 fails to compile under certain 
configuration [Was: Compilation error on master / mt7620]

In an attempt to force LZO with JFFS2, I clicked on "mksquash" in menuconfig.

I reach the follwoing error

mipsel-openwrt-linux-musl-gcc -Os -pipe -mno-branch-likely -mips32r2 -mtune=24kc 
-fno-caller-saves -fno-plt -fhonour-copts -Wno-error=unused-but-set-variable 
-Wno-error=unused-result -msoft-float -mips16 -minterlink-mips16 
-iremap/usr/src/openwrt/4g/build_dir/target-mipsel_24kc_musl/squashfs-tools-4.3:squashfs-tools-4.3
 -Wformat -Werror=format-security -fstack-protector -D_FORTIFY_SOURCE=1 -Wl,-z,now 
-Wl,-z,relro -I/usr/src/openwrt/4g/staging_dir/target-mipsel_24kc_musl/usr/include 
-I/usr/src/openwrt/4g/staging_dir/target-mipsel_24kc_musl/include 
-I/usr/src/openwrt/4g/staging_dir/toolchain-mipsel_24kc_gcc-7.4.0_musl/usr/include 
-I/usr/src/openwrt/4g/staging_dir/toolchain-mipsel_24kc_gcc-7.4.0_musl/include/fortify 
-I/usr/src/openwrt/4g/staging_dir/toolchain-mipsel_24kc_gcc-7.4.0_musl/include -I. 
-D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_GNU_SOURCE 
-DCOMP_DEFAULT=\"gzip\" -Wall -DGZIP_SUPPORT -DXZ_SUPPORT -DLZO_SUPPORT 
-DLZ4_SUPPORT -c -o mksquashfs.o mksquashfs.c
mksquashfs.c: In function 'create_inode':
mksquashfs.c:996:24: error: called object 'major' is not a function or function 
pointer
unsigned int major = major(buf->st_rdev);
^
mksquashfs.c:996:16: note: declared here
unsigned int major = major(buf->st_rdev);
^

Something is very broken in mt76

That error is related to squashfs-tools, not mt76:
https://downloads.openwrt.org/snapshots/faillogs/mips_24kc/packages/squashfs-tools/compile.txt 


On 2019-08-02 23:12, Joan Moreau wrote:

Additionally, I get the following error in the image generated (master) without 
the debugfs option then to allow compilation

[ 8.936247] jffs2: Error: unknown compressor "zlib"
[ 8.941939] mount_root: failed to mount -t jffs2 /dev/mtdblock6 /tmp/overlay: 
Invalid argument
[ 8.951033] mount_root: overlay filesystem has not been fully initialized yet
[ 8.958979] mount_root: switching to jffs2 overlay
[ 8.964114] mount_root: switching to jffs2 failed - fallback to ramoverlay

On 2019-08-02 21:37, Joan Moreau wrote:

Removing "debug fs" in compilation options removes the problem.

So there is something very awkward in the Makefile

On 2019-08-02 20:28, Joan Moreau wrote:

attached

On 2019-08-02 18:36, Petr Štetiar wrote:

Joan Moreau via openwrt-devel  [2019-08-02 
07:56:41]:

Hello,

I reach the following error while compiling my MT7620/ZBT826-16M on
master (no error on 18.06) :

CC [M]
/usr/src/openwrt/4g/build_dir/target-mipsel_24kc_musl/linux-ramips_mt7620/mt76-2019-07-22-75656a45/mt7603/pci.o
:0:37: error: redeclaration of enumerator
'IEEE80211_HW_REPORTS_TX_ACK_STATUS'
:0:37: note: in definition of macro
'IEEE80211_HW_TX_STATUS_NO_AMPDU_LEN'
In file included from
/usr/src/openwrt/4g/build_dir/target-mipsel_24kc_musl/linux-ramips_mt7620/mt76-2019-07-22-75656a45/mt7603/../mt76.h:27:0,
from
/usr/src/openwrt/4g/build_dir/target-mipsel_24kc_musl/linux-ramips_mt7620/mt76-2019-07-22-75656a45/mt7603/mt7603.h:8,
from
/usr/src/openwrt/4g/build_dir/target-mipsel_24kc_musl/linux-ramips_mt7620/mt76-2019-07-22-75656a45/mt7603/pci.c:7:
/usr/src/openwrt/4g/staging_dir/target-mipsel_24kc_musl/usr/include/mac80211/net/mac80211.h:2293:2:
note: previous definition of 'IEEE80211_HW_REPORTS_TX_ACK_STATUS' was
here
IEEE80211_HW_REPORTS_TX_ACK_STATUS,
^~
make[6]: *** [scripts/Makefile.build:327:
/usr/src/openwrt/4g/build_dir/target-mipsel_24kc_musl/linux-ramips_mt7620/mt76-2019-07-22-75656a45/mt7603/pci.o]
Error 1
make[5]: *** [scripts/Makefile.build:585:
/usr/src/openwrt/4g/build_dir/target-mipsel_24kc_musl/linux-ramips_mt7620/mt76-2019-07-22-75656a45/mt7603]
Error 2
make[4]: *** [Makefile:1532:
_module_/usr/src/openwrt/4g/build_dir/target-mipsel_24kc_musl/linux-ramips_mt7620/mt76-2019-07-22-75656a45]
Error 2

Can you help ?

the problem is probably in 

Re: [OpenWrt-Devel] package mt76 fails to compile under certain configuration [Was: Compilation error on master / mt7620]

2019-08-02 Thread Rosen Penev
On Fri, Aug 2, 2019 at 5:55 PM Joan Moreau via openwrt-devel
 wrote:
>
> 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.
>
>
> -- Forwarded message --
> From: Joan Moreau 
> To: "Petr Štetiar" 
> Cc: openwrt-devel@lists.openwrt.org
> Bcc:
> Date: Sat, 03 Aug 2019 08:54:45 +0800
> Subject: Re: [OpenWrt-Devel] package mt76 fails to compile under certain 
> configuration [Was: Compilation error on master / mt7620]
>
> In an attempt to force LZO with JFFS2, I clicked on "mksquash" in menuconfig.
>
>
> I reach the follwoing error
>
> mipsel-openwrt-linux-musl-gcc -Os -pipe -mno-branch-likely -mips32r2 
> -mtune=24kc -fno-caller-saves -fno-plt -fhonour-copts 
> -Wno-error=unused-but-set-variable -Wno-error=unused-result -msoft-float 
> -mips16 -minterlink-mips16 
> -iremap/usr/src/openwrt/4g/build_dir/target-mipsel_24kc_musl/squashfs-tools-4.3:squashfs-tools-4.3
>  -Wformat -Werror=format-security -fstack-protector -D_FORTIFY_SOURCE=1 
> -Wl,-z,now -Wl,-z,relro 
> -I/usr/src/openwrt/4g/staging_dir/target-mipsel_24kc_musl/usr/include 
> -I/usr/src/openwrt/4g/staging_dir/target-mipsel_24kc_musl/include 
> -I/usr/src/openwrt/4g/staging_dir/toolchain-mipsel_24kc_gcc-7.4.0_musl/usr/include
>  
> -I/usr/src/openwrt/4g/staging_dir/toolchain-mipsel_24kc_gcc-7.4.0_musl/include/fortify
>  
> -I/usr/src/openwrt/4g/staging_dir/toolchain-mipsel_24kc_gcc-7.4.0_musl/include
>  -I. -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_GNU_SOURCE 
> -DCOMP_DEFAULT=\"gzip\" -Wall -DGZIP_SUPPORT -DXZ_SUPPORT -DLZO_SUPPORT 
> -DLZ4_SUPPORT -c -o mksquashfs.o mksquashfs.c
> mksquashfs.c: In function 'create_inode':
> mksquashfs.c:996:24: error: called object 'major' is not a function or 
> function pointer
> unsigned int major = major(buf->st_rdev);
> ^
> mksquashfs.c:996:16: note: declared here
> unsigned int major = major(buf->st_rdev);
> ^
>
>
> Something is very broken in mt76
That error is related to squashfs-tools, not mt76:
https://downloads.openwrt.org/snapshots/faillogs/mips_24kc/packages/squashfs-tools/compile.txt
>
>
>
>
>
>
> On 2019-08-02 23:12, Joan Moreau wrote:
>
> Additionally, I get the following error in the image generated (master) 
> without the debugfs option then to allow compilation
>
>
> [ 8.936247] jffs2: Error: unknown compressor "zlib"
> [ 8.941939] mount_root: failed to mount -t jffs2 /dev/mtdblock6 /tmp/overlay: 
> Invalid argument
> [ 8.951033] mount_root: overlay filesystem has not been fully initialized yet
> [ 8.958979] mount_root: switching to jffs2 overlay
> [ 8.964114] mount_root: switching to jffs2 failed - fallback to ramoverlay
>
>
>
>
> On 2019-08-02 21:37, Joan Moreau wrote:
>
> Removing "debug fs" in compilation options removes the problem.
>
> So there is something very awkward in the Makefile
>
>
>
>
>
> On 2019-08-02 20:28, Joan Moreau wrote:
>
> attached
>
>
>
>
> On 2019-08-02 18:36, Petr Štetiar wrote:
>
> Joan Moreau via openwrt-devel  [2019-08-02 
> 07:56:41]:
>
> Hello,
>
> I reach the following error while compiling my MT7620/ZBT826-16M on
> master (no error on 18.06) :
>
> CC [M]
> /usr/src/openwrt/4g/build_dir/target-mipsel_24kc_musl/linux-ramips_mt7620/mt76-2019-07-22-75656a45/mt7603/pci.o
> :0:37: error: redeclaration of enumerator
> 'IEEE80211_HW_REPORTS_TX_ACK_STATUS'
> :0:37: note: in definition of macro
> 'IEEE80211_HW_TX_STATUS_NO_AMPDU_LEN'
> In file included from
> /usr/src/openwrt/4g/build_dir/target-mipsel_24kc_musl/linux-ramips_mt7620/mt76-2019-07-22-75656a45/mt7603/../mt76.h:27:0,
> from
> /usr/src/openwrt/4g/build_dir/target-mipsel_24kc_musl/linux-ramips_mt7620/mt76-2019-07-22-75656a45/mt7603/mt7603.h:8,
> from
> /usr/src/openwrt/4g/build_dir/target-mipsel_24kc_musl/linux-ramips_mt7620/mt76-2019-07-22-75656a45/mt7603/pci.c:7:
> /usr/src/openwrt/4g/staging_dir/target-mipsel_24kc_musl/usr/include/mac80211/net/mac80211.h:2293:2:
> note: previous definition of 'IEEE80211_HW_REPORTS_TX_ACK_STATUS' was
> here
> IEEE80211_HW_REPORTS_TX_ACK_STATUS,
> ^~
> make[6]: *** [scripts/Makefile.build:327:
> /usr/src/openwrt/4g/build_dir/target-mipsel_24kc_musl/linux-ramips_mt7620/mt76-2019-07-22-75656a45/mt7603/pci.o]
> Error 1
> make[5]: *** [scripts/Makefile.build:585:
> /usr/src/openwrt/4g/build_dir/target-mipsel_24kc_musl/linux-ramips_mt7620/mt76-2019-07-22-75656a45/mt7603]
> Error 2
> make[4]: *** [Makefile:1532:
> _module_/usr/src/openwrt/4g/build_dir/target-mipsel_24kc_musl/linux-ramips_mt7620/mt76-2019-07-22-75656a45]
> Error 2
>
> Can you help ?
>
>
> the problem is probably in this compile check[1], so please do following:
>
>  make package/mt76/{clean,prepare}
>  sed -i 's;TMP";TMP" 2> $(TOPDIR)/meh.log;' 
> build_dir/target-mipsel_24kc_musl/linux-ramips_mt7620/mt76-2019-07-22-75656a45/mt7603/Makefile
>  make 

Re: [OpenWrt-Devel] package mt76 fails to compile under certain configuration [Was: Compilation error on master / mt7620]

2019-08-02 Thread Joan Moreau 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 ---

In an attempt to force LZO with JFFS2, I clicked on "mksquash" in
menuconfig. 

I reach the follwoing error 


mipsel-openwrt-linux-musl-gcc -Os -pipe -mno-branch-likely -mips32r2
-mtune=24kc -fno-caller-saves -fno-plt -fhonour-copts
-Wno-error=unused-but-set-variable -Wno-error=unused-result -msoft-float
-mips16 -minterlink-mips16
-iremap/usr/src/openwrt/4g/build_dir/target-mipsel_24kc_musl/squashfs-tools-4.3:squashfs-tools-4.3
-Wformat -Werror=format-security -fstack-protector -D_FORTIFY_SOURCE=1
-Wl,-z,now -Wl,-z,relro
-I/usr/src/openwrt/4g/staging_dir/target-mipsel_24kc_musl/usr/include
-I/usr/src/openwrt/4g/staging_dir/target-mipsel_24kc_musl/include
-I/usr/src/openwrt/4g/staging_dir/toolchain-mipsel_24kc_gcc-7.4.0_musl/usr/include
-I/usr/src/openwrt/4g/staging_dir/toolchain-mipsel_24kc_gcc-7.4.0_musl/include/fortify
-I/usr/src/openwrt/4g/staging_dir/toolchain-mipsel_24kc_gcc-7.4.0_musl/include
-I. -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_GNU_SOURCE
-DCOMP_DEFAULT=\"gzip\" -Wall -DGZIP_SUPPORT -DXZ_SUPPORT -DLZO_SUPPORT
-DLZ4_SUPPORT -c -o mksquashfs.o mksquashfs.c
mksquashfs.c: In function 'create_inode':
mksquashfs.c:996:24: error: called object 'major' is not a function or
function pointer
unsigned int major = major(buf->st_rdev);
^
mksquashfs.c:996:16: note: declared here
unsigned int major = major(buf->st_rdev);
^ 

Something is very broken in mt76 


On 2019-08-02 23:12, Joan Moreau wrote:

Additionally, I get the following error in the image generated (master) without the debugfs option then to allow compilation 


[ 8.936247] jffs2: Error: unknown compressor "zlib"
[ 8.941939] mount_root: failed to mount -t jffs2 /dev/mtdblock6 /tmp/overlay: 
Invalid argument
[ 8.951033] mount_root: overlay filesystem has not been fully initialized yet
[ 8.958979] mount_root: switching to jffs2 overlay
[ 8.964114] mount_root: switching to jffs2 failed - fallback to ramoverlay

On 2019-08-02 21:37, Joan Moreau wrote: 

Removing "debug fs" in compilation options removes the problem. 

So there is something very awkward in the Makefile 

On 2019-08-02 20:28, Joan Moreau wrote: 


attached

On 2019-08-02 18:36, Petr Štetiar wrote: 
Joan Moreau via openwrt-devel  [2019-08-02 07:56:41]:


Hello,

I reach the following error while compiling my MT7620/ZBT826-16M on
master (no error on 18.06) :

CC [M]
/usr/src/openwrt/4g/build_dir/target-mipsel_24kc_musl/linux-ramips_mt7620/mt76-2019-07-22-75656a45/mt7603/pci.o
:0:37: error: redeclaration of enumerator
'IEEE80211_HW_REPORTS_TX_ACK_STATUS'
:0:37: note: in definition of macro
'IEEE80211_HW_TX_STATUS_NO_AMPDU_LEN'
In file included from
/usr/src/openwrt/4g/build_dir/target-mipsel_24kc_musl/linux-ramips_mt7620/mt76-2019-07-22-75656a45/mt7603/../mt76.h:27:0,
from
/usr/src/openwrt/4g/build_dir/target-mipsel_24kc_musl/linux-ramips_mt7620/mt76-2019-07-22-75656a45/mt7603/mt7603.h:8,
from
/usr/src/openwrt/4g/build_dir/target-mipsel_24kc_musl/linux-ramips_mt7620/mt76-2019-07-22-75656a45/mt7603/pci.c:7:
/usr/src/openwrt/4g/staging_dir/target-mipsel_24kc_musl/usr/include/mac80211/net/mac80211.h:2293:2:
note: previous definition of 'IEEE80211_HW_REPORTS_TX_ACK_STATUS' was
here
IEEE80211_HW_REPORTS_TX_ACK_STATUS,
^~
make[6]: *** [scripts/Makefile.build:327:
/usr/src/openwrt/4g/build_dir/target-mipsel_24kc_musl/linux-ramips_mt7620/mt76-2019-07-22-75656a45/mt7603/pci.o]
Error 1
make[5]: *** [scripts/Makefile.build:585:
/usr/src/openwrt/4g/build_dir/target-mipsel_24kc_musl/linux-ramips_mt7620/mt76-2019-07-22-75656a45/mt7603]
Error 2
make[4]: *** [Makefile:1532:
_module_/usr/src/openwrt/4g/build_dir/target-mipsel_24kc_musl/linux-ramips_mt7620/mt76-2019-07-22-75656a45]
Error 2

Can you help ? 
the problem is probably in this compile check[1], so please do following:


make package/mt76/{clean,prepare}
sed -i 's;TMP";TMP" 2> $(TOPDIR)/meh.log;' build_dir/target-mipsel_24kc_musl/linux-ramips_mt7620/mt76-2019-07-22-75656a45/mt7603/Makefile 
make package/mt76/compile

scripts/diffconfig.sh >> meh.log; gzip meh.log

and send meh.log.gz file as attachment.

1. https://github.com/openwrt/mt76/blob/master/mt7603/Makefile#L7

-- ynezz

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


[OpenWrt-Devel] [PATCH 2/2] mdadm: Include sys/sysmacros.h under musl as well.

2019-08-02 Thread Rosen Penev
Needed with musl version 1.1.23 as it no longer includes this header
internally. From changelog:

- sys/types.h no longer pollutes namespace with sys/sysmacros.h in any profile

Signed-off-by: Rosen Penev 
---
 package/utils/mdadm/patches/102-sysmacros.patch | 11 +++
 1 file changed, 11 insertions(+)
 create mode 100644 package/utils/mdadm/patches/102-sysmacros.patch

diff --git a/package/utils/mdadm/patches/102-sysmacros.patch 
b/package/utils/mdadm/patches/102-sysmacros.patch
new file mode 100644
index 00..68ec719f15
--- /dev/null
+++ b/package/utils/mdadm/patches/102-sysmacros.patch
@@ -0,0 +1,11 @@
+--- a/mdadm.h
 b/mdadm.h
+@@ -45,7 +45,7 @@ extern __off64_t lseek64 __P ((int __fd, __off64_t __offset, 
int __whence));
+ #include  
+ #include  
+ #include  
+-#ifdef __GLIBC__
++#if 1
+ /* Newer glibc requires sys/sysmacros.h directly for makedev() */
+ #include  
+ #endif
-- 
2.17.1


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


[OpenWrt-Devel] [PATCH 1/2] mdadm: revised mdadm config & init logic

2019-08-02 Thread Rosen Penev
From: Joseph Tingiris 

This is a significant revision of /etc/init.d/mdadm.  It adds new
features, support for new configuration options, safer error
handling, (configurable) verbose output, and contains multiple bug
fixes.

Most notably, mdadm was being started with the --config flag and
that prevented it from using its built in Auto Assembly features.
Users were required to put a correct uuid in /etc/config/mdadm.

The new default startup mode is now to automatically assemble all
RAID arrays attached to the machine using device scans, rather than
configuation options.

A new UCI section, config mdadm global, was added with new options that
are supported by the accompanying /etc/init.d/mdadm. Documentation for all
new (and previous) options was added as well.  See the
/etc/config/mdadmin or mdadm.init file itself for more details.

Additionally, a new stateful 'auto' feature was added that functions
similarly to the stateless Auto Assembly feature.  The benefits of
stateful auto assembly are to support features that mdadm 4.0 will only
read from a configuration file, such as setting the MAILFROM value.  The
new mdadm_conf_auto() function will also aid users in troubleshooting.
When verbose is turned on it provides tips and better visibility for what's
actually happening.

Backward compatibility was retained.  Stateful UCI only configurations are
supported.  All previously existing configurations will work in this mode.
However, these users will now have to explicitly turn it on.

A new reload_service() function was added to prevent reloads from
stopping mdadm.  Reloads will now be ignored, though the stage is set for
reloads to trigger scans for new devices.  Explicit restarts still work as
expected.

The start_service() function was enhanced to query new UCI mdadm.global
options: alert_program, config, email, email_from, monitor_frequency,
and verbose.  Each option is documented in /etc/mdadm/config (config.init) and
some additional code comments were added.

Finally, error handling and verbose output was enhanced.  Users will
know what's going on (if verbose is turned on).

Strict reliance on a shell global ($CONF) was removed and replaced with a
single global ($TMP_FILE) that's for development convenience.  When/if a config
file is not specified in the UCI config, it will fall back to using $TMP_FILE 
as the
configuration file.

Incremented PKG_RELEASE from 1 to 2

Signed-off-by: Joseph Tingiris 
(rebased and ran through shellcheck)
Signed-off-by: Rosen Penev 
---
 package/utils/mdadm/Makefile   |   2 +-
 package/utils/mdadm/files/mdadm.config | 162 ++-
 package/utils/mdadm/files/mdadm.init   | 557 ++---
 3 files changed, 648 insertions(+), 73 deletions(-)

diff --git a/package/utils/mdadm/Makefile b/package/utils/mdadm/Makefile
index 18026bbed2..f20a58b704 100644
--- a/package/utils/mdadm/Makefile
+++ b/package/utils/mdadm/Makefile
@@ -9,7 +9,7 @@ include $(TOPDIR)/rules.mk
 
 PKG_NAME:=mdadm
 PKG_VERSION:=4.1
-PKG_RELEASE:=1
+PKG_RELEASE:=2
 
 PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.xz
 PKG_SOURCE_URL:=@KERNEL/linux/utils/raid/mdadm
diff --git a/package/utils/mdadm/files/mdadm.config 
b/package/utils/mdadm/files/mdadm.config
index 50afbc2ab6..0c78c964a8 100644
--- a/package/utils/mdadm/files/mdadm.config
+++ b/package/utils/mdadm/files/mdadm.config
@@ -1,18 +1,154 @@
-config mdadm
+#
+# The mdadm 'global' section is for options that apply to all sections.
+#
+
+config mdadm global
+
+   #
+   # option 'alert_program' values may be a path to a valid, executable 
binary.
+   #
+   # The default 'alert_program' is not set.
+   #
+   # When mdadm detects an event it will execute this program with 3 
arguments, see https://linux.die.net/man/8/mdadm
+   # $1 = will be the event
+   # $2 = will be the meta device
+   # $3 = may be a related component (if one exists)
+   #
+   # * alert_program runs independently from sendmail.
+   # * If both options alert_program and email are set, and both work, 
then an email and a
+   #   custom alert will be generated.
+   # * no alert program is included in mdadm 4.0-4.
+   #
+   # Lots of possibilities exist, i.e. scripts for netdata, slack, etc.
+   #
+   #option alert_program /usr/sbin/mdadm_alerts
+
+
+   #
+   # option 'config' values may be one of the following.
+   #
+   # The default 'config' is none (stateless auto assembly).
+   #
+   # auto  - stateful, dynamically generated mdadm.conf via block 
info,
+   # stored in /var/etc/mdadm.conf
+   # containers- stateless, mdadm --assemble --scan 
--config=containers; see https://linux.die.net/man/8/mdadm
+   # none  - stateless, mdadm --assemble --scan --config=none; aka 
'Auto Assembly',
+   # see https://linux.die.net/man/8/mdadm
+   # partition - stateless, mdadm --assemble --scan 
--config=partition; see 

[OpenWrt-Devel] [PATCH v2] procd: add daemon mode and remove pid 1 check

2019-08-02 Thread Paul Spooren
Add arg -D to start procd in daemon mode. This allows running procd
directly, not only via /init. Useful for CI environments to start
services like ubus and netifd without needing the whole init process.

To make this work procd also spawns services when running on a different
pid than 1, normal when started via terminal. Before it would only try
to connect to an existing ubus instance.

The -D arg handling was kindly created (with < 60 seconds RTT) by John,
I just created the patch and removed pid checking.

CC: John Crispin 
Signed-off-by: Paul Spooren 
---
v2: added usage/help message

 procd.c | 11 ++-
 1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/procd.c b/procd.c
index 3de6208..aaef4fe 100644
--- a/procd.c
+++ b/procd.c
@@ -35,6 +35,7 @@ static int usage(const char *prog)
"   -hrun as hotplug daemon\n"
"   -d   Enable debug messages\n"
"   -S  Print messages to stdout\n"
+   "   -D  Run procd as daemon process\n"
"\n", prog);
return 1;
 }
@@ -50,7 +51,7 @@ int main(int argc, char **argv)
unsetenv("DBGLVL");
}
 
-   while ((ch = getopt(argc, argv, "d:s:h:S")) != -1) {
+   while ((ch = getopt(argc, argv, "d:s:h:SD")) != -1) {
switch (ch) {
case 'h':
return hotplug_run(optarg);
@@ -63,6 +64,9 @@ int main(int argc, char **argv)
case 'S':
ulog_channels = ULOG_STDIO;
break;
+   case 'D':
+   daemon(1, 1);
+   break;
default:
return usage(argv[0]);
}
@@ -74,10 +78,7 @@ int main(int argc, char **argv)
setsid();
uloop_init();
procd_signal();
-   if (getpid() != 1)
-   procd_connect_ubus();
-   else
-   procd_state_next();
+   procd_state_next();
uloop_run();
uloop_done();
 
-- 
2.20.1


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


Re: [OpenWrt-Devel] [PATCH v2] build: include BUILD_VARIANT in PKG_BUILD_DIR

2019-08-02 Thread Paul Spooren
Hey,

on commit 5e928acf22cdc956eabe6e4b2327b34eb0ee66da applying fails:

error: patch failed: package/libs/ustream-ssl/Makefile:10
error: package/libs/ustream-ssl/Makefile: patch does not apply

However removing the ustream-ssl part of the patch results in a working
version for (at least) all three openvpn variants!

Best,
Paul

On 02.08.19 21:15, Jeffery To wrote:
> On Wed, May 15, 2019 at 8:32 PM Jeffery To  > wrote:
>
> This changes the default PKG_BUILD_DIR to take BUILD_VARIANT into
> account (if set), so that packages do not need to manually override
> PKG_BUILD_DIR just to handle variants.
>
> This also updates most base packages with variants to use the updated
> default PKG_BUILD_DIR.
>
> Signed-off-by: Jeffery To  >
> ---
> v2: updated PKG_BUILD_DIR in include/kernel.mk ,
> removed undefines
>
>
> Can someone take a look at this patch? (I have un-delegated it in
> patchwork.)
>
> Thanks,
> Jeff
>
>
> ___
> 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] ath79: convert devices to interrupt-driven gpio-keys

2019-08-02 Thread Christian Lamparter
On Friday, August 2, 2019 8:03:17 PM CEST Jeff Kletsky wrote:
> 
> On 8/2/19 7:46 AM, Adrian Schmutzler wrote:
> > This converts all remaining devices to use interrupt-driven
> > gpio-keys compatible instead of gpio-keys-polled.
> > The poll-interval is removed.
> >
> 
> Not that this proposed change makes the situation any different, but 
> many devices have switches that are poorly handled by the "key-press" 
> approach.
> 
> One specific case that has bothered me (but not enough to dig into it) 
> is the Archer C7v2 that has an "rfkill" switch. Not only is it 
> "backwards" (label "Off" is really "wireless on"), but it only responds 
> to changes in state, so its state at boot is not respected. You can't, 
> as I recall, set it for "wireless off", plug in the device, and have the 
> wireless be off when OpenWrt boots.
> 
> The GL-AR300M series and the GL-AR750S also have a multi-position "mode" 
> switch.
> 
> Right now, all these switches have to be toggled twice to have their 
> position be properly respected by the OS if they're not in the 
> "expected" position.
> 
> It would seem that, at some point, switches like these would be better 
> served by a driver that can both detect position, as well as transition. 
> This would likely also require a way to poll the position at 
> "impacted-service start" and ubus support along with changes in existing 
> hotplug scripts.

>From playing around with gpio-keys and the openwrt's gpio-button-hotplug.c
in the past few weeks, I think I can tell you what's happening here.
One (there are more) of the problems is that gpio-keys module gets loaded
even before the procd enters its "preinit" phase (the module is part of 
/etc/modules-boot.d/30-gpio-button-hotplug). And the bad news is that
even once procd hits the preinit phase, it intentionally forwards everything
to the failsafe button events script:

|   [ "if",
|   [ "eq", "SUBSYSTEM", "button" ],
|   [ "exec", "/etc/rc.button/failsafe" ]
|  ]



/etc/rc.button/failsafe itself is also very telling:

|#!/bin/sh
|
|[ "${TYPE}" = "switch" ] || echo ${BUTTON} > /tmp/failsafe_button
|
|return 0

The long and short of this is that initial switch state event is
generated but it has no change of getting processed properly
at the time the driver is loaded as the system isn't ready.

Note: If it was loaded later when procd is in the "init" phase,
then it works because events are then processed by hotplug.json,
which does:
 
[ "if",
[ "and",
[ "has", "BUTTON" ],
[ "eq", "SUBSYSTEM", "button" ]
],
[ "button", "/etc/rc.button/%BUTTON%" ]
],



Then everything would work as you expect.
so, it's not the driver that lets you down here, because it can't
do much about these userspace antics.

(Note: OpenWrt's gpio-button-hotplug.c uses the BUTTON subsystem
event type for both EV_KEY (button) and EV_SW (switches) events.
So don't let this confuse you).

Regards,
Christian



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


Re: [OpenWrt-Devel] [PATCH 1/2] base-files: make USE_PROCD=1 default

2019-08-02 Thread John Crispin

Hi,

ignoring the ranting and putting  the enlightening philantrophic 
comments aside, on a pure technical level, being the author of procd, I 
dont think this is a good idea. procd is an opt-in feature for those 
that want to use it. there has never been a requirement to make it 
baseline. USE_PROCD=1 is only intended for the owrt specific core 
services that want to make use of the advanced features. owrt is a linux 
system and thus should by default be able to run SYSV init style rc.d 
scripts. anything else would be a very daring thing to do. To be honest 
I dont even understand the motivation of wanting to make this opt-out.


    John

On 02/08/2019 18:38, Reiner Karlsberg wrote:
Although not a developer of openwrt itself, but a happy (?) user, I 
have to agree to the statement below.


PROCD=1 default is a NOGO for me.

Simple reason,as mentioned already: Software, which is not documented, 
does not exist.
Which is a requirement, we had to obey to already half a century ago. 
When I wrote my first Assembler code.


For me, this is another step of openwrt into bloatware, as it becomes 
more and more "obfuscated",

the simple user like me not giving any idea, how it is supposed to work.

Which breaks another old principle of software development: Egoless 
programming.

Not only the coder should understand, how it works.

Open Source is heading into Closed Source.
Back to the roots.


My few cents.

Reiner Karlsberg







Am 02.08.2019 um 18:18 schrieb Kevin 'ldir' Darbyshire-Bryant:




On 2 Aug 2019, at 16:00, Hannu Nyman  wrote:

Hauke Mehrtens kirjoitti 2.8.2019 klo 17.42:

On 7/23/19 3:37 PM, Petr Štetiar wrote:

Transition period for init script migration was long enough, let's
make USE_PROCD=1 default now so there's enough time to convert the
remaining services/init scripts for the next release.

Signed-off-by: Petr Štetiar 
---
  package/base-files/files/etc/rc.common | 113 
++---

  1 file changed, 47 insertions(+), 66 deletions(-)


Do you know how many packages in the package feed and the main
repository are still not using procd?

External repositories, not the package feed, will probably be affected
most, but I think we do not have to care and there were many years to
convert.

Acked-by: Hauke Mehrtens 

Hauke



I do not remember seeing ever a general call for converting the old 
packages to using procd. In that sense this proposed change to 
switch the default comes a bit surpise.


Quick search in the packages feed repo reveals that there are 281 
instances of "/etc/rc.common" and only 205 instances of USE_PROCD. 
So, likely about 75 packages in the packages feed repo only are 
using the old syntax without procd.


Has a decision been made to declare the old-style init file invalid? 
Will it be possible to still use the syntax? What is the new 
"override" to indicate the usage of the old syntax?


Or will the proposed change disable the packages using the old init 
file syntax totally?


My reading of the change is that old syntax is basically dropped.

Wish for:  We should be using procd and to that end I started looking 
at converting the ‘important to me’ packages: ddns & miniupnpd.


Real life: Documentation is confusing vs real life which is just 
plain different. See adblock startup script as an excellent example 
of  that just isn’t documented.


I gave up and left the process feeling very angry.


KDB


___
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: [OpenWrt-Devel] [PATCH v2] build: include BUILD_VARIANT in PKG_BUILD_DIR

2019-08-02 Thread Jeffery To
On Wed, May 15, 2019 at 8:32 PM Jeffery To  wrote:

> This changes the default PKG_BUILD_DIR to take BUILD_VARIANT into
> account (if set), so that packages do not need to manually override
> PKG_BUILD_DIR just to handle variants.
>
> This also updates most base packages with variants to use the updated
> default PKG_BUILD_DIR.
>
> Signed-off-by: Jeffery To 
> ---
> v2: updated PKG_BUILD_DIR in include/kernel.mk, removed undefines
>

Can someone take a look at this patch? (I have un-delegated it in
patchwork.)

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


Re: [OpenWrt-Devel] Cryptodev-linux compile error with armvirt-64 sdk

2019-08-02 Thread Jeffery To
On Fri, Aug 2, 2019 at 3:16 AM Petr Štetiar  wrote:

> Jeffery To  [2019-08-02 02:04:23]:
>
> > I believe this started after a459d237 (this added
> CONFIG_ARM64_MODULE_PLTS=y
>
> that config symbol is selected by ARM64_ERRATUM_843419 ("Cortex-A53:
> 843419: A
> load or store might access an incorrect address"), so probably the fix
> would
> be to bundle that linker script into SDK (target/sdk/Makefile).
>

Thanks for the pointer - I've sent the patch (
https://patchwork.ozlabs.org/patch/1141354/).

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


[OpenWrt-Devel] [PATCH] sdk: Fix cryptodev-linux build when CONFIG_ARM64_MODULE_PLTS=y

2019-08-02 Thread Jeffery To
When CONFIG_ARM64_MODULE_PLTS=y, arch/arm64/kernel/module.lds is
required to build cryptodev-linux. This updates the sdk to include this
file.

Signed-off-by: Jeffery To 
---
 target/sdk/Makefile | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/target/sdk/Makefile b/target/sdk/Makefile
index 3b860db93a..0bed666d21 100644
--- a/target/sdk/Makefile
+++ b/target/sdk/Makefile
@@ -64,7 +64,8 @@ KERNEL_FILES_ARCH = \
include \
*/include \
scripts \
-   kernel/asm-offsets.s
+   kernel/asm-offsets.s \
+   kernel/module.lds
 
 KERNEL_FILES_BASE := \
.config \
-- 
2.20.1


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


Re: [OpenWrt-Devel] [PATCH] ath79: convert devices to interrupt-driven gpio-keys

2019-08-02 Thread Michal Cieslakiewicz
On Fri,  2 Aug 2019 16:46:10 +0200
Adrian Schmutzler  wrote:

> This converts all remaining devices to use interrupt-driven
> gpio-keys compatible instead of gpio-keys-polled.
> The poll-interval is removed.
> 
> Signed-off-by: Adrian Schmutzler 
> ---
> [...]
> diff --git a/target/linux/ath79/dts/ar7240_netgear_wnr612-v2.dtsi
> b/target/linux/ath79/dts/ar7240_netgear_wnr612-v2.dtsi index
> 8e934429a3..7b5f0ca70b 100644 ---
> a/target/linux/ath79/dts/ar7240_netgear_wnr612-v2.dtsi +++
> b/target/linux/ath79/dts/ar7240_netgear_wnr612-v2.dtsi @@ -15,8 +15,7
> @@ };
>  
>   keys {
> - compatible = "gpio-keys-polled";
> - poll-interval = <20>;
> + compatible = "gpio-keys";
>  
>   reset {
>   label = "reset";
> [...]

Hello all,

Please clarify the scope of above change - AFAIK there is no GPIO IRQ
for wireless chips (or please correct me if I am utterly wrong), hence
ath9k-connected buttons will not work with this setting.

I've built an ath79 image for Netgear WNR612v2 with this patch applied
and indeed, at startup it gives an error:

gpio-keys keys: failed to get irq for gpio:507

which points to reset button wired to ar9285 at pin 7. As expected
with this sort of problem, reset button does not trigger any action at
all.

Currently I'm porting some older WNR* routers to DTS and ath79, most of
them have all or at least some buttons wired to wireless chip, so I
would like to see your opinion on following:

0. Buttons for ath9k-phy GPIOs should remain polled.
1. If above is true and we want to use mixed (irq/polled) configuration,
maybe it is advisable to split DTS definitions into 'keys' and
'ath9k-keys', identical to LEDs setup.
2. Or alternatively, because we need to poll ath9k GPIO pins
anyway, we keep all buttons in polled section.

Cheers
Micu

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


Re: [OpenWrt-Devel] Why ath79 has been made source-only on 19.07?

2019-08-02 Thread Vincent Wiemann
I remember it was decided that:
1. 19.07 will be the last release where image generation is turned on for 
ar71xx (oldstable-style).
2. Because of that nor more pull-requests for ar71xx were accepted but fixes.
3. 19.07 will be the last release where image generation is turned on for tiny 
devices
   and 32 MB RAM devices.
4. Pull-requests for Tiny ath79 devices will still be accepted if they're clean.
5. There will be no kernel updates for ar71xx (which was later withdrawn), 
because
   the next release should contain ath79 and people should be emphasized to 
port them to ath79

So now you have emphasized people to port devices to ath79 and you've even 
stopped them from
working on ar71xx more than once and now you want to release the next stable 
version only with something
that nobody was allowed to do maintenance on/which is basically 18.06 with a 
slightly newer kernel?
This does not make sense. For most people it was clear, that 19.07 will have 
images for ar71xx and ath79.

Regards,

Vincent Wiemann

On 30.07.19 21:40, James Campbell wrote:
> Can we not have a way of including unstable stuff in a way the consumers know 
> it’s un stable ?
> 
> Like a 19.07 canary 
> 
> On Tue, 30 Jul 2019 at 20:22, Andreas Ziegler  > wrote:
> 
> 
> Dmitry Tunin schrieb am 30.07.19 um 14:29:
> > Are you taking in account that many devices added during the last year
> > as ath79 won't be supported by a stable release.
> > Master is no good now for normal use. That will mean that for the next
> > year or so many users will require custom 19.07 builds.
> > That doesn't sound very good.
> >
> > Initially ath79 was expected in 19.07, but it appeared that not all
> > devices have been ported from ar71xx. So we are not ready to drop
> > ar71xx, but we are ready to support ath79.
> 
> to me, this is the only big negative thing here.
> everyone was told, that new devices have to go into ath79 - and now we
> will have a new release, lacking binaries for many many new devices
> because new device support in ar71xx was not welcome.
> 
> ___
> 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: [OpenWrt-Devel] [PATCH] ath79: convert devices to interrupt-driven gpio-keys

2019-08-02 Thread Jeff Kletsky



On 8/2/19 7:46 AM, Adrian Schmutzler wrote:

This converts all remaining devices to use interrupt-driven
gpio-keys compatible instead of gpio-keys-polled.
The poll-interval is removed.



Not that this proposed change makes the situation any different, but 
many devices have switches that are poorly handled by the "key-press" 
approach.


One specific case that has bothered me (but not enough to dig into it) 
is the Archer C7v2 that has an "rfkill" switch. Not only is it 
"backwards" (label "Off" is really "wireless on"), but it only responds 
to changes in state, so its state at boot is not respected. You can't, 
as I recall, set it for "wireless off", plug in the device, and have the 
wireless be off when OpenWrt boots.


The GL-AR300M series and the GL-AR750S also have a multi-position "mode" 
switch.


Right now, all these switches have to be toggled twice to have their 
position be properly respected by the OS if they're not in the 
"expected" position.


It would seem that, at some point, switches like these would be better 
served by a driver that can both detect position, as well as transition. 
This would likely also require a way to poll the position at 
"impacted-service start" and ubus support along with changes in existing 
hotplug scripts.



Jeff



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


Re: [OpenWrt-Devel] [PATCH] ath79: convert devices to interrupt-driven gpio-keys

2019-08-02 Thread Dmitry Tunin
пт, 2 авг. 2019 г. в 17:46, Adrian Schmutzler :
>
> This converts all remaining devices to use interrupt-driven
> gpio-keys compatible instead of gpio-keys-polled.
> The poll-interval is removed.
>

When I ported DIR-825-b1 to ath79 last year, "gpio-keys" where very
unreliable and I had to switch to "gpio-keys-polled".
I didn't test it since. I'll be able to test only next week.

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


Re: [OpenWrt-Devel] [PATCH 1/2] base-files: make USE_PROCD=1 default

2019-08-02 Thread Reiner Karlsberg

Although not a developer of openwrt itself, but a happy (?) user, I have to 
agree to the statement below.

PROCD=1 default is a NOGO for me.

Simple reason,as mentioned already: Software, which is not documented, does not 
exist.
Which is a requirement, we had to obey to already half a century ago. When I 
wrote my first Assembler code.

For me, this is another step of openwrt into bloatware, as it becomes more and more 
"obfuscated",
the simple user like me not giving any idea, how it is supposed to work.

Which breaks another old principle of software development: Egoless programming.
Not only the coder should understand, how it works.

Open Source is heading into Closed Source.
Back to the roots.


My few cents.

Reiner Karlsberg







Am 02.08.2019 um 18:18 schrieb Kevin 'ldir' Darbyshire-Bryant:




On 2 Aug 2019, at 16:00, Hannu Nyman  wrote:

Hauke Mehrtens kirjoitti 2.8.2019 klo 17.42:

On 7/23/19 3:37 PM, Petr Štetiar wrote:

Transition period for init script migration was long enough, let's
make USE_PROCD=1 default now so there's enough time to convert the
remaining services/init scripts for the next release.

Signed-off-by: Petr Štetiar 
---
  package/base-files/files/etc/rc.common | 113 ++---
  1 file changed, 47 insertions(+), 66 deletions(-)


Do you know how many packages in the package feed and the main
repository are still not using procd?

External repositories, not the package feed, will probably be affected
most, but I think we do not have to care and there were many years to
convert.

Acked-by: Hauke Mehrtens 

Hauke



I do not remember seeing ever a general call for converting the old packages to 
using procd. In that sense this proposed change to switch the default comes a 
bit surpise.

Quick search in the packages feed repo reveals that there are 281 instances of 
"/etc/rc.common" and only 205 instances of USE_PROCD. So, likely about 75 
packages in the packages feed repo only are using the old syntax without procd.

Has a decision been made to declare the old-style init file invalid? Will it be possible 
to still use the syntax? What is the new "override" to indicate the usage of 
the old syntax?

Or will the proposed change disable the packages using the old init file syntax 
totally?


My reading of the change is that old syntax is basically dropped.

Wish for:  We should be using procd and to that end I started looking at converting 
the ‘important to me’ packages: ddns & miniupnpd.

Real life: Documentation is confusing vs real life which is just plain 
different. See adblock startup script as an excellent example of  that just 
isn’t documented.

I gave up and left the process feeling very angry.


KDB


___
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] Memory leak related to OpenWrt patch of hostapd

2019-08-02 Thread Nick Schaf



> Nick Schaf  [2019-07-31 16:34:36]:
> 
> Hi,
> 
> > I've noticed the wpa_supplicant process on my mesh interfaces leaking
> > memory to the point that the kernel kills the process.  It was
> > discovered in 18.06.2, but I've reproduced it with 18.06.4 and with
> > the master branch from the GitHub repo.  Since the leak occurs as mesh
> > links are created and destroyed, I was able to reproduce it with a
> > simple two-node setup where I monitor the wpa_supplicant process VSZ
> > on one node and repeatedly bring wifi up and down on the other node.
> >
> > I've traced it back to the 18.06.2 release, specifically to lines
> > 34-35 of
> > package/network/services/hostapd/patches/015-mesh-do-not-use-
> offchan-m
> > gmt-tx-on-DFS.patch
> > + (modes = nl80211_get_hw_feature_data(bss,
> > + _modes,
> > , +
> > _domain)) && That code was added in
> > a35f24309021c1c0e9cbed0faedf58b941cb4bd3.
> >
> > I removed the entire patch file to resolve the memory leak because the
> > subsequent call to ieee80211_is_dfs() uses the return value from
> > nl80211_get_hw_feature_data().  However, I know the problem is
> > specifically related to the nl80211_get_hw_feature_data() call because
> > I stepped-backward through commits of the hostapd source until I got
> > back to 0f7fc6b98de9c69f511b9b22f2b65553126362eb, where
> > ieee80211_is_dfs() had only one argument and didn't rely on the
> > nl80211_get_hw_feature_data() return value.  At that point, the memory
> > leak still occurred until I commented-out the call to
> nl80211_get_hw_feature_data().
> >
> > I attempted to dive into nl80211_get_hw_feature_data(), but was
> > quickly lost, so I defer to those that are more experienced in that code.
> 
> you did a nice job here to track it down, so thanks for reporting this, can 
> you
> try this patch[1]?
> 

I had already tried an os_free(modes) and found no resolution.  However, to be 
sure, I tried your patch today and still observe the leak, but also checked 
original code to determine whether the leak rate reduced with the patch.  From 
that test (data below) it seems possible that the modes leak I might be a small 
portion of the overall leak I observed.
I still suspect the main leak to be somewhere inside 
nl80211_get_hw_feature_data.

For your reference, data from today's quick test is below.  VSZ is "VmSize" 
from /proc/[PID]/status where PID=wpa_supplicant's process ID.  Unpatched is 
the clean 18.06.4 code.  Patched is the same with your patch applied.
The other node cycles the connection ~ every 30 seconds (while [ 1 ]; do wifi 
down; sleep 10; wifi; sleep 20; done).
We don't see a rise in memory every 30 seconds, leading me to believe the 
leaked memory was allocated from a memory pool and the pool size needs to be 
periodically increased as the leak continues.

Time (s),VSZ unpatched,VSZ patched
0,3408,3404
10,3408,3408
20,3408,3416
30,3408,3416
40,3408,3420
50,3408,3440
60,3408,3440
70,3412,3440
80,3432,3440
90,3432,3440
100,3432,3440
110,3432,3464
120,3432,3464
130,3432,3464
140,3432,3464
150,3432,3464
160,3436,3464
170,3456,3464
180,3456,3464
190,3456,3464
200,3456,3464
210,3456,3464
220,3460,3464
230,3480,3468
,,3468
,,3468
,,3472
,,3472
,,3472
,,3496

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


Re: [OpenWrt-Devel] [PATCH 1/2] base-files: make USE_PROCD=1 default

2019-08-02 Thread Kevin 'ldir' Darbyshire-Bryant


> On 2 Aug 2019, at 16:00, Hannu Nyman  wrote:
> 
> Hauke Mehrtens kirjoitti 2.8.2019 klo 17.42:
>> On 7/23/19 3:37 PM, Petr Štetiar wrote:
>>> Transition period for init script migration was long enough, let's
>>> make USE_PROCD=1 default now so there's enough time to convert the
>>> remaining services/init scripts for the next release.
>>> 
>>> Signed-off-by: Petr Štetiar 
>>> ---
>>>  package/base-files/files/etc/rc.common | 113 ++---
>>>  1 file changed, 47 insertions(+), 66 deletions(-)
>>> 
>> Do you know how many packages in the package feed and the main
>> repository are still not using procd?
>> 
>> External repositories, not the package feed, will probably be affected
>> most, but I think we do not have to care and there were many years to
>> convert.
>> 
>> Acked-by: Hauke Mehrtens 
>> 
>> Hauke
>> 
> 
> I do not remember seeing ever a general call for converting the old packages 
> to using procd. In that sense this proposed change to switch the default 
> comes a bit surpise.
> 
> Quick search in the packages feed repo reveals that there are 281 instances 
> of "/etc/rc.common" and only 205 instances of USE_PROCD. So, likely about 75 
> packages in the packages feed repo only are using the old syntax without 
> procd.
> 
> Has a decision been made to declare the old-style init file invalid? Will it 
> be possible to still use the syntax? What is the new "override" to indicate 
> the usage of the old syntax?
> 
> Or will the proposed change disable the packages using the old init file 
> syntax totally?

My reading of the change is that old syntax is basically dropped.

Wish for:  We should be using procd and to that end I started looking at 
converting the ‘important to me’ packages: ddns & miniupnpd.

Real life: Documentation is confusing vs real life which is just plain 
different. See adblock startup script as an excellent example of  that just 
isn’t documented.

I gave up and left the process feeling very angry.


KDB


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


[OpenWrt-Devel] [PATCH] ar71xx: WNR2200: remove redundant GPIO for WLAN LED

2019-08-02 Thread Michal Cieslakiewicz
Without this patch, an extra entry appears for AR9287 GPIO
that duplicates WLAN LED but in fact drives nothing:

gpiochip1: GPIOs 502-511, ath9k-phy0:
 gpio-502 (|netgear:blue:wlan   ) out hi
 gpio-503 (|netgear:amber:test  ) out hi
 gpio-504 (|netgear:green:power ) out lo
 gpio-505 (|rfkill  ) in  hi
 gpio-507 (|wps ) in  hi
 gpio-508 (|reset   ) in  hi
 gpio-510 (|ath9k-phy0  ) out hi <===!

The pin pointed above is default LED GPIO (8) for AR9287.
For WNR2200 it is not connected anywhere - pin 0 drives blue WLAN
LED instead - but initialization code is missing that information.

This fix calls ap9x_pci_setup_wmac_led_pin() function at device
setup, forcing WLAN LED pin to be 0 and removing redundant entry.

Signed-off-by: Michal Cieslakiewicz 
---
 target/linux/ar71xx/files/arch/mips/ath79/mach-wnr2200.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/target/linux/ar71xx/files/arch/mips/ath79/mach-wnr2200.c 
b/target/linux/ar71xx/files/arch/mips/ath79/mach-wnr2200.c
index 54217220f7..74166c5376 100644
--- a/target/linux/ar71xx/files/arch/mips/ath79/mach-wnr2200.c
+++ b/target/linux/ar71xx/files/arch/mips/ath79/mach-wnr2200.c
@@ -222,6 +222,7 @@ static void __init wnr2200_setup(void)
 
wnr2200_get_wmac(wlan_mac_addr, WNR2200_MAC0_OFFSET,
 WNR2200_MAC1_OFFSET, WNR2200_WMAC_OFFSET);
+   ap9x_pci_setup_wmac_led_pin(0, 0);
ap91_pci_init(art + WNR2200_PCIE_CALDATA_OFFSET, wlan_mac_addr);
 
ath79_register_leds_gpio(-1, ARRAY_SIZE(wnr2200_leds_gpio),
-- 
2.22.0

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


Re: [OpenWrt-Devel] package mt76 fails to compile under certain configuration [Was: Compilation error on master / mt7620]

2019-08-02 Thread Joan Moreau 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 ---

Additionally, I get the following error in the image generated (master)
without the debugfs option then to allow compilation 


[ 8.936247] jffs2: Error: unknown compressor "zlib"
[ 8.941939] mount_root: failed to mount -t jffs2 /dev/mtdblock6
/tmp/overlay: Invalid argument
[ 8.951033] mount_root: overlay filesystem has not been fully
initialized yet
[ 8.958979] mount_root: switching to jffs2 overlay
[ 8.964114] mount_root: switching to jffs2 failed - fallback to
ramoverlay

On 2019-08-02 21:37, Joan Moreau wrote:

Removing "debug fs" in compilation options removes the problem. 

So there is something very awkward in the Makefile 

On 2019-08-02 20:28, Joan Moreau wrote: 


attached

On 2019-08-02 18:36, Petr Štetiar wrote: 
Joan Moreau via openwrt-devel  [2019-08-02 07:56:41]:


Hello,

I reach the following error while compiling my MT7620/ZBT826-16M on
master (no error on 18.06) :

CC [M]
/usr/src/openwrt/4g/build_dir/target-mipsel_24kc_musl/linux-ramips_mt7620/mt76-2019-07-22-75656a45/mt7603/pci.o
:0:37: error: redeclaration of enumerator
'IEEE80211_HW_REPORTS_TX_ACK_STATUS'
:0:37: note: in definition of macro
'IEEE80211_HW_TX_STATUS_NO_AMPDU_LEN'
In file included from
/usr/src/openwrt/4g/build_dir/target-mipsel_24kc_musl/linux-ramips_mt7620/mt76-2019-07-22-75656a45/mt7603/../mt76.h:27:0,
from
/usr/src/openwrt/4g/build_dir/target-mipsel_24kc_musl/linux-ramips_mt7620/mt76-2019-07-22-75656a45/mt7603/mt7603.h:8,
from
/usr/src/openwrt/4g/build_dir/target-mipsel_24kc_musl/linux-ramips_mt7620/mt76-2019-07-22-75656a45/mt7603/pci.c:7:
/usr/src/openwrt/4g/staging_dir/target-mipsel_24kc_musl/usr/include/mac80211/net/mac80211.h:2293:2:
note: previous definition of 'IEEE80211_HW_REPORTS_TX_ACK_STATUS' was
here
IEEE80211_HW_REPORTS_TX_ACK_STATUS,
^~
make[6]: *** [scripts/Makefile.build:327:
/usr/src/openwrt/4g/build_dir/target-mipsel_24kc_musl/linux-ramips_mt7620/mt76-2019-07-22-75656a45/mt7603/pci.o]
Error 1
make[5]: *** [scripts/Makefile.build:585:
/usr/src/openwrt/4g/build_dir/target-mipsel_24kc_musl/linux-ramips_mt7620/mt76-2019-07-22-75656a45/mt7603]
Error 2
make[4]: *** [Makefile:1532:
_module_/usr/src/openwrt/4g/build_dir/target-mipsel_24kc_musl/linux-ramips_mt7620/mt76-2019-07-22-75656a45]
Error 2

Can you help ? 
the problem is probably in this compile check[1], so please do following:


make package/mt76/{clean,prepare}
sed -i 's;TMP";TMP" 2> $(TOPDIR)/meh.log;' build_dir/target-mipsel_24kc_musl/linux-ramips_mt7620/mt76-2019-07-22-75656a45/mt7603/Makefile 
make package/mt76/compile

scripts/diffconfig.sh >> meh.log; gzip meh.log

and send meh.log.gz file as attachment.

1. https://github.com/openwrt/mt76/blob/master/mt7603/Makefile#L7

-- ynezz

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


Re: [OpenWrt-Devel] [PATCH 1/2] base-files: make USE_PROCD=1 default

2019-08-02 Thread Hannu Nyman

Hauke Mehrtens kirjoitti 2.8.2019 klo 17.42:

On 7/23/19 3:37 PM, Petr Štetiar wrote:

Transition period for init script migration was long enough, let's
make USE_PROCD=1 default now so there's enough time to convert the
remaining services/init scripts for the next release.

Signed-off-by: Petr Štetiar 
---
  package/base-files/files/etc/rc.common | 113 ++---
  1 file changed, 47 insertions(+), 66 deletions(-)


Do you know how many packages in the package feed and the main
repository are still not using procd?

External repositories, not the package feed, will probably be affected
most, but I think we do not have to care and there were many years to
convert.

Acked-by: Hauke Mehrtens 

Hauke



I do not remember seeing ever a general call for converting the old packages 
to using procd. In that sense this proposed change to switch the default 
comes a bit surpise.


Quick search in the packages feed repo reveals that there are 281 instances 
of "/etc/rc.common" and only 205 instances of USE_PROCD. So, likely about 75 
packages in the packages feed repo only are using the old syntax without procd.


Has a decision been made to declare the old-style init file invalid? Will it 
be possible to still use the syntax? What is the new "override" to indicate 
the usage of the old syntax?


Or will the proposed change disable the packages using the old init file 
syntax totally?




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


Re: [OpenWrt-Devel] [PATCH] ath79: convert devices to interrupt-driven gpio-keys

2019-08-02 Thread Adrian Schmutzler
Anything speaking against doing the same for ramips mt7620a, mt7621, mt7628?

> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org] On
> Behalf Of Adrian Schmutzler
> Sent: Freitag, 2. August 2019 16:46
> To: openwrt-devel@lists.openwrt.org
> Subject: [OpenWrt-Devel] [PATCH] ath79: convert devices to interrupt-driven
> gpio-keys
> 
> This converts all remaining devices to use interrupt-driven
> gpio-keys compatible instead of gpio-keys-polled.
> The poll-interval is removed.
> 
> Signed-off-by: Adrian Schmutzler 
> ---
>  target/linux/ath79/dts/ar1022_iodata_wn-ag300dgr.dts | 3 +--
>  target/linux/ath79/dts/ar7161_buffalo_wzr-hp-ag300h.dts  | 3 +--
>  target/linux/ath79/dts/ar7161_dlink_dir-825-b1.dts   | 3 +--
>  target/linux/ath79/dts/ar7161_jjplus_ja76pf2.dts | 3 +--
>  target/linux/ath79/dts/ar7161_ubnt_routerstation.dtsi| 3 +--
>  target/linux/ath79/dts/ar7240_buffalo_whr-g301n.dts  | 3 +--
>  target/linux/ath79/dts/ar7240_netgear_wnr612-v2.dtsi | 3 +--
>  target/linux/ath79/dts/ar7240_tplink_tl-wr74xn-v1.dtsi   | 3 +--
>  target/linux/ath79/dts/ar7241_tplink.dtsi| 3 +--
>  target/linux/ath79/dts/ar7241_tplink_tl-wr842n-v1.dts| 3 +--
>  target/linux/ath79/dts/ar7241_ubnt_unifi.dts | 4 ++--
>  target/linux/ath79/dts/ar7241_ubnt_xm.dtsi   | 4 ++--
>  target/linux/ath79/dts/ar7242_avm_fritz300e.dts  | 3 +--
>  target/linux/ath79/dts/ar7242_buffalo_wzr-bhr.dtsi   | 3 +--
>  target/linux/ath79/dts/ar7242_buffalo_wzr-hp-g302h-a1a0.dts  | 3 +--
>  target/linux/ath79/dts/ar7242_tplink_tl-wr2543-v1.dts| 3 +--
>  target/linux/ath79/dts/ar9330_glinet_gl-ar150.dts| 3 +--
>  target/linux/ath79/dts/ar9330_pqi_air-pen.dts| 3 +--
>  target/linux/ath79/dts/ar9331_embeddedwireless_dorin.dts | 3 +--
>  target/linux/ath79/dts/ar9331_etactica_eg200.dts | 3 +--
>  target/linux/ath79/dts/ar9331_pisen_wmm003n.dts  | 3 +--
>  target/linux/ath79/dts/ar9331_tplink_tl-mr3040-v2.dts| 3 +--
>  target/linux/ath79/dts/ar9331_tplink_tl-wr703n_tl-mr10u.dtsi | 3 +--
>  target/linux/ath79/dts/ar9331_tplink_tl-wr710n-v1.dts| 3 +--
>  target/linux/ath79/dts/ar9331_tplink_tl-wr741nd-v4.dtsi  | 3 +--
>  target/linux/ath79/dts/ar9341_pcs_cr3000.dts | 3 +--
>  target/linux/ath79/dts/ar9341_tplink_tl-wr841-v8.dts | 3 +--
>  target/linux/ath79/dts/ar9341_tplink_tl-wr842n-v2.dts| 3 +--
>  target/linux/ath79/dts/ar9342_iodata_etg3-r.dts  | 3 +--
>  target/linux/ath79/dts/ar9344_comfast_cf-e120a-v3.dts| 3 +--
>  target/linux/ath79/dts/ar9344_ocedo_raccoon.dts  | 3 +--
>  target/linux/ath79/dts/ar9344_pcs_cap324.dts | 3 +--
>  target/linux/ath79/dts/ar9344_pcs_cr5000.dts | 3 +--
>  target/linux/ath79/dts/ar9344_tplink_tl-wdr4300.dtsi | 3 +--
>  target/linux/ath79/dts/ar9344_winchannel_wb2000.dts  | 3 +--
>  target/linux/ath79/dts/qca9531_comfast_cf-e5.dts | 3 +--
>  target/linux/ath79/dts/qca9531_engenius_ews511ap.dts | 3 +--
>  target/linux/ath79/dts/qca9531_glinet_gl-ar300m.dtsi | 4 ++--
>  target/linux/ath79/dts/qca9531_glinet_gl-x750.dts| 3 +--
>  target/linux/ath79/dts/qca9533_comfast_cf-e110n-v2.dts   | 3 +--
>  target/linux/ath79/dts/qca9533_tplink_cpe210.dtsi| 3 +--
>  target/linux/ath79/dts/qca9557_buffalo_bhr-4grv2.dts | 3 +--
>  target/linux/ath79/dts/qca9557_iodata_wn-ac-dgr.dtsi | 3 +--
>  target/linux/ath79/dts/qca9558_engenius_epg5000.dts  | 3 +--
>  target/linux/ath79/dts/qca9558_ocedo_koala.dts   | 3 +--
>  target/linux/ath79/dts/qca9558_openmesh_om5p-ac-v2.dts   | 3 +--
>  target/linux/ath79/dts/qca9561_avm_fritz4020.dts | 3 +--
>  target/linux/ath79/dts/qca9561_tplink_archer-c5x.dtsi| 3 +--
>  target/linux/ath79/dts/qca9561_xiaomi_mi-router-4q.dts   | 3 +--
>  target/linux/ath79/dts/qca9563_dlink_dir-859-a1.dts  | 3 +--
>  target/linux/ath79/dts/qca9563_glinet_gl-ar750s.dts  | 4 ++--
>  target/linux/ath79/dts/qca9563_phicomm_k2t.dts   | 3 +--
>  52 files changed, 56 insertions(+), 104 deletions(-)
> 
> diff --git a/target/linux/ath79/dts/ar1022_iodata_wn-ag300dgr.dts
> b/target/linux/ath79/dts/ar1022_iodata_wn-ag300dgr.dts
> index 5ad8196a15..64f471649e 100644
> --- a/target/linux/ath79/dts/ar1022_iodata_wn-ag300dgr.dts
> +++ b/target/linux/ath79/dts/ar1022_iodata_wn-ag300dgr.dts
> @@ -55,8 +55,7 @@
>   };
> 
>   keys {
> - compatible = "gpio-keys-polled";
> - poll-interval = <20>;
> + compatible = "gpio-keys";
> 
>   eco {
>   label = "eco";
> diff --git a/target/linux/ath79/dts/ar7161_buffalo_wzr-hp-ag300h.dts
> 

[OpenWrt-Devel] [PATCH] ath79: convert devices to interrupt-driven gpio-keys

2019-08-02 Thread Adrian Schmutzler
This converts all remaining devices to use interrupt-driven
gpio-keys compatible instead of gpio-keys-polled.
The poll-interval is removed.

Signed-off-by: Adrian Schmutzler 
---
 target/linux/ath79/dts/ar1022_iodata_wn-ag300dgr.dts | 3 +--
 target/linux/ath79/dts/ar7161_buffalo_wzr-hp-ag300h.dts  | 3 +--
 target/linux/ath79/dts/ar7161_dlink_dir-825-b1.dts   | 3 +--
 target/linux/ath79/dts/ar7161_jjplus_ja76pf2.dts | 3 +--
 target/linux/ath79/dts/ar7161_ubnt_routerstation.dtsi| 3 +--
 target/linux/ath79/dts/ar7240_buffalo_whr-g301n.dts  | 3 +--
 target/linux/ath79/dts/ar7240_netgear_wnr612-v2.dtsi | 3 +--
 target/linux/ath79/dts/ar7240_tplink_tl-wr74xn-v1.dtsi   | 3 +--
 target/linux/ath79/dts/ar7241_tplink.dtsi| 3 +--
 target/linux/ath79/dts/ar7241_tplink_tl-wr842n-v1.dts| 3 +--
 target/linux/ath79/dts/ar7241_ubnt_unifi.dts | 4 ++--
 target/linux/ath79/dts/ar7241_ubnt_xm.dtsi   | 4 ++--
 target/linux/ath79/dts/ar7242_avm_fritz300e.dts  | 3 +--
 target/linux/ath79/dts/ar7242_buffalo_wzr-bhr.dtsi   | 3 +--
 target/linux/ath79/dts/ar7242_buffalo_wzr-hp-g302h-a1a0.dts  | 3 +--
 target/linux/ath79/dts/ar7242_tplink_tl-wr2543-v1.dts| 3 +--
 target/linux/ath79/dts/ar9330_glinet_gl-ar150.dts| 3 +--
 target/linux/ath79/dts/ar9330_pqi_air-pen.dts| 3 +--
 target/linux/ath79/dts/ar9331_embeddedwireless_dorin.dts | 3 +--
 target/linux/ath79/dts/ar9331_etactica_eg200.dts | 3 +--
 target/linux/ath79/dts/ar9331_pisen_wmm003n.dts  | 3 +--
 target/linux/ath79/dts/ar9331_tplink_tl-mr3040-v2.dts| 3 +--
 target/linux/ath79/dts/ar9331_tplink_tl-wr703n_tl-mr10u.dtsi | 3 +--
 target/linux/ath79/dts/ar9331_tplink_tl-wr710n-v1.dts| 3 +--
 target/linux/ath79/dts/ar9331_tplink_tl-wr741nd-v4.dtsi  | 3 +--
 target/linux/ath79/dts/ar9341_pcs_cr3000.dts | 3 +--
 target/linux/ath79/dts/ar9341_tplink_tl-wr841-v8.dts | 3 +--
 target/linux/ath79/dts/ar9341_tplink_tl-wr842n-v2.dts| 3 +--
 target/linux/ath79/dts/ar9342_iodata_etg3-r.dts  | 3 +--
 target/linux/ath79/dts/ar9344_comfast_cf-e120a-v3.dts| 3 +--
 target/linux/ath79/dts/ar9344_ocedo_raccoon.dts  | 3 +--
 target/linux/ath79/dts/ar9344_pcs_cap324.dts | 3 +--
 target/linux/ath79/dts/ar9344_pcs_cr5000.dts | 3 +--
 target/linux/ath79/dts/ar9344_tplink_tl-wdr4300.dtsi | 3 +--
 target/linux/ath79/dts/ar9344_winchannel_wb2000.dts  | 3 +--
 target/linux/ath79/dts/qca9531_comfast_cf-e5.dts | 3 +--
 target/linux/ath79/dts/qca9531_engenius_ews511ap.dts | 3 +--
 target/linux/ath79/dts/qca9531_glinet_gl-ar300m.dtsi | 4 ++--
 target/linux/ath79/dts/qca9531_glinet_gl-x750.dts| 3 +--
 target/linux/ath79/dts/qca9533_comfast_cf-e110n-v2.dts   | 3 +--
 target/linux/ath79/dts/qca9533_tplink_cpe210.dtsi| 3 +--
 target/linux/ath79/dts/qca9557_buffalo_bhr-4grv2.dts | 3 +--
 target/linux/ath79/dts/qca9557_iodata_wn-ac-dgr.dtsi | 3 +--
 target/linux/ath79/dts/qca9558_engenius_epg5000.dts  | 3 +--
 target/linux/ath79/dts/qca9558_ocedo_koala.dts   | 3 +--
 target/linux/ath79/dts/qca9558_openmesh_om5p-ac-v2.dts   | 3 +--
 target/linux/ath79/dts/qca9561_avm_fritz4020.dts | 3 +--
 target/linux/ath79/dts/qca9561_tplink_archer-c5x.dtsi| 3 +--
 target/linux/ath79/dts/qca9561_xiaomi_mi-router-4q.dts   | 3 +--
 target/linux/ath79/dts/qca9563_dlink_dir-859-a1.dts  | 3 +--
 target/linux/ath79/dts/qca9563_glinet_gl-ar750s.dts  | 4 ++--
 target/linux/ath79/dts/qca9563_phicomm_k2t.dts   | 3 +--
 52 files changed, 56 insertions(+), 104 deletions(-)

diff --git a/target/linux/ath79/dts/ar1022_iodata_wn-ag300dgr.dts 
b/target/linux/ath79/dts/ar1022_iodata_wn-ag300dgr.dts
index 5ad8196a15..64f471649e 100644
--- a/target/linux/ath79/dts/ar1022_iodata_wn-ag300dgr.dts
+++ b/target/linux/ath79/dts/ar1022_iodata_wn-ag300dgr.dts
@@ -55,8 +55,7 @@
};
 
keys {
-   compatible = "gpio-keys-polled";
-   poll-interval = <20>;
+   compatible = "gpio-keys";
 
eco {
label = "eco";
diff --git a/target/linux/ath79/dts/ar7161_buffalo_wzr-hp-ag300h.dts 
b/target/linux/ath79/dts/ar7161_buffalo_wzr-hp-ag300h.dts
index df22eb8dc4..f51bc0f771 100644
--- a/target/linux/ath79/dts/ar7161_buffalo_wzr-hp-ag300h.dts
+++ b/target/linux/ath79/dts/ar7161_buffalo_wzr-hp-ag300h.dts
@@ -81,8 +81,7 @@
};
 
keys {
-   compatible = "gpio-keys-polled";
-   poll-interval = <20>;
+   compatible = "gpio-keys";
 
reset {
linux,code = ;
diff --git a/target/linux/ath79/dts/ar7161_dlink_dir-825-b1.dts 

Re: [OpenWrt-Devel] [PATCH 1/2] base-files: make USE_PROCD=1 default

2019-08-02 Thread Hauke Mehrtens
On 7/23/19 3:37 PM, Petr Štetiar wrote:
> Transition period for init script migration was long enough, let's
> make USE_PROCD=1 default now so there's enough time to convert the
> remaining services/init scripts for the next release.
> 
> Signed-off-by: Petr Štetiar 
> ---
>  package/base-files/files/etc/rc.common | 113 ++---
>  1 file changed, 47 insertions(+), 66 deletions(-)
> 

Do you know how many packages in the package feed and the main
repository are still not using procd?

External repositories, not the package feed, will probably be affected
most, but I think we do not have to care and there were many years to
convert.

Acked-by: Hauke Mehrtens 

Hauke



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] scons: move to packages feed

2019-08-02 Thread Hauke Mehrtens
On 7/28/19 11:31 PM, Petr Štetiar wrote:
> This patch removes scons host build tool, as commit 0c090fde68b2
> ("scons: move host build tool to a proper place") in the packages feed
> has moved scons into the new home.
> 
> There are currently no packages in the master tree which would need
> scons, yet scons is build always as part of host tools, just in order to
> satisfy host build dependency of few packages in the packages feeds.
> 
> Signed-off-by: Petr Štetiar 

Acked-by: Hauke Mehrtens 

> ---
>  tools/Makefile |  2 +-
>  tools/scons/Makefile   | 35 --
>  tools/scons/files/pywrap.sh| 15 --
>  tools/scons/patches/001-platform_env.patch | 11 ---
>  4 files changed, 1 insertion(+), 62 deletions(-)
>  delete mode 100644 tools/scons/Makefile
>  delete mode 100755 tools/scons/files/pywrap.sh
>  delete mode 100644 tools/scons/patches/001-platform_env.patch
> 
> diff --git a/tools/Makefile b/tools/Makefile
> index d7207ba89dd9..a161154b806b 100644
> --- a/tools/Makefile
> +++ b/tools/Makefile
> @@ -25,7 +25,7 @@ tools-$(BUILD_TOOLCHAIN) += gmp mpfr mpc libelf expat
>  tools-y += m4 libtool autoconf automake flex bison pkg-config mklibs zlib
>  tools-y += sstrip make-ext4fs e2fsprogs mtd-utils mkimage
>  tools-y += firmware-utils patch-image quilt padjffs2
> -tools-y += mm-macros missing-macros cmake scons bc findutils gengetopt 
> patchelf
> +tools-y += mm-macros missing-macros cmake bc findutils gengetopt patchelf
>  tools-y += mtools dosfstools libressl
>  tools-$(CONFIG_TARGET_orion_generic) += wrt350nv2-builder upslug2
>  tools-$(CONFIG_TARGET_x86) += qemu
> diff --git a/tools/scons/Makefile b/tools/scons/Makefile
> deleted file mode 100644
> index 5ec655416585..
> --- a/tools/scons/Makefile
> +++ /dev/null
> @@ -1,35 +0,0 @@
> -#
> -# Copyright (C) 2011-2015 OpenWrt.org
> -#
> -# This is free software, licensed under the GNU General Public License v2.
> -# See /LICENSE for more information.
> -#
> -
> -include $(TOPDIR)/rules.mk
> -
> -PKG_NAME:=scons
> -PKG_VERSION:=3.0.5
> -
> -PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.gz
> -PKG_SOURCE_URL:=@SF/scons \
> - http://fossies.org/linux/misc/
> -PKG_HASH:=df676f23dc6d4bfa384fc389d95dcd21ab907e6349d4c848958ba4befb73c73e
> -
> -include $(INCLUDE_DIR)/host-build.mk
> -
> -define Host/Configure
> -endef
> -
> -define Host/Compile
> -endef
> -
> -define Host/Install
> - ./files/pywrap.sh $(HOST_BUILD_DIR)/setup.py install 
> --prefix=$(STAGING_DIR_HOST)
> - rm -f $(STAGING_DIR_HOST)/bin/scons*.py
> - for bin in $(STAGING_DIR_HOST)/bin/scons*; do \
> - mv "bin" "bin.py";\
> - cp ./files/pywrap.sh "bin";   \
> - done
> -endef
> -
> -$(eval $(call HostBuild))
> diff --git a/tools/scons/files/pywrap.sh b/tools/scons/files/pywrap.sh
> deleted file mode 100755
> index 53910e947209..
> --- a/tools/scons/files/pywrap.sh
> +++ /dev/null
> @@ -1,15 +0,0 @@
> -#!/usr/bin/env bash
> -
> -case "${0##*/}" in
> - pywrap.sh) arg1="";;
> - *) arg1="$0.py" ;;
> -esac
> -
> -for bin in python python3; do
> -case "$($bin -V 2>&1)" in
> -"Python 3"*) exec $bin $arg1 "$@" ;;
> -esac
> -done
> -
> -echo "Unable to find a Python 3.x interpreter for executing ${arg1:+$arg1 
> }$@ !" >&2
> -exit 1
> diff --git a/tools/scons/patches/001-platform_env.patch 
> b/tools/scons/patches/001-platform_env.patch
> deleted file mode 100644
> index 2be31470c27d..
> --- a/tools/scons/patches/001-platform_env.patch
> +++ /dev/null
> @@ -1,11 +0,0 @@
>  a/engine/SCons/Platform/__init__.py
> -+++ b/engine/SCons/Platform/__init__.py
> -@@ -65,6 +65,8 @@ def platform_default():
> - care about the machine architecture.
> - """
> - osname = os.name
> -+if 'PLATFORM' in os.environ:
> -+return os.environ['PLATFORM']
> - if osname == 'java':
> - osname = os._osType
> - if osname == 'posix':
> 
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel
> 




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] wireless-regdb: fix build when python2 from package feeds exists

2019-08-02 Thread Hauke Mehrtens
On 7/31/19 10:31 PM, Petr Štetiar wrote:
> wireless-regdb fails to build if there is python2 installed from package
> feeds, as staging_dir/hostpkg/bin/python is python2 and
> staging_dir/hostpkg/bin takes precedence over staging_dir/host/bin
> (proper place with python -> python3 symlink) which leads to the build
> failure of wireless-regdb, so this patch makes it explicit which python
> should be used.
> 
> Reported-by: Hauke Mehrtens 
> Tested-by: Kevin Darbyshire-Bryant 
> Signed-off-by: Petr Štetiar 

Tested-by: Hauke Mehrtens 

> ---
>  package/firmware/wireless-regdb/Makefile | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/package/firmware/wireless-regdb/Makefile 
> b/package/firmware/wireless-regdb/Makefile
> index 88a8d0bd9c3b..26f470af44c4 100644
> --- a/package/firmware/wireless-regdb/Makefile
> +++ b/package/firmware/wireless-regdb/Makefile
> @@ -20,7 +20,7 @@ define Package/wireless-regdb
>  endef
>  
>  define Build/Compile
> - $(PYTHON) $(PKG_BUILD_DIR)/db2fw.py $(PKG_BUILD_DIR)/regulatory.db 
> $(PKG_BUILD_DIR)/db.txt
> + $(STAGING_DIR_HOST)/bin/$(PYTHON) $(PKG_BUILD_DIR)/db2fw.py 
> $(PKG_BUILD_DIR)/regulatory.db $(PKG_BUILD_DIR)/db.txt
>  endef
>  
>  define Package/wireless-regdb/install
> 
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel
> 




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] atomic sleep bugs - 19.07 (and probably Master too)

2019-08-02 Thread Hauke Mehrtens
On 8/2/19 10:40 AM, Koen Vandeputte wrote:
> 
> On 01.08.19 17:27, Koen Vandeputte wrote:
>> Hi All,
>>
>> I've been playing around the last few days stresstesting latest 19.07
>> on different targets (ar71xx, cns3xxx, imx6, ...) with extra kernel
>> debug features enabled.
>>
>> I'll post some results here as maybe somebody has a clue. :)
>>
>>
>> Some interesting splats already showed up, actually also *breaking*
>> some functionality while the board is running:
>>
>> on Mikrotik RB2011 (ar71xx)
>>
>>

..

> 
> [   13.152502] eth0: link down
> [   13.155063] BUG: sleeping function called from invalid context at
> net/core/dev.c:5563
> [   13.161685] in_atomic(): 1, irqs_disabled(): 1, pid: 456, name: ip
> [   13.167848] 2 locks held by ip/456:
> [   13.171315]  #0:  (rtnl_mutex){}, at: [<8032aba4>]
> rtnetlink_rcv_msg+0x2d8/0x380
> [   13.179039]  #1:  (&(>lock)->rlock){}, at: [<802e3c40>]
> ag71xx_hw_disable+0x24/0x94
> [   13.187385] CPU: 0 PID: 456 Comm: ip Not tainted 4.14.134 #0
> [   13.193019] Stack : 805a 80547894 8051de14 831c98ec 805f
> 805f 83918efc 805733a7
> [   13.201348] 80517e44 01c8 805f38bc 831c9ccc 8390d0c0
> 0001 831c98a0 b0502ae3
> [   13.209681]   80ae 831c979c 6138f004
>  0007 
> [   13.218016] 0091 b340 0090  8000
> 839c9d8c 839c9db0 0001
> [   13.226347] 80428b7c 831c9ccc 8390d0c0 83b51210 0003
>   805f
> [   13.234680] ...
> [   13.237114] Call Trace:
> [   13.239556] [<8006c88c>] show_stack+0x58/0x100
> [   13.244006] [<800aab74>] ___might_sleep+0x100/0x120
> [   13.248853] [<8030fb84>] napi_disable+0x30/0xd8
> [   13.253354] [<802e3c80>] ag71xx_hw_disable+0x64/0x94
> [   13.258304] [<802e3cd4>] ag71xx_stop+0x24/0x38
> [   13.262731] [<8030d580>] __dev_close_many+0xcc/0x104
> [   13.267697] [<803165fc>] __dev_change_flags+0xc8/0x1ac
> [   13.272801] [<80316708>] dev_change_flags+0x28/0x70
> [   13.277662] [<80329fc0>] do_setlink+0x31c/0x91c
> [   13.282178] [<8032ca90>] rtnl_newlink+0x3ec/0x7f8
> [   13.286865] [<8032abc8>] rtnetlink_rcv_msg+0x2fc/0x380
> [   13.292019] [<8034de64>] netlink_rcv_skb+0xd4/0x178
> [   13.296849] [<8034d440>] netlink_unicast+0x168/0x250
> [   13.301797] [<8034da04>] netlink_sendmsg+0x3d8/0x434
> [   13.306753] [<802f2774>] ___sys_sendmsg+0x1dc/0x290
> [   13.311607] [<802f37d0>] __sys_sendmsg+0x54/0x84
> [   13.316225] [<80071eac>] syscall_common+0x34/0x58

There is a bug in ag71xx_hw_disable(), it calls napi_disable() while
holding a spinlock in the same function which is not allowed. I never
looked into ag71xx before, someone should fix this code and make it call
napi_disable() outside of the spinlock.

Hauke



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] lantiq: use gpio_hog instead of gpio-export

2019-08-02 Thread Hauke Mehrtens
On 8/2/19 11:57 AM, Birger Koblitz wrote:
> lantiq: use gpio_hog instead of gpio-export
> 
> The `gpio-export` functionality is a hack for
> missing kernel functionality, which was rejected in upstream kernel long
> time
> ago, for details see this email
> http://lists.infradead.org/pipermail/openwrt-devel/2019-February/015772.html,
> discussion in PR#1366 or
> https://github.com/openwrt/openwrt/pull/1814#issuecomment-462942022.
> 
> This patch converts all remaining lantiq .dts(i) files which were
> using export-gpio and not making use of the change-direction functionality
> to using gpio_hog instead
> 
> Signed-off-by: Birger Koblitz 

Reviewed-by: Hauke Mehrtens 

I only reviewed this, it would be nice if someone could test this at
least on one of the affected devices.

Hauke

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


Re: [OpenWrt-Devel] package mt76 fails to compile under certain configuration [Was: Compilation error on master / mt7620]

2019-08-02 Thread Joan Moreau 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 ---
Removing "debug fs" in compilation options removes the problem. 

So there is something very awkward in the Makefile 


On 2019-08-02 20:28, Joan Moreau wrote:


attached

On 2019-08-02 18:36, Petr Štetiar wrote: 
Joan Moreau via openwrt-devel  [2019-08-02 07:56:41]:


Hello,

I reach the following error while compiling my MT7620/ZBT826-16M on
master (no error on 18.06) :

CC [M]
/usr/src/openwrt/4g/build_dir/target-mipsel_24kc_musl/linux-ramips_mt7620/mt76-2019-07-22-75656a45/mt7603/pci.o
:0:37: error: redeclaration of enumerator
'IEEE80211_HW_REPORTS_TX_ACK_STATUS'
:0:37: note: in definition of macro
'IEEE80211_HW_TX_STATUS_NO_AMPDU_LEN'
In file included from
/usr/src/openwrt/4g/build_dir/target-mipsel_24kc_musl/linux-ramips_mt7620/mt76-2019-07-22-75656a45/mt7603/../mt76.h:27:0,
from
/usr/src/openwrt/4g/build_dir/target-mipsel_24kc_musl/linux-ramips_mt7620/mt76-2019-07-22-75656a45/mt7603/mt7603.h:8,
from
/usr/src/openwrt/4g/build_dir/target-mipsel_24kc_musl/linux-ramips_mt7620/mt76-2019-07-22-75656a45/mt7603/pci.c:7:
/usr/src/openwrt/4g/staging_dir/target-mipsel_24kc_musl/usr/include/mac80211/net/mac80211.h:2293:2:
note: previous definition of 'IEEE80211_HW_REPORTS_TX_ACK_STATUS' was
here
IEEE80211_HW_REPORTS_TX_ACK_STATUS,
^~
make[6]: *** [scripts/Makefile.build:327:
/usr/src/openwrt/4g/build_dir/target-mipsel_24kc_musl/linux-ramips_mt7620/mt76-2019-07-22-75656a45/mt7603/pci.o]
Error 1
make[5]: *** [scripts/Makefile.build:585:
/usr/src/openwrt/4g/build_dir/target-mipsel_24kc_musl/linux-ramips_mt7620/mt76-2019-07-22-75656a45/mt7603]
Error 2
make[4]: *** [Makefile:1532:
_module_/usr/src/openwrt/4g/build_dir/target-mipsel_24kc_musl/linux-ramips_mt7620/mt76-2019-07-22-75656a45]
Error 2

Can you help ? 
the problem is probably in this compile check[1], so please do following:


make package/mt76/{clean,prepare}
sed -i 's;TMP";TMP" 2> $(TOPDIR)/meh.log;' build_dir/target-mipsel_24kc_musl/linux-ramips_mt7620/mt76-2019-07-22-75656a45/mt7603/Makefile 
make package/mt76/compile

scripts/diffconfig.sh >> meh.log; gzip meh.log

and send meh.log.gz file as attachment.

1. https://github.com/openwrt/mt76/blob/master/mt7603/Makefile#L7

-- ynezz

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


Re: [OpenWrt-Devel] package mt76 fails to compile under certain configuration [Was: Compilation error on master / mt7620]

2019-08-02 Thread Joan Moreau 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 ---

attached

On 2019-08-02 18:36, Petr Štetiar wrote:


Joan Moreau via openwrt-devel  [2019-08-02 
07:56:41]:


Hello,

I reach the following error while compiling my MT7620/ZBT826-16M on
master (no error on 18.06) :

CC [M]
/usr/src/openwrt/4g/build_dir/target-mipsel_24kc_musl/linux-ramips_mt7620/mt76-2019-07-22-75656a45/mt7603/pci.o
:0:37: error: redeclaration of enumerator
'IEEE80211_HW_REPORTS_TX_ACK_STATUS'
:0:37: note: in definition of macro
'IEEE80211_HW_TX_STATUS_NO_AMPDU_LEN'
In file included from
/usr/src/openwrt/4g/build_dir/target-mipsel_24kc_musl/linux-ramips_mt7620/mt76-2019-07-22-75656a45/mt7603/../mt76.h:27:0,
from
/usr/src/openwrt/4g/build_dir/target-mipsel_24kc_musl/linux-ramips_mt7620/mt76-2019-07-22-75656a45/mt7603/mt7603.h:8,
from
/usr/src/openwrt/4g/build_dir/target-mipsel_24kc_musl/linux-ramips_mt7620/mt76-2019-07-22-75656a45/mt7603/pci.c:7:
/usr/src/openwrt/4g/staging_dir/target-mipsel_24kc_musl/usr/include/mac80211/net/mac80211.h:2293:2:
note: previous definition of 'IEEE80211_HW_REPORTS_TX_ACK_STATUS' was
here
IEEE80211_HW_REPORTS_TX_ACK_STATUS,
^~
make[6]: *** [scripts/Makefile.build:327:
/usr/src/openwrt/4g/build_dir/target-mipsel_24kc_musl/linux-ramips_mt7620/mt76-2019-07-22-75656a45/mt7603/pci.o]
Error 1
make[5]: *** [scripts/Makefile.build:585:
/usr/src/openwrt/4g/build_dir/target-mipsel_24kc_musl/linux-ramips_mt7620/mt76-2019-07-22-75656a45/mt7603]
Error 2
make[4]: *** [Makefile:1532:
_module_/usr/src/openwrt/4g/build_dir/target-mipsel_24kc_musl/linux-ramips_mt7620/mt76-2019-07-22-75656a45]
Error 2

Can you help ?


the problem is probably in this compile check[1], so please do following:

make package/mt76/{clean,prepare}
sed -i 's;TMP";TMP" 2> $(TOPDIR)/meh.log;' build_dir/target-mipsel_24kc_musl/linux-ramips_mt7620/mt76-2019-07-22-75656a45/mt7603/Makefile 
make package/mt76/compile

scripts/diffconfig.sh >> meh.log; gzip meh.log

and send meh.log.gz file as attachment.

1. https://github.com/openwrt/mt76/blob/master/mt7603/Makefile#L7

-- ynezz

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

meh.log.gz
Description: GNU Zip compressed data
--- End Message ---
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] package mt76 fails to compile under certain configuration [Was: Compilation error on master / mt7620]

2019-08-02 Thread Petr Štetiar
Joan Moreau via openwrt-devel  [2019-08-02 
07:56:41]:

> Hello,
> 
> I reach the following error while compiling my MT7620/ZBT826-16M on
> master (no error on 18.06) :
> 
> CC [M]
> /usr/src/openwrt/4g/build_dir/target-mipsel_24kc_musl/linux-ramips_mt7620/mt76-2019-07-22-75656a45/mt7603/pci.o
> :0:37: error: redeclaration of enumerator
> 'IEEE80211_HW_REPORTS_TX_ACK_STATUS'
> :0:37: note: in definition of macro
> 'IEEE80211_HW_TX_STATUS_NO_AMPDU_LEN'
> In file included from
> /usr/src/openwrt/4g/build_dir/target-mipsel_24kc_musl/linux-ramips_mt7620/mt76-2019-07-22-75656a45/mt7603/../mt76.h:27:0,
> from
> /usr/src/openwrt/4g/build_dir/target-mipsel_24kc_musl/linux-ramips_mt7620/mt76-2019-07-22-75656a45/mt7603/mt7603.h:8,
> from
> /usr/src/openwrt/4g/build_dir/target-mipsel_24kc_musl/linux-ramips_mt7620/mt76-2019-07-22-75656a45/mt7603/pci.c:7:
> /usr/src/openwrt/4g/staging_dir/target-mipsel_24kc_musl/usr/include/mac80211/net/mac80211.h:2293:2:
> note: previous definition of 'IEEE80211_HW_REPORTS_TX_ACK_STATUS' was
> here
> IEEE80211_HW_REPORTS_TX_ACK_STATUS,
> ^~
> make[6]: *** [scripts/Makefile.build:327:
> /usr/src/openwrt/4g/build_dir/target-mipsel_24kc_musl/linux-ramips_mt7620/mt76-2019-07-22-75656a45/mt7603/pci.o]
> Error 1
> make[5]: *** [scripts/Makefile.build:585:
> /usr/src/openwrt/4g/build_dir/target-mipsel_24kc_musl/linux-ramips_mt7620/mt76-2019-07-22-75656a45/mt7603]
> Error 2
> make[4]: *** [Makefile:1532:
> _module_/usr/src/openwrt/4g/build_dir/target-mipsel_24kc_musl/linux-ramips_mt7620/mt76-2019-07-22-75656a45]
> Error 2
> 
> Can you help ?

the problem is probably in this compile check[1], so please do following:

 make package/mt76/{clean,prepare}
 sed -i 's;TMP";TMP" 2> $(TOPDIR)/meh.log;' 
build_dir/target-mipsel_24kc_musl/linux-ramips_mt7620/mt76-2019-07-22-75656a45/mt7603/Makefile
 
 make package/mt76/compile
 scripts/diffconfig.sh >> meh.log; gzip meh.log

and send meh.log.gz file as attachment.

1. https://github.com/openwrt/mt76/blob/master/mt7603/Makefile#L7

-- ynezz

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


[OpenWrt-Devel] [PATCH] ramips: use gpio_hog instead of gpio-export

2019-08-02 Thread Birger Koblitz
ramips: use gpio_hog instead of gpio-export

The `gpio-export` functionality is a hack for
missing kernel functionality, which was rejected in upstream kernel long
time
ago, for details see this email
http://lists.infradead.org/pipermail/openwrt-devel/2019-February/015772.html,
discussion in PR#1366 or
https://github.com/openwrt/openwrt/pull/1814#issuecomment-462942022.

This patch converts all remaining ramips .dts(i) files which were
using export-gpio and not making use of the change-direction functionality
to using gpio_hog instead

Signed-off-by: Birger Koblitz 

---

diff --git a/target/linux/ramips/dts/mt7620a_alfa-network_tube-e4g.dts
b/target/linux/ramips/dts/mt7620a_alfa-network_tube-e4g.dts
index 4097dc6140..ea0d9801c1 100644
--- a/target/linux/ramips/dts/mt7620a_alfa-network_tube-e4g.dts
+++ b/target/linux/ramips/dts/mt7620a_alfa-network_tube-e4g.dts
@@ -21,39 +21,6 @@
     bootargs = "console=ttyS0,115200";
 };
 
-    gpio-export {
-        compatible = "gpio-export";
-        #size-cells = <0>;
-
-        modem-enable {
-            gpio-export,name = "modem-enable";
-            gpio-export,output = <1>;
-            gpios = < 12 GPIO_ACTIVE_HIGH>;
-        };
-
-        modem-rf-enable {
-            gpio-export,name = "modem-rf-enable";
-            gpio-export,output = <1>;
-            gpios = < 12 GPIO_ACTIVE_HIGH>;
-        };
-
-        sim-select {
-            gpio-export,name = "sim-select";
-            gpio-export,output = <0>;
-            gpios = < 13 GPIO_ACTIVE_HIGH>;
-        };
-
-        sim1-detect {
-            gpio-export,name = "sim1-detect";
-            gpios = < 9 GPIO_ACTIVE_HIGH>;
-        };
-
-        sim2-detect {
-            gpio-export,name = "sim2-detect";
-            gpios = < 1 GPIO_ACTIVE_HIGH>;
-        };
-    };
-
 keys {
     compatible = "gpio-keys";
 
@@ -98,26 +65,61 @@
 };
 };
 
- {
+ {
 status = "okay";
-};
 
- {
-    mtd-mac-address = < 0x28>;
+    modem-enable {
+        gpio-hog;
+        line-name = "modem-enable";
+        gpios = <12 GPIO_ACTIVE_HIGH>;
+        output-high;
+    };
 };
 
  {
 status = "okay";
+
+    modem-rf-enable {
+        gpio-hog;
+        line-name = "modem-rf-enable";
+        gpios = <12 GPIO_ACTIVE_HIGH>;
+        output-high;
+    };
+
+    sim-select {
+        gpio-hog;
+        line-name = "sim-select";
+        gpios = <13 GPIO_ACTIVE_HIGH>;
+        output-low;
+    };
+
+    sim1-detect {
+        gpio-hog;
+        line-name = "sim1-detect";
+        gpios = <9 GPIO_ACTIVE_HIGH>;
+        input;
+    };
 };
 
- {
+ {
 status = "okay";
+
+    sim2-detect {
+        gpio-hog;
+        line-name = "sim2-detect";
+        gpios = <1 GPIO_ACTIVE_HIGH>;
+        input;
+    };
 };
 
- {
+ {
 status = "okay";
 };
 
+ {
+    mtd-mac-address = < 0x28>;
+};
+
  {
 mediatek,port4 = "ephy";
 };
diff --git a/target/linux/ramips/dts/mt7620a_asus_rt-ac51u.dts
b/target/linux/ramips/dts/mt7620a_asus_rt-ac51u.dts
index 3e54ffdad2..c573b38284 100644
--- a/target/linux/ramips/dts/mt7620a_asus_rt-ac51u.dts
+++ b/target/linux/ramips/dts/mt7620a_asus_rt-ac51u.dts
@@ -53,16 +53,16 @@
         linux,code = ;
     };
 };
+};
 
-    gpio_export {
-        compatible = "gpio-export";
-        #size-cells = <0>;
+ {
+    status = "okay";
 
-        enable-leds {
-            gpio-export,name = "enable-leds";
-            gpio-export,output = <1>;
-            gpios = < 10 GPIO_ACTIVE_HIGH>;
-        };
+    enable-leds {
+        gpio-hog;
+        line-name = "enable-leds";
+        gpios = <10 GPIO_ACTIVE_HIGH>;
+        output-high;
 };
 };
 
diff --git a/target/linux/ramips/dts/mt7620a_dlink_dwr-118-a1.dts
b/target/linux/ramips/dts/mt7620a_dlink_dwr-118-a1.dts
index 707bc1c3d3..7af90c6908 100644
--- a/target/linux/ramips/dts/mt7620a_dlink_dwr-118-a1.dts
+++ b/target/linux/ramips/dts/mt7620a_dlink_dwr-118-a1.dts
@@ -63,21 +63,17 @@
         linux,default-trigger = "usbport";
     };
 };
-
-    gpio_export {
-        compatible = "gpio-export";
-        #size-cells = <0>;
-
-        usb {
-            gpio-export,name = "usb";
-            gpio-export,output = <0>;
-            gpios = < 14 GPIO_ACTIVE_LOW>;
-        };
-    };
 };
 
  {
 status = "okay";
+
+    usb {
+        gpio-hog;
+        line-name = "usb";
+        gpios = <14 GPIO_ACTIVE_LOW>;
+        output-low;
+    };
 };
 
  {
diff --git a/target/linux/ramips/dts/mt7620a_dlink_dwr-118-a2.dts
b/target/linux/ramips/dts/mt7620a_dlink_dwr-118-a2.dts
index 26b23aa6d1..17ec47b9d5 100644
--- a/target/linux/ramips/dts/mt7620a_dlink_dwr-118-a2.dts
+++ b/target/linux/ramips/dts/mt7620a_dlink_dwr-118-a2.dts
@@ -61,21 +61,17 @@
         linux,default-trigger = "usbport";
     };
 };
-
-    gpio_export {
-        compatible = "gpio-export";
-        #size-cells = <0>;
-
-        usb {
-            gpio-export,name = "usb";
-            gpio-export,output = <1>;
-            gpios = < 14 

[OpenWrt-Devel] [PATCH] lantiq: use gpio_hog instead of gpio-export

2019-08-02 Thread Birger Koblitz
lantiq: use gpio_hog instead of gpio-export

The `gpio-export` functionality is a hack for
missing kernel functionality, which was rejected in upstream kernel long
time
ago, for details see this email
http://lists.infradead.org/pipermail/openwrt-devel/2019-February/015772.html,
discussion in PR#1366 or
https://github.com/openwrt/openwrt/pull/1814#issuecomment-462942022.

This patch converts all remaining lantiq .dts(i) files which were
using export-gpio and not making use of the change-direction functionality
to using gpio_hog instead

Signed-off-by: Birger Koblitz 

---

diff --git a/target/linux/lantiq/files/arch/mips/boot/dts/ARV7519PW.dts
b/target/linux/lantiq/files/arch/mips/boot/dts/ARV7519PW.dts
index e9c418e482..c597febeeb 100644
--- a/target/linux/lantiq/files/arch/mips/boot/dts/ARV7519PW.dts
+++ b/target/linux/lantiq/files/arch/mips/boot/dts/ARV7519PW.dts
@@ -110,15 +110,16 @@
 };
 
 /* is there another way to "reserve" the GPIO? */
-    gpio_export {
-        compatible = "gpio-export";
-        #size-cells = <0>;
+};
 
-        switch {
-            gpio-export,name = "switch";
-            gpio-export,output = <1>;
-            gpios = < 19 GPIO_ACTIVE_HIGH>;
-        };
+ {
+    status = "okay";
+
+    switch {
+        gpio-hog;
+        line-name = "switch";
+        gpios = <19 GPIO_ACTIVE_HIGH>;
+        output-high;
 };
 };
 
diff --git a/target/linux/lantiq/files/arch/mips/boot/dts/ASL56026.dts
b/target/linux/lantiq/files/arch/mips/boot/dts/ASL56026.dts
index 1c7f03c355..5d801d14ec 100644
--- a/target/linux/lantiq/files/arch/mips/boot/dts/ASL56026.dts
+++ b/target/linux/lantiq/files/arch/mips/boot/dts/ASL56026.dts
@@ -58,16 +58,16 @@
         gpios = < 18 GPIO_ACTIVE_HIGH>;
     };
 };
+};
 
-    gpio_export {
-        compatible = "gpio-export";
-        #size-cells = <0>;
+ {
+    status = "okay";
 
-        power_led_blink {
-            gpio-export,name = "power_led_blink";
-            gpio-export,output = <0>;
-            gpios = < 16 GPIO_ACTIVE_LOW>;
-        };
+    power_led_blink {
+        gpio-hog;
+        line-name = "power_led_blink";
+        gpios = <16 GPIO_ACTIVE_LOW>;
+        output-low;
 };
 };
 
diff --git a/target/linux/lantiq/files/arch/mips/boot/dts/DM200.dts
b/target/linux/lantiq/files/arch/mips/boot/dts/DM200.dts
index 4796123c20..0b21b67504 100644
--- a/target/linux/lantiq/files/arch/mips/boot/dts/DM200.dts
+++ b/target/linux/lantiq/files/arch/mips/boot/dts/DM200.dts
@@ -37,22 +37,6 @@
     };
 };
 
-    gpio_export {
-        compatible = "gpio-export";
-        #size-cells = <0>;
-
-        annexa {
-            gpio-export,name = "annexa";
-            gpio-export,output = <0>;
-            gpios = < 12 GPIO_ACTIVE_HIGH>;
-        };
-        annexb {
-            gpio-export,name = "annexb";
-            gpio-export,output = <0>;
-            gpios = < 15 GPIO_ACTIVE_HIGH>;
-        };
-    };
-
 leds {
     compatible = "gpio-leds";
 
@@ -85,6 +69,24 @@
 };
 };
 
+ {
+    status = "okay";
+
+    annexa {
+        gpio-hog;
+        line-name = "annexa";
+        gpios = <12 GPIO_ACTIVE_HIGH>;
+        output-low;
+    };
+
+    annexb {
+        gpio-hog;
+        line-name = "annexb";
+        gpios = <15 GPIO_ACTIVE_HIGH>;
+        output-low;
+    };
+};
+
  {
 lantiq,phys = <>;
 
diff --git a/target/linux/lantiq/files/arch/mips/boot/dts/GIGASX76X.dts
b/target/linux/lantiq/files/arch/mips/boot/dts/GIGASX76X.dts
index a9a5cbae2f..6b4ab7f918 100644
--- a/target/linux/lantiq/files/arch/mips/boot/dts/GIGASX76X.dts
+++ b/target/linux/lantiq/files/arch/mips/boot/dts/GIGASX76X.dts
@@ -28,17 +28,6 @@
     };
 };
 
-    gpio_export {
-        compatible = "gpio-export";
-        #size-cells = <0>;
-
-        switch {
-            gpio-export,name = "switch";
-            gpio-export,output = <1>;
-            gpios = < 19 GPIO_ACTIVE_HIGH>;
-        };
-    };
-
 usb_vbus: regulator-usb-vbus {
     compatible = "regulator-fixed";
 
@@ -52,6 +41,17 @@
 };
 };
 
+ {
+    status = "okay";
+
+    switch {
+        gpio-hog;
+        line-name = "switch";
+        gpios = <19 GPIO_ACTIVE_HIGH>;
+        output-high;
+    };
+};
+
  {
 pinctrl-names = "default";
 pinctrl-0 = <_default>;
@@ -64,10 +64,6 @@
 };
 };
 
- {
-    status = "okay";
-};
-
  {
 phy-mode = "rmii";
 };
diff --git a/target/linux/lantiq/files/arch/mips/boot/dts/H201L.dts
b/target/linux/lantiq/files/arch/mips/boot/dts/H201L.dts
index 9b640e0327..fe0e5af0c1 100644
--- a/target/linux/lantiq/files/arch/mips/boot/dts/H201L.dts
+++ b/target/linux/lantiq/files/arch/mips/boot/dts/H201L.dts
@@ -84,27 +84,6 @@
     };
 };
 
-    gpio_export {
-        compatible = "gpio-export";
-        #size-cells = <0>;
-
-        switch {
-            gpio-export,name = "switch";
-            gpio-export,output = <1>;
-            gpios = < 38 GPIO_ACTIVE_HIGH>;
-        };
-        usb {
-            gpio-export,name = 

[OpenWrt-Devel] [PATCH] ath79: use gpio_hog instead of gpio-export

2019-08-02 Thread Birger Koblitz
ath79: use gpio_hog instead of gpio-export

The `gpio-export` functionality is a hack for
missing kernel functionality, which was rejected in upstream kernel long
time
ago, for details see this email
http://lists.infradead.org/pipermail/openwrt-devel/2019-February/015772.html,
discussion in PR#1366 or
https://github.com/openwrt/openwrt/pull/1814#issuecomment-462942022.

This patch converts all remaining ath79 .dts files which were
using export-gpio to using gpio_hog instead

Signed-off-by: Birger Koblitz 

---

diff --git a/target/linux/ath79/dts/ar7161_buffalo_wzr-hp-ag300h.dts
b/target/linux/ath79/dts/ar7161_buffalo_wzr-hp-ag300h.dts
index df22eb8dc4..822858aab7 100644
--- a/target/linux/ath79/dts/ar7161_buffalo_wzr-hp-ag300h.dts
+++ b/target/linux/ath79/dts/ar7161_buffalo_wzr-hp-ag300h.dts
@@ -121,16 +121,6 @@
     };
 };
 
-    gpio-export {
-        compatible = "gpio-export";
-
-        gpio_usb_power {
-            gpio-export,name = "buffalo:power:usb";
-            gpio-export,output = <1>;
-            gpios = < 2 GPIO_ACTIVE_HIGH>;
-        };
-    };
-
 flash {
     compatible = "mtd-concat";
 
@@ -173,6 +163,17 @@
 };
 };
 
+ {
+    status = "okay";
+
+    usb {
+        gpio-hog;
+        line-name = "buffalo:power:usb";
+        gpios = <2 GPIO_ACTIVE_HIGH>;
+        output-high;
+    };
+};
+
 _phy {
 status = "okay";
 };
diff --git a/target/linux/ath79/dts/ar7241_tplink_tl-mr3x20.dtsi
b/target/linux/ath79/dts/ar7241_tplink_tl-mr3x20.dtsi
index 04403637b6..de0deb3f3c 100644
--- a/target/linux/ath79/dts/ar7241_tplink_tl-mr3x20.dtsi
+++ b/target/linux/ath79/dts/ar7241_tplink_tl-mr3x20.dtsi
@@ -3,15 +3,16 @@
 #include "ar7241_tplink.dtsi"
 
 / {
-    gpio-export {
-        compatible = "gpio-export";
-        #size-cells = <0>;
-
-        gpio_usb_power {
-            gpio-export,name = "tp-link:power:usb";
-            gpio-export,output = <1>;
-            gpios = < 6 GPIO_ACTIVE_HIGH>;
-        };
+};
+
+ {
+    status = "okay";
+
+    usb {
+        gpio-hog;
+        line-name = "tp-link:power:usb";
+        gpios = <6 GPIO_ACTIVE_HIGH>;
+        output-high;
 };
 };
 
diff --git a/target/linux/ath79/dts/ar7241_tplink_tl-wr842n-v1.dts
b/target/linux/ath79/dts/ar7241_tplink_tl-wr842n-v1.dts
index 282446b1e1..829f1fe0e7 100644
--- a/target/linux/ath79/dts/ar7241_tplink_tl-wr842n-v1.dts
+++ b/target/linux/ath79/dts/ar7241_tplink_tl-wr842n-v1.dts
@@ -66,15 +66,16 @@
         linux,default-trigger = "phy0tpt";
     };
 };
+};
 
-    gpio-export {
-        compatible = "gpio-export";
+ {
+    status = "okay";
 
-        gpio_usb_power {
-            gpio-export,name = "tp-link:power:usb";
-            gpio-export,output = <1>;
-            gpios = < 6 GPIO_ACTIVE_HIGH>;
-        };
+    usb {
+        gpio-hog;
+        line-name = "tp-link:power:usb";
+        gpios = <6 GPIO_ACTIVE_HIGH>;
+        output-high;
 };
 };
 
@@ -155,10 +156,6 @@
 mtd-mac-address-increment = <1>;
 };
 
- {
-    status = "okay";
-};
-
  {
 status = "okay";
 };
diff --git a/target/linux/ath79/dts/ar7242_buffalo_wzr-bhr.dtsi
b/target/linux/ath79/dts/ar7242_buffalo_wzr-bhr.dtsi
index 70ce41b84d..aee37729b1 100644
--- a/target/linux/ath79/dts/ar7242_buffalo_wzr-bhr.dtsi
+++ b/target/linux/ath79/dts/ar7242_buffalo_wzr-bhr.dtsi
@@ -58,17 +58,6 @@
     };
 };
 
-    gpio-export {
-        compatible = "gpio-export";
-        #size-cells = <0>;
-
-        gpio_usb_power {
-            gpio-export,name = "buffalo:usb-power";
-            gpio-export,output = <1>;
-            gpios = < 16 GPIO_ACTIVE_HIGH>;
-        };
-    };
-
 virtual_flash {
     compatible = "mtd-concat";
     devices = < >;
@@ -110,6 +99,17 @@
 };
 };
 
+ {
+    status = "okay";
+
+    usb-power {
+        gpio-hog;
+        line-name = "buffalo:usb-power";
+        gpios = <16 GPIO_ACTIVE_HIGH>;
+        output-high;
+    };
+};
+
  {
 status = "okay";
 cs-gpios = <0>, <0>;
diff --git a/target/linux/ath79/dts/ar7242_buffalo_wzr-hp-g302h-a1a0.dts
b/target/linux/ath79/dts/ar7242_buffalo_wzr-hp-g302h-a1a0.dts
index 97bfd0f842..9f04025598 100644
--- a/target/linux/ath79/dts/ar7242_buffalo_wzr-hp-g302h-a1a0.dts
+++ b/target/linux/ath79/dts/ar7242_buffalo_wzr-hp-g302h-a1a0.dts
@@ -110,17 +110,6 @@
     };
 };
 
-    gpio-export {
-        compatible = "gpio-export";
-        #size-cells = <0>;
-
-        gpio_usb_power {
-            gpio-export,name = "buffalo:usb-power";
-            gpio-export,output = <1>;
-            gpios = < 13 GPIO_ACTIVE_HIGH>;
-        };
-    };
-
 virtual_flash {
     compatible = "mtd-concat";
     devices = < >;
@@ -162,6 +151,17 @@
 };
 };
 
+ {
+    status = "okay";
+
+    usb-power {
+        gpio-hog;
+        line-name = "buffalo:usb-power";
+        gpios = <13 GPIO_ACTIVE_HIGH>;
+        output-high;
+    };
+};
+
  {
 status = "okay";
 cs-gpios = <0>, <0>;
diff --git 

Re: [OpenWrt-Devel] Compilation error on master / mt7620

2019-08-02 Thread Joan Moreau 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 ---
Same error with 19.07 


On 2019-08-02 07:56, Joan Moreau wrote:

Hello, 

I reach the following error while compiling my MT7620/ZBT826-16M on master (no error on 18.06) : 


CC [M] 
/usr/src/openwrt/4g/build_dir/target-mipsel_24kc_musl/linux-ramips_mt7620/mt76-2019-07-22-75656a45/mt7603/pci.o
:0:37: error: redeclaration of enumerator 
'IEEE80211_HW_REPORTS_TX_ACK_STATUS'
:0:37: note: in definition of macro 
'IEEE80211_HW_TX_STATUS_NO_AMPDU_LEN'
In file included from 
/usr/src/openwrt/4g/build_dir/target-mipsel_24kc_musl/linux-ramips_mt7620/mt76-2019-07-22-75656a45/mt7603/../mt76.h:27:0,
from 
/usr/src/openwrt/4g/build_dir/target-mipsel_24kc_musl/linux-ramips_mt7620/mt76-2019-07-22-75656a45/mt7603/mt7603.h:8,
from 
/usr/src/openwrt/4g/build_dir/target-mipsel_24kc_musl/linux-ramips_mt7620/mt76-2019-07-22-75656a45/mt7603/pci.c:7:
/usr/src/openwrt/4g/staging_dir/target-mipsel_24kc_musl/usr/include/mac80211/net/mac80211.h:2293:2:
 note: previous definition of 'IEEE80211_HW_REPORTS_TX_ACK_STATUS' was here
IEEE80211_HW_REPORTS_TX_ACK_STATUS,
^~
make[6]: *** [scripts/Makefile.build:327: 
/usr/src/openwrt/4g/build_dir/target-mipsel_24kc_musl/linux-ramips_mt7620/mt76-2019-07-22-75656a45/mt7603/pci.o]
 Error 1
make[5]: *** [scripts/Makefile.build:585: 
/usr/src/openwrt/4g/build_dir/target-mipsel_24kc_musl/linux-ramips_mt7620/mt76-2019-07-22-75656a45/mt7603]
 Error 2
make[4]: *** [Makefile:1532: _module_/usr/src/openwrt/4g/build_dir/target-mipsel_24kc_musl/linux-ramips_mt7620/mt76-2019-07-22-75656a45] Error 2 

Can you help ? 


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


[OpenWrt-Devel] Dodatečné zdroje

2019-08-02 Thread Kamil Adamec 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 ---
Dobrý den!

Živnostníkům často stojí v cestě k dosažení úspěchu nízká úroveň provozních 
zdrojů na nákup materiálu, zboží nebo surovin z důvodu např. nezaplacení faktur 
(nezaplacení od dodavatelů, prodloužená splatnost apod.). V této oblasti jsme 
již pomohli řadě firem, které mohly díky získání návratného financování 
realizovat své klíčové plány.

Jsem partnerem mnoha společností, jejichž činnost je srovnatelná s tou Vaší a 
za kooperaci s námi získáte bonus - rychlé splacení ve výši až 4 splátek.

Dovolte, abychom Vás kontaktovali za účelem provedení analýzy možností pomoci 
financování. Kdy bych mohl zavolat?


S pozdravem
Kamil Adamec
Account Manager
www.automatics-control.eu

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


[OpenWrt-Devel] [PATCH] procd: add daemon mode and remove pid 1 check

2019-08-02 Thread Paul Spooren
Add arg -D to start procd in daemon mode. This allows running procd
directly, not only via /init. Useful for CI environments to start
services like ubus and netifd without needing the whole init process.

To make this work procd also spawns services when running on a different
pid than 1, normal when started via terminal. Before it would only try
to connect to an existing ubus instance.

The -D arg handling was kindly created (with < 60 seconds RTT) by John,
I just created the patch and removed pid checking.

CC: John Crispin 
Signed-off-by: Paul Spooren 
---
 procd.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/procd.c b/procd.c
index 3de6208..10b974b 100644
--- a/procd.c
+++ b/procd.c
@@ -50,7 +50,7 @@ int main(int argc, char **argv)
unsetenv("DBGLVL");
}
 
-   while ((ch = getopt(argc, argv, "d:s:h:S")) != -1) {
+   while ((ch = getopt(argc, argv, "d:s:h:SD")) != -1) {
switch (ch) {
case 'h':
return hotplug_run(optarg);
@@ -63,6 +63,9 @@ int main(int argc, char **argv)
case 'S':
ulog_channels = ULOG_STDIO;
break;
+   case 'D':
+   daemon(1, 1);
+   break;
default:
return usage(argv[0]);
}
@@ -74,10 +77,7 @@ int main(int argc, char **argv)
setsid();
uloop_init();
procd_signal();
-   if (getpid() != 1)
-   procd_connect_ubus();
-   else
-   procd_state_next();
+   procd_state_next();
uloop_run();
uloop_done();
 
-- 
2.20.1


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


Re: [OpenWrt-Devel] atomic sleep bugs - 19.07 (and probably Master too)

2019-08-02 Thread Koen Vandeputte


On 01.08.19 17:27, Koen Vandeputte wrote:

Hi All,

I've been playing around the last few days stresstesting latest 19.07 
on different targets (ar71xx, cns3xxx, imx6, ...) with extra kernel 
debug features enabled.


I'll post some results here as maybe somebody has a clue. :)


Some interesting splats already showed up, actually also *breaking* 
some functionality while the board is running:


on Mikrotik RB2011 (ar71xx)


[   16.885207] eth0: link down
[   16.919752] BUG: sleeping function called from invalid context at 
net/core/dev.c:5563

[   17.013669] in_atomic(): 1, irqs_disabled(): 1, pid: 463, name: ip
[   17.087839] 2 locks held by ip/463:
[   17.129668]  #0:  (rtnl_mutex){}, at: [<80378814>] 
rtnetlink_rcv_msg+0x2d8/0x380
[   17.222617]  #1:  (&(>lock)->rlock){}, at: [<80331900>] 
ag71xx_hw_disable+0x24/0x94

[   17.322878] CPU: 0 PID: 463 Comm: ip Not tainted 4.14.134 #0
[   17.390782] Stack : 805e 8058aefc 80558ed0 876278ec 8061 
8061 87d1b2fc 805b7367
[   17.491032] 80552f04 01cf 8061386c 87627ccc 87d5b180 
0001 876278a0 6ae07578
[   17.591283]   80b0 8762779c 0a55a891 
 0007 
[   17.691535] 0099 8f9b5648 0098  8000 
87d6e58c 87d6e5b0 0001
[   17.791785] 8047095c 87627ccc 87d5b180 87d9ae10 0003 
802cfa54  8061

[   17.892036] ...
[   17.921352] Call Trace:
[   17.950676] [<8006cb0c>] show_stack+0x58/0x100
[   18.003996] [<800aadf4>] ___might_sleep+0x100/0x120
[   18.062512] [<8035d7f4>] napi_disable+0x30/0xd8
[   18.116854] [<80331940>] ag71xx_hw_disable+0x64/0x94
[   18.176421] [<80331994>] ag71xx_stop+0x24/0x38
[   18.229729] [<8035b1f0>] __dev_close_many+0xcc/0x104
[   18.289306] [<8036426c>] __dev_change_flags+0xc8/0x1ac
[   18.350950] [<80364378>] dev_change_flags+0x28/0x70
[   18.409473] [<80377c30>] do_setlink+0x31c/0x91c
[   18.463826] [<8037a700>] rtnl_newlink+0x3ec/0x7f8
[   18.520261] [<80378838>] rtnetlink_rcv_msg+0x2fc/0x380
[   18.581938] [<8039bac4>] netlink_rcv_skb+0xd4/0x178
[   18.640439] [<8039b0a0>] netlink_unicast+0x168/0x250
[   18.76] [<8039b664>] netlink_sendmsg+0x3d8/0x434
[   18.759580] [<803404a4>] ___sys_sendmsg+0x1dc/0x290
[   18.818098] [<80341500>] __sys_sendmsg+0x54/0x84
[   18.873504] [<8007212c>] syscall_common+0x34/0x58


on Mikrotik RB-912 (ar71xx), using ath9k combined with a USB modem 
together.  When disabling ath9k or unplugging the modem, these bugs 
don't appear

Here, the USB modem stops receiving data after a few seconds:


[   37.165493] wlan0: Trigger new scan to find an IBSS to join
[   37.171546] BUG: sleeping function called from invalid context at 
kernel/irq/manage.c:112
[   37.180006] in_atomic(): 1, irqs_disabled(): 1, pid: 9, name: 
kworker/u2:1

[   37.187110] 6 locks held by kworker/u2:1/9:
[   37.191434]  #0:  ("%s"wiphy_name(local->hw.wiphy)){}, at: 
[<8009f89c>] process_one_work+0x250/0x4c0
[   37.201298]  #1:  ((>work)){}, at: [<8009f89c>] 
process_one_work+0x250/0x4c0
[   37.209604]  #2:  (>mtx){}, at: [<82917130>] 
ieee80211_ibss_work+0x40/0x5a4 [mac80211]
[   37.219077]  #3:  (>mtx){}, at: [<8290d914>] 
ieee80211_request_ibss_scan+0x4c/0x2b8 [mac80211]
[   37.229246]  #4:  (>mutex){}, at: [<82ae4878>] 
ath9k_ps_restore+0xd54/0x11dc [ath9k]
[   37.238159]  #5:  (_desc_lock_class){}, at: [<800c29d8>] 
__irq_get_desc_lock+0x8c/0xb0

[   37.247113] CPU: 0 PID: 9 Comm: kworker/u2:1 Tainted: G W 4.14.134 #0
[   37.255282] Workqueue: phy0 ieee80211_ibss_leave [mac80211]
[   37.261055] Stack : 82870080 82870158 82860d60 800c0fa0 8061 
 0001 805b
[   37.269743] 80552e7c 8384db24 0348 800c1e04 82860d60 
 8384db00 21bc325c
[   37.278434]   0006 8384d9d4 acbbbd0d 
 0007 
[   37.287125] 0132 805c 0131   
828626d8 828703c8 0348
[   37.295816] 82870080 82870158 82860d60 828703c8 0002 
802cfa54  8061

[   37.304508] ...
[   37.307055] Call Trace:
[   37.309601] [<8006cb0c>] show_stack+0x58/0x100
[   37.314219] [<800aadf4>] ___might_sleep+0x100/0x120
[   37.319280] [<800c3344>] synchronize_irq+0x3c/0xa0
[   37.324245] [<800c6594>] __irq_disable+0x64/0xb4
[   37.329024] [<800c35f4>] __disable_irq_nosync+0x3c/0x68
[   37.334434] [<800c363c>] disable_irq+0x14/0x38
[   37.339195] [<82ae5b48>] ath9k_calculate_summary_state+0x53c/0x6f4 
[ath9k]

[   37.357669] ttyS ttyS0: 1 input overrun(s)
[   38.170588] BUG: sleeping function called from invalid context at 
kernel/irq/manage.c:112
[   38.179059] in_atomic(): 1, irqs_disabled(): 1, pid: 9, name: 
kworker/u2:1

[   38.186167] 5 locks held by kworker/u2:1/9:
[   38.190492]  #0:  ("%s"wiphy_name(local->hw.wiphy)){}, at: 
[<8009f89c>] process_one_work+0x250/0x4c0
[   38.200365]  #1: ((&(>scan_work)->work)){}, at: 
[<8009f89c>] process_one_work+0x250/0x4c0
[