[LEDE-DEV] [PATCH] procd: add cancel_timeout on rc scripts when a runtime_timeout is specified

2017-02-09 Thread Jurgen Van Ham 
Enable procd to restrict the execution time of a rc scripts during shutdown, 
even
when a script ignores the SIGTERM signal by insisting after 10s with a SIGKILL.


Signed-off-by: Jurgen Van Ham 
---
file /etc/rc.d/K01test reproduces the problem that this patch addresses.
 #!/bin/sh
 h_sigterm() { 
   echo $0 SIGTERM > /dev/console
 }

 stop() {
   local x=0
   while true; do
 x=$(($x+1))
 echo $0 PING $x > /dev/console
 sleep 1
done
 }

 trap h_sigterm SIGTERM
 case "$1" in
   stop|shutdown)
stop
;;
 esac
creating the above file results in a board that cannot complete the 'reboot' 
command.

 rcS.c |4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/rcS.c b/rcS.c
index 1e38d39..0208a75 100644
--- a/rcS.c
+++ b/rcS.c
@@ -121,8 +121,10 @@ static void add_initd(struct runqueue *q, char *file, char 
*param)
}
s->proc.task.type = _type;
s->proc.task.complete = q_initd_complete;
-   if (!strcmp(param, "stop") || !strcmp(param, "shutdown"))
+   if (!strcmp(param, "stop") || !strcmp(param, "shutdown")) {
s->proc.task.run_timeout = 15000;
+   s->proc.task.cancel_timeout = 1;
+   }
s->param = p;
s->file = f;
strcpy(s->param, param);
-- 
1.7.9.5


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] License for DTS files

2017-02-09 Thread John Crispin 


On 09/02/2017 18:18, Rafał Miłecki wrote:
> On 3 February 2017 at 12:29, Rafał Miłecki  wrote:
>> In LEDE we have quite a lot of DTS files that hasn't been upstreamed.
>> They often contain no licensing info.
>>
>> Upstream Linux maintainers prefer/require clear BSD-compatible
>> license, see e.g.:
>> https://lkml.org/lkml/2016/5/4/707
>>
>> Some people may not agree such files are copyrightable at all, but
>> most of us are not layers (including upstream maintainers) so it's
>> probably just easier to specify some license and be done with it.
>>
>> Could we require/ask new DTS files added to LEDE project to use
>> BSD-compatible license? This would help upstreaming code if someone
>> decides to do that.
> 
> As Linus pointed, I shouldn't generalize, BSD-compatible license is
> clearly required/preferred by ARM maintainers, not all arch ones.
> 
> Using BSD-compatible license instead of GPL allows using the code in
> BSD systems and proprietary bootloaders. Since we're talking about DTS
> files it may be more acceptable that in case of standard drivers.
> 
> So if you're OK with that, it may be better (to simplify upstreaming
> process) to use BSD-compatible license, e.g.
> 1) BSD 3-Clause License
> 2) ISC License
> 
> If you don't want to use BSD-compatible license, we still have some
> chance to upstream GPL licensed DTS files.
> 

can you add a wiki page (or ask Richb to help doing so) which has the
text that should be used and a short text explaining why ? we can then
just point people at that wiki page when we get new dts files.

John

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] massive speed-loss using 'make defconfig'

2017-02-09 Thread Karl Palsson 
> 
> (apply some symbols)
> make defconfig
> 
> [...]
> 
> (apply some symbols)
> make defconfig
> 
> This is called up to 30 times till our '.config' is ready.
> 
> Question: is it *safe* to call 'defconfig' only at there very
> end?

That's all I've ever done. I have a little snippet of maybe 20-30
lines of config keys, and just call "make defconfig" once. It
never even entered my mind to try doing it in multiple runs.

signature.html
Description: OpenPGP Digital Signature
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

[LEDE-DEV] LEDE v17.01.0-rc2

2017-02-09 Thread Jo-Philipp Wich 
Hi,

The LEDE Community is proud to announce the second release candidate of
the upcoming LEDE 17.01 stable version series.

Main scope of this RC version is backporting important fixes and
addressing critical bugs to further refine the code base for the final
v17.01.0 version.

---

Some selected highlights since the 17.01.0-rc1 release candidate are:

  * Properly handle Curl download errors during compilation
  * Update to musl libc version 1.1.16
  * Update kernel to version 4.4.47
  * Improve Mikrotik device support on ar71xx
  * Support configuring static route protocols
  * Prevent swconfig related kernel panics on ar83x7 switches
  * Update tcpdump to address several security vulnerabilities

