Re: [OpenWrt-Devel] [PATCH 3/3] treewide: rename DEVICE_TYPE to DEFAULT_TYPE

2020-05-29 Thread Raylynn Knight via openwrt-devel
The sender domain has a DMARC Reject/Quarantine policy which disallows sending mailing list messages using the original "From" header. To mitigate this problem, the original message has been wrapped automatically by the mailing list software.--- Begin Message --- > On May 29, 2020, at 5:12 PM, M

[OpenWrt-Devel] [PATCH 2/2] procd: allow optional watchdog instance parameter

2020-05-29 Thread Daniel Bailey
From: Daniel Bailey Date: Thu, 28 May 2020 20:39:35 -0700 Subject: [PATCH] procd: allow optional watchdog instance parameter Optional instance watchdog timeout and watchdog mode be set by adding procd_set_param $mode $timeout $mode is an integer [0-2] representing instance watchdog mode of opera

[OpenWrt-Devel] [PATCH 1/2] procd: add service instance watchdog

2020-05-29 Thread Daniel Bailey
From: Daniel Bailey Date: Fri, 29 May 2020 17:37:25 -0700 Subject: [PATCH] procd: add service instance watchdog Added instance watchdog which will eventually either terminate or respawn an instance depending on the instance respawn setting. Added service ubus method 'watchdog' which services the

Re: [OpenWrt-Devel] [PATCH 3/3] treewide: rename DEVICE_TYPE to DEFAULT_TYPE

2020-05-29 Thread Matthias Schiffer
On 5/30/20 1:04 AM, m...@adrianschmutzler.de wrote: >> The variable is used rarely enough that we could well make this a bit more >> verbose. "TARGET_DEVICE_TYPE"? If it weren't for the busybox config change >> (which seems hacky to me at best*), we could also go with something like >> TARGET_PA

Re: [OpenWrt-Devel] [PATCH 3/3] treewide: rename DEVICE_TYPE to DEFAULT_TYPE

2020-05-29 Thread mail
> The variable is used rarely enough that we could well make this a bit more > verbose. "TARGET_DEVICE_TYPE"? If it weren't for the busybox config change > (which seems hacky to me at best*), we could also go with something like > TARGET_PACKAGEGROUP, as the package selection would be the only t

Re: [OpenWrt-Devel] [PATCH 1/3] treewide: drop DEVICE_TYPE when used as device variable

2020-05-29 Thread Christian Lamparter
On Friday, 29 May 2020 22:32:10 CEST m...@adrianschmutzler.de wrote: > > > > Or am I completely misled here? > > > > > > I believe you are right, it seems DEVICE_TYPE is not evaluated when > > > set in a device definition. > > True, question is then, should this really be called "DEVICE"_TYPE? > >

Re: [OpenWrt-Devel] [PATCH 3/3] treewide: rename DEVICE_TYPE to DEFAULT_TYPE

2020-05-29 Thread Matthias Schiffer
On 5/29/20 10:52 PM, m...@adrianschmutzler.de wrote: >> Or we just drop the variable at all, and do >> DEFAULT_PACKAGES := DEFAULT_PACKAGES.basic DEFAULT_PACKAGES.router >> at the beginning (!) of target.mk, so targets (effectively just 3 of them) >> can just overwrite it with >> DEFAULT_PACKAG

Re: [OpenWrt-Devel] [PATCH 3/3] treewide: rename DEVICE_TYPE to DEFAULT_TYPE

2020-05-29 Thread mail
> Or we just drop the variable at all, and do > DEFAULT_PACKAGES := DEFAULT_PACKAGES.basic DEFAULT_PACKAGES.router > at the beginning (!) of target.mk, so targets (effectively just 3 of them) > can just overwrite it with > DEFAULT_PACKAGES := DEFAULT_PACKAGES.basic DEFAULT_PACKAGES.nas > direc

Re: [OpenWrt-Devel] [PATCH 1/3] treewide: drop DEVICE_TYPE when used as device variable