For a detailed list of changes refer to
https://lede-project.org/releases/17.01/changelog-17.01.0-rc2

---

Known issues:

  * There is an incompatible libubus ABI change between rc1 and rc2
so do not upgrade packages with opkg on rc1 but sysupgrade to rc2
instead

  * Available space on devices with only 4MB flash is very low,
users requiring extra packages might want to consider using the
image builder to repack custom images

  * The available memory on devices with 16MB RAM might be too low to
reliably run opkg or sysupgrade operations, especially in
conjunction with LuCI

  * Any outstanding issues reported at https://bugs.lede-project.org/

---

For latest information about the 17.01 release, refer to the wiki at:
https://lede-project.org/releases/17.01/

To download the v17.01.0-rc2 images, navigate to:
https://downloads.lede-project.org/releases/17.01.0-rc2/

---

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

Have fun!

The LEDE Community


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev



signature.asc
Description: OpenPGP digital signature
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [PATCH v2] ramips: add support for RATOC REX-WIFISD2

2017-02-09 Thread Rafał Miłecki 
On 9 February 2017 at 15:13, John Crispin  wrote:
> On 28/01/2017 17:03, FUKAUMI Naoki wrote:
>> diff --git a/target/linux/ramips/dts/REX-WIFISD2.dts 
>> b/target/linux/ramips/dts/REX-WIFISD2.dts
>> new file mode 100644
>> index 000..4d8819a
>> --- /dev/null
>> +++ b/target/linux/ramips/dts/REX-WIFISD2.dts
>> @@ -0,0 +1,148 @@
>> +/dts-v1/;
>> +
>> +#include "mt7620a.dtsi"
>> +
>> +#include 
>> +#include 

Please specify license for this file. If possible, BSD-compatible one
may be easier to work with in the future. See my recent request:
http://lists.infradead.org/pipermail/lede-dev/2017-February/005842.html

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] License for DTS files

2017-02-09 Thread Rafał Miłecki 
On 3 February 2017 at 12:29, Rafał Miłecki  wrote:
> In LEDE we have quite a lot of DTS files that hasn't been upstreamed.
> They often contain no licensing info.
>
> Upstream Linux maintainers prefer/require clear BSD-compatible
> license, see e.g.:
> https://lkml.org/lkml/2016/5/4/707
>
> Some people may not agree such files are copyrightable at all, but
> most of us are not layers (including upstream maintainers) so it's
> probably just easier to specify some license and be done with it.
>
> Could we require/ask new DTS files added to LEDE project to use
> BSD-compatible license? This would help upstreaming code if someone
> decides to do that.

As Linus pointed, I shouldn't generalize, BSD-compatible license is
clearly required/preferred by ARM maintainers, not all arch ones.

Using BSD-compatible license instead of GPL allows using the code in
BSD systems and proprietary bootloaders. Since we're talking about DTS
files it may be more acceptable that in case of standard drivers.

So if you're OK with that, it may be better (to simplify upstreaming
process) to use BSD-compatible license, e.g.
1) BSD 3-Clause License
2) ISC License

If you don't want to use BSD-compatible license, we still have some
chance to upstream GPL licensed DTS files.

-- 
Rafał

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] massive speed-loss using 'make defconfig'

2017-02-09 Thread Bastian Bittorf 
* Bastian Bittorf  [09.02.2017 17:45]:
> is 'make menuconfig' also using 'package-metadata.pl'?
> 
> I ask, because start 'menuconfig' and selecting/unselecting
> symbols with the GUI is very fast, but the same operation - is'nt it?

i will answer the question myself: it is not.
defconfig must be called after working with 'menuconfig'.

maybe you have an idea, how we can speedup our workflow:


echo  >.config 'CONFIG_TARGET_ar71xx=y'
echo >>.config 'CONFIG_TARGET_ar71xx_generic=y'
make defconfig

(apply some symbols)
make defconfig

[...]

(apply some symbols)
make defconfig

This is called up to 30 times till our '.config' is ready.

Question: is it *safe* to call 'defconfig' only at there very end?

bye, bastian

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [PATCH 1/2] mac80211: backport upstream fix for CSA in IBSS mode

2017-02-09 Thread Koen Vandeputte 

Patch got accepted upstream.

https://git.kernel.org/cgit/linux/kernel/git/jberg/mac80211-next.git/commit/?id=f181d6a3bcc35633facf5f3925699021c13492c5


On 2017-02-08 16:11, Koen Vandeputte wrote:

Allows to change channels on-the-fly using CSA when using IBSS.

Signed-off-by: Koen Vandeputte 
---

fyi: Fix is still awaiting upstream approval


  .../320-mac80211-fix-CSA-in-IBSS-mode.patch| 34 ++
  1 file changed, 34 insertions(+)
  create mode 100644 
package/kernel/mac80211/patches/320-mac80211-fix-CSA-in-IBSS-mode.patch

diff --git 
a/package/kernel/mac80211/patches/320-mac80211-fix-CSA-in-IBSS-mode.patch 
b/package/kernel/mac80211/patches/320-mac80211-fix-CSA-in-IBSS-mode.patch
new file mode 100644
index 000..13765b2
--- /dev/null
+++ b/package/kernel/mac80211/patches/320-mac80211-fix-CSA-in-IBSS-mode.patch
@@ -0,0 +1,34 @@
+From: Koen Vandeputte 
+Date: Wed, 8 Feb 2017 15:29:45 +0100
+Subject: [PATCH] mac80211: fix CSA in IBSS mode
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+Add the missing IBSS capability flag during capability init as it needs
+to be inserted into the generated beacon in order for CSA to work.
+
+Signed-off-by: Piotr Gawlowicz 
+Signed-off-by: Mikołaj Chwalisz 
+Tested-by: Koen Vandeputte 
+---
+
+--- a/net/mac80211/ibss.c
 b/net/mac80211/ibss.c