2020-05-29 Thread mail
> > > Or am I completely misled here? > > > > I believe you are right, it seems DEVICE_TYPE is not evaluated when > > set in a device definition. > True, question is then, should this really be called "DEVICE"_TYPE? > It's not like other DEVICE_* variables (DEVICE_NAME, DEVICE_PACKAGES or > DEVICE_

Re: [OpenWrt-Devel] [PATCH 1/3] treewide: drop DEVICE_TYPE when used as device variable

2020-05-29 Thread Christian Lamparter
On Friday, 29 May 2020 21:32:59 CEST Matthias Schiffer wrote: > On 5/29/20 7:45 PM, m...@adrianschmutzler.de wrote: > >>> Consequently, having it set anyway is misleading, so this drops all > >>> cases. > >> > >> Well, I can tell you where it matters for devices. > >> > >> You'll have to look at th

Re: [OpenWrt-Devel] [PATCH 3/3] treewide: rename DEVICE_TYPE to DEFAULT_TYPE

2020-05-29 Thread mail
> > The prefix "DEVICE_" for Make variables is only used for per-device > > variables with the only exception of DEVICE_TYPE. This is misleading > > as it leads people to incorrectly assume it can be set per device like > > all the other DEVICE_* variables, as has been observed in the past. > >

Re: [OpenWrt-Devel] [PATCH 3/3] treewide: rename DEVICE_TYPE to DEFAULT_TYPE

2020-05-29 Thread Matthias Schiffer
On 5/29/20 7:22 PM, Adrian Schmutzler wrote: > The prefix "DEVICE_" for Make variables is only used for per-device > variables with the only exception of DEVICE_TYPE. This is misleading > as it leads people to incorrectly assume it can be set per device like > all the other DEVICE_* variables, as h

Re: [OpenWrt-Devel] [PATCH 1/3] treewide: drop DEVICE_TYPE when used as device variable

2020-05-29 Thread Matthias Schiffer
On 5/29/20 7:45 PM, m...@adrianschmutzler.de wrote: >>> Consequently, having it set anyway is misleading, so this drops all >>> cases. >> >> Well, I can tell you where it matters for devices. >> >> You'll have to look at this: >> >>

Re: [OpenWrt-Devel] [PATCH v2 4/4] build: use zstd for SDK and ImageBuilder tarballs

2020-05-29 Thread Matthias Schiffer
On 5/17/20 1:51 PM, Matthias Schiffer wrote: > Comression level -19 was chosen as it provides a very good tradeoff > between compression ratio and performance, especially in multithreaded > operation. > > Signed-off-by: Matthias Schiffer Jow, do you have any opinion on this? I assume this will a

Re: [OpenWrt-Devel] [PATCH 1/3] treewide: drop DEVICE_TYPE when used as device variable

2020-05-29 Thread mail
> > Consequently, having it set anyway is misleading, so this drops all > > cases. > > Well, I can tell you where it matters for devices. > > You'll have to look at this: > > mk;h=9bd4c14936c1438df2be87e5697f5f5568699d2b;

Re: [OpenWrt-Devel] [PATCH] build: reflect DEVICE_TYPE to top level config

2020-05-29 Thread mail
> -Original Message- > From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org] > On Behalf Of Linus Walleij > Sent: Freitag, 29. Mai 2020 14:21 > To: openwrt-devel@lists.openwrt.org > Cc: Linus Walleij > Subject: [OpenWrt-Devel] [PATCH] build: reflect DEVICE_TYPE to top level

Re: [OpenWrt-Devel] [PATCH 1/3] treewide: drop DEVICE_TYPE when used as device variable

2020-05-29 Thread Christian Lamparter
On Friday, 29 May 2020 19:22:36 CEST Adrian Schmutzler wrote: > DEVICE_TYPE is a target/subtarget variable, and it does not have > any effect when set in a device definition. It can only be set > in a target's or subtarget's Makefile. > > Consequently, having it set anyway is misleading, so this d