+@@ -487,14 +487,14 @@ int ieee80211_ibss_csa_beacon(struct iee
+   struct beacon_data *presp, *old_presp;
+   struct cfg80211_bss *cbss;
+   const struct cfg80211_bss_ies *ies;
+-  u16 capability = 0;
++  u16 capability = WLAN_CAPABILITY_IBSS;
+   u64 tsf;
+   int ret = 0;
+
+   sdata_assert_lock(sdata);
+
+   if (ifibss->privacy)
+-  capability = WLAN_CAPABILITY_PRIVACY;
++  capability |= WLAN_CAPABILITY_PRIVACY;
+
+   cbss = cfg80211_get_bss(sdata->local->hw.wiphy, ifibss->chandef.chan,
+   ifibss->bssid, ifibss->ssid,


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [PATCH] procd: stop service using SIGKILL if SIGTERM failed to do so

2017-02-09 Thread John Crispin 


On 09/02/2017 12:43, Alin Năstac wrote:
> On Thu, Feb 9, 2017 at 11:54 AM, John Crispin  wrote:
>> Hi,
>>
>> i know that someone else is about to send a fix for the same issue but
>> with a different approach of fixing it. i'd like to wait for this 2nd
>> patch to arrive before we decide which to merge
> Are you sure it wasn't me? :)
> You said yesterday that I should send you a patch for it.
> 
> The only other approach I could think of would involve a
> instance_stop() that waits for the service instance to exit.
> I thought initially to do it like this, but decided that waiting
> asynchronously for stop event would be a fer better technical solution
> to the given issue, don't you agree?
> 
>>
>> John
>>
> 
> Alin
> 

Hans just told me we are talking about 2 different issues, so there is
no 2nd patch, i'll process this one as normal in that case

John

> ___
> Lede-dev mailing list
> Lede-dev@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev
> 

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [PATCH] procd: stop service using SIGKILL if SIGTERM failed to do so

2017-02-09 Thread Alin Năstac 
On Thu, Feb 9, 2017 at 11:54 AM, John Crispin  wrote:
> Hi,
>
> i know that someone else is about to send a fix for the same issue but
> with a different approach of fixing it. i'd like to wait for this 2nd
> patch to arrive before we decide which to merge
Are you sure it wasn't me? :)
You said yesterday that I should send you a patch for it.

The only other approach I could think of would involve a
instance_stop() that waits for the service instance to exit.
I thought initially to do it like this, but decided that waiting
asynchronously for stop event would be a fer better technical solution
to the given issue, don't you agree?

>
> John
>

Alin

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [PATCH] procd: stop service using SIGKILL if SIGTERM failed to do so

2017-02-09 Thread John Crispin 
Hi,

i know that someone else is about to send a fix for the same issue but
with a different approach of fixing it. i'd like to wait for this 2nd
patch to arrive before we decide which to merge

John

On 09/02/2017 11:02, Alin Nastac wrote:
> SIGKILL is sent if instance process is still running after
>  seconds after SIGTERM has been sent. To prevent
> another daemon process being launched before old process dies,
> the instance is kept until SIGCHLD confirms that service has
> been stopped.
> 
> Signed-off-by: Alin Nastac 
> ---
>  service/instance.c | 44 +---
>  service/instance.h |  1 +
>  service/service.c  | 26 --
>  service/service.h  |  3 +++
>  4 files changed, 57 insertions(+), 17 deletions(-)
> 
> diff --git a/service/instance.c b/service/instance.c
> index 018db3c..4d340fd 100644
> --- a/service/instance.c
> +++ b/service/instance.c
> @@ -55,6 +55,7 @@ enum {
>   INSTANCE_ATTR_SECCOMP,
>   INSTANCE_ATTR_PIDFILE,
>   INSTANCE_ATTR_RELOADSIG,
> + INSTANCE_ATTR_TERMTIMEOUT,
>   __INSTANCE_ATTR_MAX
>  };
>  
> @@ -79,6 +80,7 @@ static const struct blobmsg_policy 
> instance_attr[__INSTANCE_ATTR_MAX] = {
>   [INSTANCE_ATTR_SECCOMP] = { "seccomp", BLOBMSG_TYPE_STRING },
>   [INSTANCE_ATTR_PIDFILE] = { "pidfile", BLOBMSG_TYPE_STRING },
>   [INSTANCE_ATTR_RELOADSIG] = { "reload_signal", BLOBMSG_TYPE_INT32 },
> + [INSTANCE_ATTR_TERMTIMEOUT] = { "term_timeout", BLOBMSG_TYPE_INT32 },
>  };
>  
>  enum {
> @@ -389,8 +391,16 @@ instance_start(struct service_instance *in)
>   return;
>   }
>  
> - if (in->proc.pending || !in->command)
> + if (!in->command) {
> + LOG("Not starting instance %s::%s, command not set\n", 
> in->srv->name, in->name);
>   return;
> + }
> +
> + if (in->proc.pending) {
> + if (in->halt)
> + in->restart = true;
> + return;
> + }
>  
>   instance_free_stdio(in);
>   if (in->_stdout.fd.fd > -2) {
> @@ -408,7 +418,7 @@ instance_start(struct service_instance *in)
>   }
>  
>   in->restart = false;
> - in->halt = !in->respawn;
> + in->halt = false;
>  
>   if (!in->valid)
>   return;
> @@ -494,7 +504,11 @@ instance_timeout(struct uloop_timeout *t)
>  
>   in = container_of(t, struct service_instance, timeout);
>  
> - if (!in->halt && (in->restart || in->respawn))
> + if (in->halt) {
> + LOG("Instance %s::%s pid %d not stopped on SIGTERM, sending 
> SIGKILL instead\n",
> + in->srv->name, in->name, in->proc.pid);
> + kill(in->proc.pid, SIGKILL);
> + } else if (in->restart || in->respawn)
>   instance_start(in);
>  }
>  
> @@ -515,8 +529,19 @@ instance_exit(struct uloop_process *p, int ret)
>   return;
>  
>   uloop_timeout_cancel(>timeout);
> + service_event("instance.stop", in->srv->name, in->name);
> +
>   if (in->halt) {
>   instance_removepid(in);
> + if (in->restart)
> + instance_start(in);
> + else {
> + struct service *s = in->srv;
> +
> + avl_delete(>instances.avl, >node.avl);
> + instance_free(in);
> + service_stopped(s);
> + }
>   } else if (in->restart) {
>   instance_start(in);
>   } else if (in->respawn) {
> @@ -535,7 +560,6 @@ instance_exit(struct uloop_process *p, int ret)
>   uloop_timeout_set(>timeout, in->respawn_timeout * 
> 1000);
>   }
>   }
> - service_event("instance.stop", in->srv->name, in->name);
>  }
>  
>  void
> @@ -546,6 +570,7 @@ instance_stop(struct service_instance *in)
>   in->halt = true;
>   in->restart = in->respawn = false;
>   kill(in->proc.pid, SIGTERM);
> + uloop_timeout_set(>timeout, in->term_timeout * 1000);
>  }
>  
>  static void
> @@ -559,10 +584,10 @@ instance_restart(struct service_instance *in)
>   return;
>   }
>  
> - in->halt = false;
> + in->halt = true;
>   in->restart = true;
>   kill(in->proc.pid, SIGTERM);
> - instance_removepid(in);
> + uloop_timeout_set(>timeout, in->term_timeout * 1000);
>  }
>  
>  static bool
> @@ -796,6 +821,8 @@ instance_config_parse(struct service_instance *in)
>   if (!instance_config_parse_command(in, tb))
>   return false;
>  
> + if (tb[INSTANCE_ATTR_TERMTIMEOUT])
> + in->term_timeout = 
> blobmsg_get_u32(tb[INSTANCE_ATTR_TERMTIMEOUT]);
>   if (tb[INSTANCE_ATTR_RESPAWN]) {
>   int i = 0;
>   uint32_t vals[3] = { 3600, 5, 5};
> @@ -933,8 +960,9 @@ instance_update(struct service_instance *in, struct 
> service_instance *in_new)
>  {
>   bool changed = instance_config_changed(in, in_new);
>   bool running =

[LEDE-DEV] [PATCH] procd: stop service using SIGKILL if SIGTERM failed to do so

2017-02-09 Thread Alin Nastac 
SIGKILL is sent if instance process is still running after
 seconds after SIGTERM has been sent. To prevent
another daemon process being launched before old process dies,
the instance is kept until SIGCHLD confirms that service has
been stopped.

Signed-off-by: Alin Nastac 
---
 service/instance.c | 44 +---
 service/instance.h |  1 +
 service/service.c  | 26 --
 service/service.h  |  3 +++
 4 files changed, 57 insertions(+), 17 deletions(-)

diff --git a/service/instance.c b/service/instance.c
index 018db3c..4d340fd 100644
--- a/service/instance.c
+++ b/service/instance.c
@@ -55,6 +55,7 @@ enum {
INSTANCE_ATTR_SECCOMP,
INSTANCE_ATTR_PIDFILE,
INSTANCE_ATTR_RELOADSIG,
+   INSTANCE_ATTR_TERMTIMEOUT,
__INSTANCE_ATTR_MAX
 };
 
@@ -79,6 +80,7 @@ static const struct blobmsg_policy 
instance_attr[__INSTANCE_ATTR_MAX] = {
[INSTANCE_ATTR_SECCOMP] = { "seccomp", BLOBMSG_TYPE_STRING },
[INSTANCE_ATTR_PIDFILE] = { "pidfile", BLOBMSG_TYPE_STRING },
[INSTANCE_ATTR_RELOADSIG] = { "reload_signal", BLOBMSG_TYPE_INT32 },
+   [INSTANCE_ATTR_TERMTIMEOUT] = { "term_timeout", BLOBMSG_TYPE_INT32 },
 };
 
 enum {
@@ -389,8 +391,16 @@ instance_start(struct service_instance *in)
return;
}
 
-   if (in->proc.pending || !in->command)
+   if (!in->command) {
+   LOG("Not starting instance %s::%s, command not set\n", 
in->srv->name, in->name);
return;
+   }
+
+   if (in->proc.pending) {
+   if (in->halt)
+   in->restart = true;
+   return;
+   }
 
instance_free_stdio(in);
if (in->_stdout.fd.fd > -2) {
@@ -408,7 +418,7 @@ instance_start(struct service_instance *in)
}
 
in->restart = false;
-   in->halt = !in->respawn;
+   in->halt = false;
 
if (!in->valid)
return;
@@ -494,7 +504,11 @@ instance_timeout(struct uloop_timeout *t)
 
in = container_of(t, struct service_instance, timeout);
 
-   if (!in->halt && (in->restart || in->respawn))
+   if (in->halt) {
+   LOG("Instance %s::%s pid %d not stopped on SIGTERM, sending 
SIGKILL instead\n",
+   in->srv->name, in->name, in->proc.pid);
+   kill(in->proc.pid, SIGKILL);
+   } else if (in->restart || in->respawn)
instance_start(in);
 }
 
@@ -515,8 +529,19 @@ instance_exit(struct uloop_process *p, int ret)
return;
 
uloop_timeout_cancel(>timeout);
+   service_event("instance.stop", in->srv->name, in->name);
+
if (in->halt) {
instance_removepid(in);
+   if (in->restart)
+   instance_start(in);
+   else {
+   struct service *s = in->srv;
+
+   avl_delete(>instances.avl, >node.avl);
+   instance_free(in);
+   service_stopped(s);
+   }
} else if (in->restart) {
instance_start(in);
} else if (in->respawn) {
@@ -535,7 +560,6 @@ instance_exit(struct uloop_process *p, int ret)
uloop_timeout_set(>timeout, in->respawn_timeout * 
1000);
}
}
-   service_event("instance.stop", in->srv->name, in->name);
 }
 
 void
@@ -546,6 +570,7 @@ instance_stop(struct service_instance *in)
in->halt = true;
in->restart = in->respawn = false;
kill(in->proc.pid, SIGTERM);
+   uloop_timeout_set(>timeout, in->term_timeout * 1000);
 }
 
 static void
@@ -559,10 +584,10 @@ instance_restart(struct service_instance *in)
return;
}
 
-   in->halt = false;
+   in->halt = true;
in->restart = true;
kill(in->proc.pid, SIGTERM);
-   instance_removepid(in);
+   uloop_timeout_set(>timeout, in->term_timeout * 1000);
 }
 
 static bool
@@ -796,6 +821,8 @@ instance_config_parse(struct service_instance *in)
if (!instance_config_parse_command(in, tb))
return false;
 
+   if (tb[INSTANCE_ATTR_TERMTIMEOUT])
+   in->term_timeout = 
blobmsg_get_u32(tb[INSTANCE_ATTR_TERMTIMEOUT]);
if (tb[INSTANCE_ATTR_RESPAWN]) {
int i = 0;
uint32_t vals[3] = { 3600, 5, 5};
@@ -933,8 +960,9 @@ instance_update(struct service_instance *in, struct 
service_instance *in_new)
 {
bool changed = instance_config_changed(in, in_new);
bool running = in->proc.pending;
+   bool stopping = in->halt;
 
-   if (!running) {
+   if (!running || stopping) {
instance_config_move(in, in_new);
instance_start(in);
} else {
@@ -967,6 +995,7 @@ instance_init(struct service_instance *in, struct service 
*s, struct blob_attr *
in->config = config;
in->timeout.cb =

Re: [LEDE-DEV] [PATCH] ar71xx: Support for TP-LINK MR6400

2017-02-09 Thread Sven Eckelmann 
On Donnerstag, 9. Februar 2017 10:32:37 CET Filip Moc wrote:
> On Thu, Feb 09, 2017 at 09:40:31AM +0100, John Crispin wrote:
> > Hi,
> > 
> > there should be a "Signed-off-by:" line here. please resend the patch
> > with the line added.
[...]
> Actually there was "Signed-off-by:" line in my original email.
> If you look here 
> https://lists.infradead.org/pipermail/lede-dev/2017-February/005728.html
> you can see it's really there. Perhaps some patchwork's magic cut it off.
> 
> But anyway I wanted to make v2 since there are few things I wanted to fix.
> Hope I make it right with "Signed-off-by:" line this time.

Looks to me like you mixed up the basic structure of the commit message body
when sending patches via mail. Let's just have a look at it

From 2a930f515c38069c2e57ef76f0ffe0d8e2ab115a Mon Sep 17 00:00:00 2001
From: Filip Moc 
Date: Sat, 4 Feb 2017 14:37:08 +0100
Subject: [LEDE-DEV] [PATCH] ar71xx: Support for TP-LINK MR6400

This part belongs in the the mail body. It should be in the mail headers

Add support for TP-Link MR6400

Everything seems to be working.
You can flash via u-boot tftp (serve factory image as 
/mr6400_tp_recovery.bin
on 192.168.0.66/24, connect to any ethernet port and power on device while
holding the reset button).

File ar71xx/base-files/etc/init.d/enablemodem is based on
ramips/base-files/etc/init.d/enablemodem. Code of enablemodem does not seem
to be platform specific and I think it should be shared.
I suggest merging these files and moving result to adb package.
Another question is how to get board info.
Maybe from `cat /tmp/sysinfo/board_name` or from '/etc/board.json'?

This is a little bit strange commit message. Maybe you wanted to put this in
the cover letter for this patch? The cover letter should have been sent
separately and the patch as reply to the cover letter.

-- 
2.1.4

Here you end something? The cover letter? See above why this is wrong here.

From 2a930f515c38069c2e57ef76f0ffe0d8e2ab115a Mon Sep 17 00:00:00 2001
From: Filip Moc 
Date: Sat, 4 Feb 2017 10:31:06 +0100
Subject: [PATCH] Add support for TL-MR6400

Again, the from, date and Subject should be in the mail header and not the
mail body.

Signed-off-by: Filip Moc 
---

The Signed-off-by: Line is after a ---. So every git tool will have ignored
it (including helper tools like patchwork).

You should check out git-send-email or use "mutt -H" for sending patches [1]

Kind regards,
Sven

[1] https://kernel.org/doc/html/latest/process/email-clients.html#mutt-tui


signature.asc
Description: This is a digitally signed message part.
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [PATCH] ar71xx: Support for TP-LINK MR6400

2017-02-09 Thread Filip Moc 
On Thu, Feb 09, 2017 at 09:40:31AM +0100, John Crispin wrote:
> Hi,
> 
> there should be a "Signed-off-by:" line here. please resend the patch
> with the line added.
> 
>   John

Hi John,

thank you for your response.

Actually there was "Signed-off-by:" line in my original email.
If you look here 
https://lists.infradead.org/pipermail/lede-dev/2017-February/005728.html
you can see it's really there. Perhaps some patchwork's magic cut it off.

But anyway I wanted to make v2 since there are few things I wanted to fix.
Hope I make it right with "Signed-off-by:" line this time.

Filip



___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

[LEDE-DEV] [PATCH mdns] Send A(AAA) records when announcing

2017-02-09 Thread Rafał Miłecki 
From: Rafał Miłecki 

This allows device to be discovered by its local hostname.

Signed-off-by: Rafał Miłecki 
---
 announce.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/announce.c b/announce.c
index 03c7b8f..ad129c0 100644
--- a/announce.c
+++ b/announce.c
@@ -66,6 +66,7 @@ announce_timer(struct uloop_timeout *timeout)
 
case STATE_ANNOUNCE:
service_announce(iface, announce_ttl);
+   dns_reply_a(iface, announce_ttl);
uloop_timeout_set(timeout, announce_ttl * 800);
break;
}
-- 
2.11.0


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [PATCH] ar71xx: Support for TP-LINK MR6400

2017-02-09 Thread John Crispin 


On 04/02/2017 14:54, Filip Moc wrote:
> From 2a930f515c38069c2e57ef76f0ffe0d8e2ab115a Mon Sep 17 00:00:00 2001
> From: Filip Moc 
> Date: Sat, 4 Feb 2017 14:37:08 +0100
> Subject: [LEDE-DEV] [PATCH] ar71xx: Support for TP-LINK MR6400
> 
> Add support for TP-Link MR6400
> 
> Everything seems to be working.
> You can flash via u-boot tftp (serve factory image as /mr6400_tp_recovery.bin
> on 192.168.0.66/24, connect to any ethernet port and power on device while
> holding the reset button).
> 
> File ar71xx/base-files/etc/init.d/enablemodem is based on
> ramips/base-files/etc/init.d/enablemodem. Code of enablemodem does not seem
> to be platform specific and I think it should be shared.
> I suggest merging these files and moving result to adb package.
> Another question is how to get board info.
> Maybe from `cat /tmp/sysinfo/board_name` or from '/etc/board.json'?
> 


Hi,

there should be a "Signed-off-by:" line here. please resend the patch
with the line added.

John

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] ar71xx: support for Zyxel NWA1121-NI (updated)

2017-02-09 Thread John Crispin 


On 01/02/2017 09:51, alexpro wrote:
> Hi,
> 
> This is updated patch for Zyxel NWA1121-NI support:
> 
> - added files, forgotten last time
> - cleaned up the patch
> - updated ar71xx.sh, platform.sh
> - checked sysupgrade - works
> 
> 
> 
> From d7372b409d6c69781f147949a511e61f539dbf2f Mon Sep 17 00:00:00 2001
> From: Alex Prokofiev 
> Date: Wed, 25 Jan 2017 21:42:38 +0300
> Subject: [PATCH] Support for Zyxel NWA1121-NI
> 
> Signed-off-by: Alex Prokofiev 
> ---
>  target/linux/ar71xx/base-files/lib/ar71xx.sh   |   3 +
>  .../ar71xx/base-files/lib/upgrade/platform.sh  |   6 +-
>  .../ar71xx/files/arch/mips/ath79/Kconfig.openwrt   |  12 +++
>  target/linux/ar71xx/files/arch/mips/ath79/Makefile |   1 +
>  .../ar71xx/files/arch/mips/ath79/mach-nwa1121.c| 105
> +



Hi,

if you look here ->
   https://patchwork.ozlabs.org/patch/722388/

You'll see that the patch got mangled when patchwork picked it up. this
happened as your mail client line wrapped the patch. try using "git
send-email" to avoid these issues.

John

>  .../linux/ar71xx/files/arch/mips/ath79/machtypes.h |   1 +
>  target/linux/ar71xx/image/generic.mk   |  12 +++
>  7 files changed, 138 insertions(+), 2 deletions(-)
>  create mode 100644
> target/linux/ar71xx/files/arch/mips/ath79/mach-nwa1121.c
> 
> diff --git a/target/linux/ar71xx/base-files/lib/ar71xx.sh
> b/target/linux/ar71xx/base-files/lib/ar71xx.sh
> index ad73ec1520..f81b4e4e46 100755
> --- a/target/linux/ar71xx/base-files/lib/ar71xx.sh
> +++ b/target/linux/ar71xx/base-files/lib/ar71xx.sh
> @@ -1235,6 +1235,9 @@ ar71xx_board_detect() {
>  *"HiWiFi HC6361")
>  name="hiwifi-hc6361"
>  ;;
> +*"ZYXEL NWA1121")
> +name="nwa1121"
> +;;
>  esac
> 
>  [ -z "$AR71XX_MODEL" ] && [ "${machine:0:8}" = 'TP-LINK ' ] && \
> diff --git a/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
> b/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
> index e0ba5d37ff..1651363cb1 100755
> --- a/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
> +++ b/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
> @@ -344,7 +344,8 @@ platform_check_image() {
>  routerstation-pro|\
>  routerstation|\
>  wp543|\
> -wpe72)
> +wpe72|\
> +nwa1121)
>  [ "$magic" != "4349" ] && {
>  echo "Invalid image. Use *-sysupgrade.bin files on this board"
>  return 1
> @@ -643,7 +644,8 @@ platform_do_upgrade() {
>  local board=$(ar71xx_board_name)
> 
>  case "$board" in
> -rb-941-2nd)
> +rb-941-2nd|\
> +nwa1121)
>  PLATFORM_DO_UPGRADE_COMBINED_SEPARATE_MTD=1
>  platform_do_upgrade_combined "$ARGV"
>  ;;
> diff --git a/target/linux/ar71xx/files/arch/mips/ath79/Kconfig.openwrt
> b/target/linux/ar71xx/files/arch/mips/ath79/Kconfig.openwrt
> index c3f958869e..62abf6c143 100644
> --- a/target/linux/ar71xx/files/arch/mips/ath79/Kconfig.openwrt
> +++ b/target/linux/ar71xx/files/arch/mips/ath79/Kconfig.openwrt
> @@ -1888,3 +1888,15 @@ config ATH79_MACH_TL_WPA8630
>  select ATH79_DEV_LEDS_GPIO
>  select ATH79_DEV_M25P80
>  select ATH79_DEV_WMAC
> +
> +config ATH79_MACH_NWA1121
> +bool "Zyxel NWA1121 support"
> +select SOC_AR934X
> +select ATH79_DEV_AP9X_PCI if PCI
> +select ATH79_DEV_ETH
> +select ATH79_DEV_GPIO_BUTTONS
> +select ATH79_DEV_LEDS_GPIO
> +select ATH79_DEV_M25P80
> +select ATH79_DEV_USB
> +select ATH79_DEV_WMAC
> +select ATH79_NVRAM
> diff --git a/target/linux/ar71xx/files/arch/mips/ath79/Makefile
> b/target/linux/ar71xx/files/arch/mips/ath79/Makefile
> index ac0bbc46bf..01ba23742a 100644
> --- a/target/linux/ar71xx/files/arch/mips/ath79/Makefile
> +++ b/target/linux/ar71xx/files/arch/mips/ath79/Makefile
> @@ -232,3 +232,4 @@ obj-$(CONFIG_ATH79_MACH_XD3200)+=
> mach-sr3200.o
>  obj-$(CONFIG_ATH79_MACH_Z1)+= mach-z1.o
>  obj-$(CONFIG_ATH79_MACH_ZBT_WE1526)+= mach-zbt-we1526.o
>  obj-$(CONFIG_ATH79_MACH_ZCN_1523H)+= mach-zcn-1523h.o
> +obj-$(CONFIG_ATH79_MACH_NWA1121)+= mach-nwa1121.o
> diff --git a/target/linux/ar71xx/files/arch/mips/ath79/mach-nwa1121.c
> b/target/linux/ar71xx/files/arch/mips/ath79/mach-nwa1121.c
> new file mode 100644
> index 00..f52662920c
> --- /dev/null
> +++ b/target/linux/ar71xx/files/arch/mips/ath79/mach-nwa1121.c
> @@ -0,0 +1,105 @@
> +/*
> + *  Zyxel NWA1121-NI support
> + *  Alex Prokofiev 
> + *
> + *  This program is free software; you can redistribute it and/or
> modify it
> + *  under the terms of the GNU General Public License version 2 as
> published
> + *  by the Free Software Foundation.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +
> +#include "common.h"
> +#include "dev-ap9x-pci.h"
> +#include "dev-eth.h"
> +#include "dev-gpio-buttons.h"
> +#include "dev-leds-gpio.h"
>