[OpenWrt-Devel] [PATCH 3/3] treewide: rename DEVICE_TYPE to DEFAULT_TYPE

2020-05-29 Thread Adrian Schmutzler
The prefix "DEVICE_" for Make variables is only used for per-device variables with the only exception of DEVICE_TYPE. This is misleading as it leads people to incorrectly assume it can be set per device like all the other DEVICE_* variables, as has been observed in the past. This renames this (rar

[OpenWrt-Devel] [PATCH 2/3] treewide: provide consistent basic DEVICE_TYPE

2020-05-29 Thread Adrian Schmutzler
While the effective "default" based on frequent use is "router", the DEVICE_TYPE variable actually provides a "basic" configuration without selecting any additional packages. This is currently set up with the identifier "bootloader", which seems to be not used at all. However, the only targets not

[OpenWrt-Devel] [PATCH 1/3] treewide: drop DEVICE_TYPE when used as device variable

2020-05-29 Thread Adrian Schmutzler
DEVICE_TYPE is a target/subtarget variable, and it does not have any effect when set in a device definition. It can only be set in a target's or subtarget's Makefile. Consequently, having it set anyway is misleading, so this drops all cases. This effectively reverts the following commits: 7a1497f

[OpenWrt-Devel] [PATCH 0/3] treewide: tidy up use of DEVICE_TYPE

2020-05-29 Thread Adrian Schmutzler
Trigger by the recent patch from Linus Walleij, I take up the problem of inconsistent use of DEVICE_TYPE in OpenWrt. This has already been partially discussed here: http://lists.infradead.org/pipermail/openwrt-devel/2020-February/021809.html Effectively, DEVICE_TYPE currently is a per-target varia

Re: [OpenWrt-Devel] [PATCH v13] ath10k: add LED and GPIO controlling support for various chipsets

2020-05-29 Thread Kalle Valo
Sven Eckelmann writes: > On Monday, 25 May 2020 11:22:13 CEST Sven Eckelmann wrote: > [...] >> And it still can with this OpenWrt version. But it doesn't seem to happen >> with >> the most recent OpenWrt reboot-13353-gb1604b744b. But there are nearly 4000 >> commits inbetween. So no idea what

Re: [OpenWrt-Devel] [PATCH] build: reflect DEVICE_TYPE to top level config

2020-05-29 Thread mail
> -Original Message- > From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org] > On Behalf Of Linus Walleij > Sent: Freitag, 29. Mai 2020 14:21 > To: openwrt-devel@lists.openwrt.org > Cc: Linus Walleij > Subject: [OpenWrt-Devel] [PATCH] build: reflect DEVICE_TYPE to top level

[OpenWrt-Devel] [PATCH] build: reflect DEVICE_TYPE to top level config

2020-05-29 Thread Linus Walleij
I made a patch to select a tool inside busybox by default on NAS type boxes, but this does not properly work because the package and image build processes are cleanly separate entities. I also noticed that this becomes a problem if you build multiple profiles: maybe one of them is NAS and one of t

[OpenWrt-Devel] Reset button on TL-WR802N v1

2020-05-29 Thread mail
Hi, we suspect that the Reset button on the old TL-WR802N v1 is configured to the wrong GPIO [1]. If somebody owns this device, it would be helpful to report whether 1. reset works ouf the box 2. if not, it works with GPIO 12 active_low [1] https://github.com/openwrt/openwrt/pull/3058 Best Ad

Re: [OpenWrt-Devel] add support for netgear R6020

2020-05-29 Thread mail
Hi, > -Original Message- > From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org] > On Behalf Of Evan Jobling > Sent: Freitag, 29. Mai 2020 06:45 > To: openwrt-devel@lists.openwrt.org > Subject: [OpenWrt-Devel] add support for netgear R6020 > > Hi All. > > Apologies if this