Re: [LEDE-DEV] undefined reference to `memmove' caused by __builtin_memmove()

[Felix Fietkau]

On 2017-02-20 15:10, Mehrtens, Hauke wrote:
> When I compile MIPS malta with the LEDE patches on kernel 4.9 I get this 
> error in the kernel build:
> 
>   CC  arch/mips/boot/compressed/decompress.o
>   OBJCOPY arch/mips/boot/compressed/vmlinux.bin
>   XZKERN  arch/mips/boot/compressed/vmlinux.bin.z
>   OBJCOPY arch/mips/boot/compressed/piggy.o
>   LD  vmlinuz
> arch/mips/boot/compressed/decompress.o: In function `lzma2_lzma':
> /tmp2/mehrtens/linux/arch/mips/boot/compressed/../../../../lib/xz/xz_dec_lzma2.c:884:
>  undefined reference to `memmove'
> make[1]: *** [vmlinuz] Error 1
> make: *** [vmlinuz] Error 2 
> 
> This is caused by this option selected in the MIPS Malta target: 
> SYS_SUPPORTS_ZBOOT 
> 
> This is caused by this patch from LEDE:
> https://git.lede-project.org/?p=source.git;a=blob;f=target/linux/generic/patches-4.9/306-mips_mem_functions_performance.patch
> This was initially committed here:
> https://git.lede-project.org/?p=source.git;a=commitdiff;h=07e59c7bc7f375f792ec9734be42fe4fa391a8bb
I've pushed a fix to my staging tree, please test.

> When I remove the "#define memmove ..." from the string.h it works
> for me, I also checked the GCC documentation and it does not list
> __builtin_memmove() as an official interface here:
> https://gcc.gnu.org/onlinedocs/gcc/Other-Builtins.html
There's nothing wrong with __builtin_memmove or the function references
that it generates. The problem lies within decompress_unxz.c:

#ifndef memmove
/* Not static to avoid a conflict with the prototype in the Linux
headers. */
void *memmove(void *dest, const void *src, size_t size)
{
...
}
#endif

Since the patch adds a #define to string.h, the the custom memmove
function no longer gets emitted, and gcc generates references to it
through __builtin_memmove

> I would like to remove the optimization for memmove as it uses an unofficial 
> GCC API.
It is used in quite a few places, and I it's safe to rely on it.

> The problem is that I do not fully understand this patch and it is not good 
> documented. 
> Why are the __buildin_ functions only called when the length is *not* a 
> __builtin_constant_p() or smaller than 64 bytes?
The length >= 64 check (to force gcc not to inline larger copies) can
only be guaranteed to run at compile time if the pointer is constant.
If it's not constant, the decision on whether to inline it or not is
left to gcc.

> Doesn't the compiler automatically replaces a call to memcpy() and similar 
> functions with the build in version when he things it is good to do so?
When I first added the patch, there were some issues with that. I don't
know if there are any corner cases with current gcc, but the code should
be safe the way it is.

- Felix



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

Re: [LEDE-DEV] Adding new people in patchwork?

[Florian Fainelli]

On 02/27/2017 09:55 PM, John Crispin wrote:
> 
> 
> On 27/02/2017 23:59, Florian Fainelli wrote:
>> On 01/15/2017 09:58 AM, Florian Fainelli wrote:
>>>
>>>
>>> On 01/15/2017 05:45 AM, John Crispin wrote:


 On 15/01/2017 05:22, Florian Fainelli wrote:
> Hi,
>
> How do we get new people added to the delegation list in patchwork?
>
> Thanks!
>

 whats your userid ?
>>
>> Where you able to get this done by Jeremy @ ozlabs?
>>
>> Do we have a way to easily add new members to specific projects with
>> requiring the help from the larger patchwork instance administrator?
>>
> 
> i did for luka but you never sent me your username. i pinged you on IRC
> but got no feedback. adding people is trivial, tell me your username and
> i ask JK to add it. takes less than 24 hours.

Attached is my original reply to your question from Jan 15th.. anyway,
just in case this did not make it, my username is ffainelli.
-- 
Florian
--- Begin Message ---
Ah h yes it is ffainelli. Thanks!

Florian

On Jan 15, 2017 10:32 AM, "John Crispin"  wrote:



On 15/01/2017 18:58, Florian Fainelli wrote:
>
>
> On 01/15/2017 05:45 AM, John Crispin wrote:
>>
>>
>> On 15/01/2017 05:22, Florian Fainelli wrote:
>>> Hi,
>>>
>>> How do we get new people added to the delegation list in patchwork?
>>>
>>> Thanks!
>>>
>>
>> whats your userid ?
>
> 2800
>
> Thanks
>

i meant username, sorry. i need to tell jeremy to bump your account

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

Re: [LEDE-DEV] Adding new people in patchwork?

[John Crispin]

On 27/02/2017 23:59, Florian Fainelli wrote:
> On 01/15/2017 09:58 AM, Florian Fainelli wrote:
>>
>>
>> On 01/15/2017 05:45 AM, John Crispin wrote:
>>>
>>>
>>> On 15/01/2017 05:22, Florian Fainelli wrote:
 Hi,

 How do we get new people added to the delegation list in patchwork?

 Thanks!

>>>
>>> whats your userid ?
> 
> Where you able to get this done by Jeremy @ ozlabs?
> 
> Do we have a way to easily add new members to specific projects with
> requiring the help from the larger patchwork instance administrator?
> 

i did for luka but you never sent me your username. i pinged you on IRC
but got no feedback. adding people is trivial, tell me your username and
i ask JK to add it. takes less than 24 hours.

John

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

[LEDE-DEV] [PATCH odhcpd] dhcpv6-ia: Check lockf return value

[Florian Fainelli]

Signed-off-by: Florian Fainelli 
---
 src/dhcpv6-ia.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/src/dhcpv6-ia.c b/src/dhcpv6-ia.c
index 888634fe1f29..fb5044884441 100644
--- a/src/dhcpv6-ia.c
+++ b/src/dhcpv6-ia.c
@@ -242,8 +242,12 @@ void dhcpv6_write_statefile(void)
int fd = open(config.dhcp_statefile, O_CREAT | O_WRONLY | 
O_CLOEXEC, 0644);
if (fd < 0)
return;
-
-   lockf(fd, F_LOCK, 0);
+   int ret;
+   ret = lockf(fd, F_LOCK, 0);
+   if (ret < 0) {
+   close(fd);
+   return;
+   }
if (ftruncate(fd, 0) < 0) {}
 
FILE *fp = fdopen(fd, "w");
-- 
2.9.3


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

Re: [LEDE-DEV] Cake SQM killing my DIR-860L - was: [17.01] Kernel: bump to 4.4.51

[Eric Luehrsen]

On 02/27/2017 03:17 PM, Stijn Segers wrote:
> Okay, so I tracked it down to cake being the culprit. When I disable the
> Cake SQM instance, no more of those traces, and no more sudden reboots.
>
> If I can help debug this, let me know - I enabled a Cake SQM instance on
> an APU2 and so far that seems to run fine.
>
> So, in short: .50/51 bump is okay.
>
> Cheers
>
> Stijn

It wasn't long ago that HFSC was causing issues with 4.4. I am not sure 
it was all worked out. I withdrew HFSC based scripts from SQM despite 
being one of a few proponents otherwise. Maybe something else in the TC 
chain is the root cause. Maybe?

Eric

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

Re: [LEDE-DEV] Problem with NFS unmounting

[Greg Oliver]

On Wed, Feb 22, 2017 at 6:05 PM, Denis Periša  wrote:
> Hi,
>
> I've been using old version of OpenWRT and umount -f works just fine.
> But some time ago it was lost.
> Does anyone know point where I could shorten check for remote accessibility?
>
> Thank you all.
>

You should mount problematic network servers (due to netwokr or
server) with soft,intr to avoid this unmountable behaviour.

-Greg

> On Thu, Feb 23, 2017 at 12:08 AM, Florian Fainelli  
> wrote:
>>
>>
>> On 02/22/2017 08:48 AM, Denis Periša wrote:
>>> Hi all,
>>>
>>> I'm having this problem long from long time ago.
>>> When NFS server is not responding which is currently case for me (and
>>> my log files go there) I cannot unmount network volume even with -f
>>> (force). Actually I think that -f don't do any change to unmount.
>>>
>>> I was kinda hoping in LEDE it will be fixed.
>>
>> This is just a common problem with NFS and Linux in general, LEDE won't
>> solve that for you.
>>
>> You may want to try lazy umount (-l) and/or read-only remount and see if
>> that helps.
>> --
>> Florian
>
> ___
> 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] Adding new people in patchwork?

[Florian Fainelli]

On 01/15/2017 09:58 AM, Florian Fainelli wrote:
> 
> 
> On 01/15/2017 05:45 AM, John Crispin wrote:
>>
>>
>> On 15/01/2017 05:22, Florian Fainelli wrote:
>>> Hi,
>>>
>>> How do we get new people added to the delegation list in patchwork?
>>>
>>> Thanks!
>>>
>>
>> whats your userid ?

Where you able to get this done by Jeremy @ ozlabs?

Do we have a way to easily add new members to specific projects with
requiring the help from the larger patchwork instance administrator?
-- 
Florian

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

[LEDE-DEV] [PATCH netifd v2] system-linux: add VXLAN support

[Matthias Schiffer]

VXLAN shares many attributes with the tunnel devices, so it is implemented
as a new tunnel type. The 'remote' attribute can be used for an unicast
peer or a multicast group.

The IANA-assigned port 4789 is used by default, instead of the non-standard
port Linux defaults to.

Signed-off-by: Matthias Schiffer 
---

Updated to use a nested JSON object for the VXLAN-specific attributes -
although one could argue that MAC address, port and "ID" aren't very
specific after all, at least I can see us using the same attributes if we
ever add L2TPv3 support to netifd...

The vxlan package in my staging tree has been updated as well.


 system-linux.c | 160 -
 system.c   |  12 +
 system.h   |  10 
 3 files changed, 181 insertions(+), 1 deletion(-)

diff --git a/system-linux.c b/system-linux.c
index f4d6c25..b57f438 100644
--- a/system-linux.c
+++ b/system-linux.c
@@ -4,6 +4,7 @@
  * Copyright (C) 2013 Jo-Philipp Wich 
  * Copyright (C) 2013 Steven Barth 
  * Copyright (C) 2014 Gioacchino Mazzurco 
+ * Copyright (C) 2017 Matthias Schiffer 
  *
  * This program is free software; you can redistribute it and/or modify
  * it under the terms of the GNU General Public License version 2
@@ -25,6 +26,7 @@
 #include 
 
 #include 
+#include 
 #include 
 
 #include 
@@ -2540,6 +2542,155 @@ failure:
 }
 #endif
 
+#ifdef IFLA_VXLAN_MAX
+static int system_add_vxlan(const char *name, const unsigned int link, struct 
blob_attr **tb, bool v6)
+{
+   struct blob_attr *tb_data[__TUNNEL_ATTR_MAX];
+   struct nl_msg *msg;
+   struct nlattr *linkinfo, *data;
+   struct ifinfomsg iim = { .ifi_family = AF_UNSPEC, };
+   struct blob_attr *cur;
+   int ret = 0;
+
+   if ((cur = tb[TUNNEL_ATTR_DATA]))
+   blobmsg_parse(vxlan_data_attr_list.params, 
__VXLAN_DATA_ATTR_MAX, tb_data,
+   blobmsg_data(cur), blobmsg_len(cur));
+   else
+   return -EINVAL;
+
+   msg = nlmsg_alloc_simple(RTM_NEWLINK, NLM_F_REQUEST | NLM_F_CREATE | 
NLM_F_EXCL);
+
+   if (!msg)
+   return -1;
+
+   nlmsg_append(msg, , sizeof(iim), 0);
+
+   nla_put_string(msg, IFLA_IFNAME, name);
+
+   if ((cur = tb_data[VXLAN_DATA_ATTR_MACADDR])) {
+   struct ether_addr *ea = ether_aton(blobmsg_get_string(cur));
+   if (!ea) {
+   ret = -EINVAL;
+   goto failure;
+   }
+
+   nla_put(msg, IFLA_ADDRESS, ETH_ALEN, ea);
+   }
+
+   if ((cur = tb[TUNNEL_ATTR_MTU])) {
+   uint32_t mtu = blobmsg_get_u32(cur);
+   nla_put_u32(msg, IFLA_MTU, mtu);
+   }
+
+   if (!(linkinfo = nla_nest_start(msg, IFLA_LINKINFO))) {
+   ret = -ENOMEM;
+   goto failure;
+   }
+
+   nla_put_string(msg, IFLA_INFO_KIND, "vxlan");
+
+   if (!(data = nla_nest_start(msg, IFLA_INFO_DATA))) {
+   ret = -ENOMEM;
+   goto failure;
+   }
+
+   if (link)
+   nla_put_u32(msg, IFLA_VXLAN_LINK, link);
+
+   if ((cur = tb_data[VXLAN_DATA_ATTR_ID])) {
+   uint32_t id = blobmsg_get_u32(cur);
+   if (id >= (1u << 24) - 1) {
+   ret = -EINVAL;
+   goto failure;
+   }
+
+   nla_put_u32(msg, IFLA_VXLAN_ID, id);
+   }
+
+   if (v6) {
+   struct in6_addr in6buf;
+   if ((cur = tb[TUNNEL_ATTR_LOCAL])) {
+   if (inet_pton(AF_INET6, blobmsg_data(cur), ) < 
1) {
+   ret = -EINVAL;
+   goto failure;
+   }
+   nla_put(msg, IFLA_VXLAN_LOCAL6, sizeof(in6buf), 
);
+   }
+
+   if ((cur = tb[TUNNEL_ATTR_REMOTE])) {
+   if (inet_pton(AF_INET6, blobmsg_data(cur), ) < 
1) {
+   ret = -EINVAL;
+   goto failure;
+   }
+   nla_put(msg, IFLA_VXLAN_GROUP6, sizeof(in6buf), 
);
+   }
+   } else {
+   struct in_addr inbuf;
+
+   if ((cur = tb[TUNNEL_ATTR_LOCAL])) {
+   if (inet_pton(AF_INET, blobmsg_data(cur), ) < 1) {
+   ret = -EINVAL;
+   goto failure;
+   }
+   nla_put(msg, IFLA_VXLAN_LOCAL, sizeof(inbuf), );
+   }
+
+   if ((cur = tb[TUNNEL_ATTR_REMOTE])) {
+   if (inet_pton(AF_INET, blobmsg_data(cur), ) < 1) {
+   ret = -EINVAL;
+   goto failure;
+   }
+   nla_put(msg, IFLA_VXLAN_GROUP, 

Re: [LEDE-DEV] [RFC] AR8327 driver: implementing get_port_stats function

[Daniel Gonzalez Cabanelas]

> Fetching the entire port stats only to look up two fields seems rather
> excessive. Please make a function instead that will look up the register
> number and fetch only the relevant registers.
> The lookup can be further simplified by adding an enum for the mib_stats
> array index.
> 
> - Felix

Hi Felix. Could this function be valid?. I'm afraid I cannot make anything more
sophisticated

ar8xxx_sw_get_port_stats(struct switch_dev *dev, int port,
   struct switch_port_stats *stats)
{
struct ar8xxx_priv *priv = swdev_to_ar8xxx(dev);
unsigned int base;
unsigned int rx_offset, tx_offset;

if (port >= dev->ports)
return -EINVAL;

base = priv->chip->reg_port_stats_start +
   priv->chip->reg_port_stats_length * port;

if (priv->chip->num_mibs == ARRAY_SIZE(ar8236_mibs)){
rx_offset = AR8236_STATS_RXGOODBYTE;
tx_offset = AR8236_STATS_TXBYTE;
}

else if (priv->chip->num_mibs == ARRAY_SIZE(ar8216_mibs)){
rx_offset = AR8216_STATS_RXGOODBYTE;
tx_offset = AR8216_STATS_TXBYTE;
}

stats->rx_bytes = ar8xxx_read(priv, base + rx_offset);
stats->tx_bytes = ar8xxx_read(priv, base + tx_offset);

return 0;
}

Also tested and working ok.

Regards
Daniel




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

[LEDE-DEV] Cake SQM killing my DIR-860L - was: [17.01] Kernel: bump to 4.4.51

[Stijn Segers]

Okay, so I tracked it down to cake being the culprit. When I disable 
the Cake SQM instance, no more of those traces, and no more sudden 
reboots.


If I can help debug this, let me know - I enabled a Cake SQM instance 
on an APU2 and so far that seems to run fine.


So, in short: .50/51 bump is okay.

Cheers

Stijn


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

Re: [LEDE-DEV] rb112/rb133 (adm5120) compile fail

[Hartmut Knaack]

Denis Periša schrieb am 27.02.2017 um 16:36:
> Yes, indeed, old kernel.
> I suck at coding so I'm of no use there.

I also have got an adm5120 device around and thought for some time
already to tinker with it, again. So, seems like now would be a good
time to do that.

> I do have one or two 16mb ram devices, but these 'newer' are all 32MB
> .. plus some swap.. good to go. I don't use luci or any daemons so..
> bridge tools and kernel modules for it and ath5k is pretty much all I
> use. It's like supplementary node to main node mostly. Cheap devices,
> good use.
> 
> Is there any quick tips to try newer kernel? maybe patches still apply?
> Device works, compiles as rb1xx and runs fully. But I have some
> problems with ath*k as it requies some old compatibility crypto that
> google cannot find.
> 
> On Mon, Feb 27, 2017 at 7:51 AM, Stefan Lippers-Hollmann  wrote:
>> Hi
>>
>> On 2017-02-27, Denis Periša wrote:
>>> Ah, now I saw if I enable "BROKEN" that it will show as rb1xx, not
>>> generic.. And does compile altho I cannot get ath5k running for some
>>> crypto reason..
>> [...]
>>
>> Be aware that adm5120 has never been ported to kernel 4.4, nor 4.9 and
>> is stuck on kernel 3.18, which is now EOL. This dependency on a no
>> longer supported kernel version and the fact that the platform as a
>> whole hasn't seen sufficient (or probably any-) development to bump
>> the kernel version to 4.4 (or now 4.9) is one of the major reasons why
>> it is marked BROKEN (another is because most of its devices only have
>> 16 MB RAM, which means you need a very specific/ targetted config to keep
>> it running at all). Chances are very high that the whole platform code
>> will be removed from LEDE shortly, unless it gets the development
>> needed to update it to kernel 4.9.x[1]. If you're interested in keeping
>> adm5120 support available, the situation is probably very urgent to
>> get it ported (and stable) to kernel 4.9+.
>>
>> Disclaimer: I can't speak for the LEDE development team and this response
>> is only my personal interpretation of adm5120's current state and most
>> likely fate.
>>
>> Regards
>> Stefan Lippers-Hollmann
>>
>> [1] see 
>> http://lists.infradead.org/pipermail/lede-dev/2017-February/006321.html
>> for reference about a platform (au1000) in a similar situation.
> 
> ___
> Lede-dev mailing list
> Lede-dev@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev
> 



0xFAC89148.asc
Description: application/pgp-keys


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] rb112/rb133 (adm5120) compile fail

[Thomas Endt]

> -Ursprüngliche Nachricht-
> Von: Lede-dev [mailto:lede-dev-boun...@lists.infradead.org] Im Auftrag
> von Stefan Lippers-Hollmann
> Gesendet: Montag, 27. Februar 2017 07:51
> An: Denis Periša
> Cc: LEDE Development List
> Betreff: Re: [LEDE-DEV] rb112/rb133 (adm5120) compile fail
> 
> Hi
> 
> On 2017-02-27, Denis Periša wrote:
> > Ah, now I saw if I enable "BROKEN" that it will show as rb1xx, not
> > generic.. And does compile altho I cannot get ath5k running for some
> > crypto reason..
> [...]
> 
> Be aware that adm5120 has never been ported to kernel 4.4, nor 4.9 and
> is stuck on kernel 3.18, which is now EOL. This dependency on a no
> longer supported kernel version and the fact that the platform as a
> whole hasn't seen sufficient (or probably any-) development to bump the
> kernel version to 4.4 (or now 4.9) is one of the major reasons why it
> is marked BROKEN (another is because most of its devices only have
> 16 MB RAM, which means you need a very specific/ targetted config to
> keep it running at all).
[...]

Do you know which of the devices listed in the LEDE ToH (Table of Hardware [1]) 
belong to the rb1xx subtarget? Is it only the MikroTik RB133?
The adm5120 devices have only very little information. It would be helpful if 
anybody knowledgable can jump in and fill in a little information in the 
following columns:

  * LEDE supported current rel
  * LEDE unsupported
  * Subtarget
  * Firmware LEDE install URL
  * Firmware LEDE upgrade URL



And if someone has something more to write about this target than what 
currently can be found on the target description page [2], feel invited to add 
your knowledge to this page.

[1] 
https://lede-project.org/toh/views/toh_dev_arch-target-cpu?dataflt%5B0%5D=target_%3Dadm5120
[2] https://lede-project.org/docs/targets/adm5120

Regards,

Thomas


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

[LEDE-DEV] [PATCH v2] toolchain/arc: update to the most recent release arc-2016.09

[Alexey Brodkin]

arc-2016.09 is the most recent toolchain for ARC cores and
it is based on top of upstream Binutils 2.27 and GCC 6.2.1.

With updated major version of GCC we copied all GCC 6.x patches
for ARC as well as Bintils 2.27 patches.

Note that toochain sports ARCv4 ABI and so must be used
with 4.8+ Linux kernels. Even though it will build v4.4 kernel
perfectly fine on attempt to run user-space apps they won't
work with older kernel. That said previuosly sent RFC patches with
Linux kernel update are required:
 [1] https://patchwork.ozlabs.org/patch/726686/
 [2] https://patchwork.ozlabs.org/patch/726687/

Signed-off-by: Alexey Brodkin 
---

Changes v1 -> v2:
 * GCC_USE_GRAPHITE option is restored, only dependency on
   !GCC_VERSION_4_8_ARC is now removed.

 package/devel/gdb-arc/Makefile |   6 +-
 toolchain/binutils/Config.in   |   8 +-
 toolchain/binutils/Config.version  |   4 +-
 toolchain/binutils/Makefile|  12 +-
 .../arc-2016.03/200-arc-fix-target-mask.patch  |  13 --
 .../300-001_ld_makefile_patch.patch|  22 +++
 .../300-012_check_ldrunpath_length.patch   |  20 +++
 toolchain/gcc/Config.in|  11 +-
 toolchain/gcc/Config.version   |   8 +-
 toolchain/gcc/common.mk|  10 +-
 .../patches/arc-2016.03/002-weak_data_fix.patch|  42 -
 .../arc-2016.03/003-universal_initializer.patch|  94 ---
 .../patches/arc-2016.03/020-no-plt-backport.patch  |  28 
 .../210-disable_libsanitizer_off_t_check.patch |  11 --
 .../arc-2016.03/800-arc-disablelibgmon.patch   |  18 --
 .../gcc/patches/arc-2016.03/860-use_eh_frame.patch |  42 -
 .../arc-2016.03/920-specs_nonfatal_getenv.patch|  14 --
 .../arc-2016.03/950-fix-building-with-gcc6.patch   | 153 -
 .../001-revert_register_mode_search.patch  |   2 +-
 .../002-case_insensitive.patch}|   0
 .../010-documentation.patch|   2 +-
 .../arc-2016.09-release/230-musl_libssp.patch  |  13 ++
 .../280-musl-disable-ifunc-by-default.patch|  36 
 .../300-mips_Os_cpu_rtx_cost_model.patch   |  11 ++
 .../800-arm_v5te_no_ldrd_strd.patch|  11 ++
 .../810-arm-softfloat-libgcc.patch |  25 +++
 .../820-libgcc_pic.patch   |   8 +-
 .../830-arm_unbreak_armv4t.patch   |  13 ++
 .../840-armv4_pass_fix-v4bx_to_ld.patch|  19 +++
 .../850-use_shared_libgcc.patch|  16 +-
 .../851-libgcc_no_compat.patch |   0
 .../870-ppc_no_crtsavres.patch |   2 +-
 .../880-no_java_section.patch  |   2 +-
 .../arc-2016.09-release/881-no_tm_section.patch|  11 ++
 .../arc-2016.09-release/900-bad-mips16-crt.patch   |   9 +
 .../910-mbsd_multi.patch   |  83 +++---
 .../920-specs_nonfatal_getenv.patch|  15 ++
 .../930-fix-mips-noexecstack.patch | 111 +
 .../940-no-clobber-stamp-bits.patch|   2 +-
 .../950-cpp_file_path_translation.patch| 182 +
 toolchain/gdb/Makefile |   6 +-
 41 files changed, 573 insertions(+), 522 deletions(-)
 delete mode 100644 
toolchain/binutils/patches/arc-2016.03/200-arc-fix-target-mask.patch
 create mode 100644 
toolchain/binutils/patches/arc-2016.09-release/300-001_ld_makefile_patch.patch
 create mode 100644 
toolchain/binutils/patches/arc-2016.09-release/300-012_check_ldrunpath_length.patch
 delete mode 100644 toolchain/gcc/patches/arc-2016.03/002-weak_data_fix.patch
 delete mode 100644 
toolchain/gcc/patches/arc-2016.03/003-universal_initializer.patch
 delete mode 100644 toolchain/gcc/patches/arc-2016.03/020-no-plt-backport.patch
 delete mode 100644 
toolchain/gcc/patches/arc-2016.03/210-disable_libsanitizer_off_t_check.patch
 delete mode 100644 
toolchain/gcc/patches/arc-2016.03/800-arc-disablelibgmon.patch
 delete mode 100644 toolchain/gcc/patches/arc-2016.03/860-use_eh_frame.patch
 delete mode 100644 
toolchain/gcc/patches/arc-2016.03/920-specs_nonfatal_getenv.patch
 delete mode 100644 
toolchain/gcc/patches/arc-2016.03/950-fix-building-with-gcc6.patch
 rename toolchain/gcc/patches/{arc-2016.03 => 
arc-2016.09-release}/001-revert_register_mode_search.patch (97%)
 rename toolchain/gcc/patches/{arc-2016.03/004-case_insensitive.patch => 
arc-2016.09-release/002-case_insensitive.patch} (100%)
 rename toolchain/gcc/patches/{arc-2016.03 => 
arc-2016.09-release}/010-documentation.patch (91%)
 create mode 100644 
toolchain/gcc/patches/arc-2016.09-release/230-musl_libssp.patch
 create mode 100644 
toolchain/gcc/patches/arc-2016.09-release/280-musl-disable-ifunc-by-default.patch
 create mode 100644 

Re: [LEDE-DEV] [PATCH] packages/utils/cryptodev-linux: Update to current master

[Alexey Brodkin]

Hi John,

On Mon, 2017-02-20 at 09:24 +0100, John Crispin wrote:
> 
> On 15/02/2017 14:19, Alexey Brodkin wrote:
> > 
> > From: Alexey Brodkin 
> > 
> > This allows us to build kernel's crypto modules in Linux v4.9.
> > Otherwise we're seeing the following breakage:
> > --->8-
> > ...//openwrt/build_dir/target-arc_arc700_uClibc/linux-arc770_generic/cryptodev-linux-1.8/cryptlib.c:
> >  In function
> > 'cryptodev_cipher_init':
> > ...//openwrt/build_dir/target-arc_arc700_uClibc/linux-arc770_generic/cryptodev-linux-1.8/cryptlib.c:138:18:
> >  error:
> > implicit declaration of function 'crypto_alloc_ablkcipher' 
> > [-Werror=implicit-function-declaration]
> >    out->async.s = crypto_alloc_ablkcipher(alg_name, 0, 0);
> >   ^~~
> > ...//openwrt/build_dir/target-arc_arc700_uClibc/linux-arc770_generic/cryptodev-linux-1.8/cryptlib.c:138:16:
> >  warning:
> > assignment makes pointer from integer without a cast [-Wint-conversion]
> >    out->async.s = crypto_alloc_ablkcipher(alg_name, 0, 0);
> > ^
> > cc1: some warnings being treated as errors
> > --->8-
> > 
> > Actual fix is in 
> > https://github.com/cryptodev-linux/cryptodev-linux/commit/6818263667ca488f9b1c86e36ea624c4ea1c309f
> > but given amount of changes since 1.8 release adaptation of this patch
> > requires quite a lot of changes and so let's just grab latest sources
> > from git.
> > 
> > Signed-off-by: Alexey Brodkin 
> > Signed-off-by: Alexey Brodkin 
> > ---
> >  utils/cryptodev-linux/Makefile | 12 ++--
> >  1 file changed, 6 insertions(+), 6 deletions(-)
> > 
> > diff --git a/utils/cryptodev-linux/Makefile b/utils/cryptodev-linux/Makefile
> > index 4f187c8..1cbf282 100644
> > --- a/utils/cryptodev-linux/Makefile
> > +++ b/utils/cryptodev-linux/Makefile
> > @@ -10,12 +10,12 @@ include $(TOPDIR)/rules.mk
> >  include $(INCLUDE_DIR)/kernel.mk
> >  
> >  PKG_NAME:=cryptodev-linux
> > -PKG_VERSION:=1.8
> > -PKG_RELEASE:=2
> > -
> > -PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.gz
> > -PKG_SOURCE_URL:=http://download.gna.org/cryptodev-linux/
> > -PKG_MD5SUM:=02644cc4cd02301e0b503a332eb2f0b5
> > +PKG_SOURCE_PROTO:=git
> > +PKG_SOURCE_URL=https://github.com/cryptodev-linux/cryptodev-linux.git
> 
> Hi,
> 
> is this the official repo ? i would prefer to not pull from github if
> possible

Looking at their official web-site http://cryptodev-linux.org/download.html
I would think https://github.com/cryptodev-linux/cryptodev-linux is their
official git repo.

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

[LEDE-DEV] [RFC] ipq806x: Add USB Type Selector for R7500

[Thomas Reifferscheid]

The patch enables the primary USB port on R7500. Because of the
missing general IPQ8064x TCSR initialisation functions a workaround
using pinctrl,single was chosen. It allows us to set 1a4000b0 from
.0010 to .0011 thus enabling the primary USB port - prior
to the dwc3-phy initialisation. Needs to be reworked once Qualcomm
adds TCSR initialisation functionality from their 3.x kernel into 4.x
kernels.

The patch fixes FS#497 and partially backs off
45bf3d4f248ea2d770a1625fdee8899dc40329af which had the right idea but
was missing the syscon-tcsr handler - which by the time of the upstream
patch attempt (January 2015) was trying to set the TCSR USB Type
selector at the wrong part of the kernel.

Signed-off-by: Thomas Reifferscheid 
---
 ...ipq806x-add-usbtypesel-required-for-r7500.patch | 56 ++
 1 file changed, 56 insertions(+)
 create mode 100644 
target/linux/ipq806x/patches-4.4/716-ipq806x-add-usbtypesel-required-for-r7500.patch

diff --git 
a/target/linux/ipq806x/patches-4.4/716-ipq806x-add-usbtypesel-required-for-r7500.patch
 
b/target/linux/ipq806x/patches-4.4/716-ipq806x-add-usbtypesel-required-for-r7500.patch
new file mode 100644
index 000..4927708
--- /dev/null
+++ 
b/target/linux/ipq806x/patches-4.4/716-ipq806x-add-usbtypesel-required-for-r7500.patch
@@ -0,0 +1,56 @@
+diff -Naur a/arch/arm/boot/dts/qcom-ipq8064.dtsi 
b/arch/arm/boot/dts/qcom-ipq8064.dtsi
+--- a/arch/arm/boot/dts/qcom-ipq8064.dtsi  2017-02-27 12:34:58.669161969 
+0100
 b/arch/arm/boot/dts/qcom-ipq8064.dtsi  2017-02-27 12:40:51.253172676 
+0100
+@@ -626,6 +626,13 @@
+   reg = <0x1a40 0x100>;
+   };
+ 
++usbtypesel: pinmux@1a4000b0 {
++compatible = "pinctrl-single";
++pinctrl-single,register-width = <32>;   /* u32
  */
++pinctrl-single,function-mask = <0x03>;  /* only allow 
to set the 2 LSBs */
++reg = <0x1a4000b0 0x04>;/* u32
  */
++};
++
+   lcc: clock-controller@2800 {
+   compatible = "qcom,lcc-ipq8064";
+   reg = <0x2800 0x1000>;
+@@ -685,8 +692,6 @@
+   clocks = < USB30_0_MASTER_CLK>;
+   clock-names = "core";
+ 
+-  syscon-tcsr = < 0xb0 1>;
+-
+   ranges;
+ 
+   status = "disabled";
+@@ -709,8 +714,6 @@
+   clocks = < USB30_1_MASTER_CLK>;
+   clock-names = "core";
+ 
+-  syscon-tcsr = < 0xb0 0>;
+-
+   ranges;
+ 
+   status = "disabled";
+diff -Naur a/arch/arm/boot/dts/qcom-ipq8064-r7500.dts 
b/arch/arm/boot/dts/qcom-ipq8064-r7500.dts
+--- a/arch/arm/boot/dts/qcom-ipq8064-r7500.dts 2017-02-27 12:35:08.693162274 
+0100
 b/arch/arm/boot/dts/qcom-ipq8064-r7500.dts 2017-02-27 12:35:12.677162395 
+0100
+@@ -131,6 +131,17 @@
+   status = "ok";
+   };
+ 
++pinmux@1a4000b0 {
++pinctrl-names = "default";
++pinctrl-0 = <_pins>;
++
++board_pins: pinmux_board_pins {
++pinctrl-single,pins = <
++0x00 0x03 /* 
IPQ_TCSR_USB_CONTROLLER_TYPE_SEL TCSR_USB_SELECT_USB3_DUAL */
++>;
++};
++};
++
+   phy@100f8800 {  /* USB3 port 1 HS phy */
+   status = "ok";
+   };
-- 
2.1.4


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

[LEDE-DEV] using sata-port-specific led triggers

[Alberto Bursi]

On 02/27/2017 12:46 PM, Daniel Golle wrote:
> Will, I wrote this patch a long while ago (and use it on oxnas)
>
> https://git.lede-project.org/?p=source.git;a=blob;f=target/linux/generic/patches-4.9/834-ledtrig-libata.patch
>

This is pretty cool, is there a reason why I can't find any board with 
the ARCH_WANTS_LIBATA_LEDS enabled in the kernel config in LEDE sources?
(even oxnas don't seem to have this)

I intend to try this on some kirkwoods that have more than one sata led 
(nsa310/325, goflexnet).

-Alberto

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

Re: [LEDE-DEV] replacing mountd with blockd - looking for testers

[Daniel Golle]

On Mon, Feb 27, 2017 at 11:48:23AM +0100, John Crispin wrote:
> On 27/02/2017 11:43, Alberto Bursi wrote:
> > There are quite a few NAS devices that have 2+ disk activity leds (one 
> > for each disk) that could really use a generic system instead of adding 
> > patches to drivers/kernel.
> 
> dont get this, why is a kernel patch required ? if there is an
> appropriate trigger at hand, we will use it otherwise it will be
> 
> * off - no device attached
> * on - device attached
> * blink - device mounted

There are devices (like the KD20) which got 2 LEDs for each S-ATA port:
a red one to indicate a faulty disk and a blue to indicate link-up and
port activity.

Will, I wrote this patch a long while ago (and use it on oxnas)

https://git.lede-project.org/?p=source.git;a=blob;f=target/linux/generic/patches-4.9/834-ledtrig-libata.patch

Maybe this LED trigger could take a parameter from userspace to
indicate the mount-status as well (unless there is a way to get
use-count from inside the libata subsystem?)

Anyway, I tried submitting this upstream and it was deleted from their
patchwork within a day with no reason given what-so-ever, I guess
because they believe that the generic 'disk' led-trigger is good
enough...


Cheers


Daniel

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

Re: [LEDE-DEV] [RFC] Need help to support CPU frequency setting on Mikrotik RB devices

[Nishant Sharma]

Hi,

Here is the data from RB951Ui-2HnD running OWRT 15.05.1 (custom compiled).

On Monday 27 February 2017 04:58 PM, Thibaut wrote:

I’m currently working with Alex Samorukov on bringing cpu frequency setting to 
rbcfg for Mikrotik Routerboards devices, and in doing so, we would need a bit 
of input from people owning that hardware and running LEDE on it:

1. output of `cat /proc/cpuinfo`


cat /proc/cpuinfo
system type : Atheros AR9344 rev 3
machine : MikroTik RouterBOARD 951Ui-2HnD
processor   : 0
cpu model   : MIPS 74Kc V4.12
BogoMIPS: 299.82
wait instruction: yes
microsecond timers  : yes
tlb_entries : 32
extra interrupt vector  : yes
hardware watchpoint : yes, count: 4, address/irw mask: [0x0ffc, 
0x0ffc, 0x0ffb, 0x0ffb]

isa : mips1 mips2 mips32r1 mips32r2
ASEs implemented: mips16 dsp dsp2
shadow register sets: 1
kscratch registers  : 0
package : 0
core: 0
VCED exceptions : not available
VCEI exceptions : not available



2. output of `dmesg | grep board=`


[0.00] Kernel command line:  no-uart parts=1 
boot_part_size=4194304 gpio=130619 HZ=3 mem=128M 
kmac=6C:3B:6B:F2:0E:40 board=951HnD Board=951HnD ver=3.33 
hw_opt=00210005 boot=1 mlc=10 rootfstype=yaffs noinitrd



3. if possible, whether or not RouterBOOT offers a “cpu frequency” setting 
(typically under key ‘f’) at boot time


I guess, this is accessible over UART. But I do not have access to UART 
port as devices are in the field



4. if possible, for various cpu frequency settings (ideally for all of them), 
the output of `dmesg | grep Clocks; hexdump -C /dev/mtdblockN` where mtdblockN 
is the soft_config partition. Please provide this output at least once, even if 
there’s no frequency setting.


[0.00] Clocks: CPU:600.000MHz, DDR:400.000MHz, AHB:400.000MHz, 
Ref:25.000MHz


I can see /dev/mtdblock{0,1,2}.

Kernel is on mtdblock1 and filesystem on mtdblock2. Is that the 
mtdblock0 whose hexdump is required? It is going to be a big one. Please 
suggest how to send it across.



5. Finally, which frequency setting is the factory default one


No idea on this one. Sorry.




Regards,
Nishant

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

Re: [LEDE-DEV] [RFC] AR8327 driver: implementing get_port_stats function

[Felix Fietkau]

On 2017-02-25 22:51, Daniel Gonzalez Cabanelas wrote:
> Currently the switch LED trigger only shows link status, but not traffic 
> activity by blinking
> the LEDs on the AR8316/AR8327 switch. It turns out that the get_port_stats is 
> missing.
> 
> I've made this patch, which works ok. But I'm not sure if there is any reason 
> to not implement this 
> function. And probably the function ar8xxx_sw_get_port_stats can be improved.
> 
> There are a few boards with an  AR8316/AR8327 switch that need this trigger, 
> usually on the WAN port.
> As said without get_port_stats the light stays always fixed, like if there 
> wasn't traffic activity. We can use 
> the netdev trigger but then the light is always on even when the cable is 
> unplugged, and there isn't the
> possibility of using a second LED trigger on the same port for indicating a 
> reduced link speed.
> 
> diff --git a/target/linux/generic/files/drivers/net/phy/ar8216.c 
> b/target/linux/generic/files/drivers/net/phy/ar8216.c
> index 37877d5..ffaa77e 100644
> --- a/target/linux/generic/files/drivers/net/phy/ar8216.c
> +++ b/target/linux/generic/files/drivers/net/phy/ar8216.c
> @@ -1001,6 +1001,41 @@ ar8xxx_sw_get_port_link(struct switch_dev *dev, int 
> port,
>   return 0;
>  }
>  
> +int
> +ar8xxx_sw_get_port_stats(struct switch_dev *dev, int port,
> +struct switch_port_stats *stats)
> +{
> + struct ar8xxx_priv *priv = swdev_to_ar8xxx(dev);
> + const struct ar8xxx_chip *chip = priv->chip;
> + u64 *mib_stats, mib_data;
> + const char *mib_name;
> + int i;
> +
> + if (!ar8xxx_has_mib_counters(priv))
> + return -EOPNOTSUPP;
> +
> + if (port >= dev->ports)
> + return -EINVAL;
> +
> + mutex_lock(>mib_lock);
> +
> + ar8xxx_mib_fetch_port_stat(priv, port, false);
> +
> + mib_stats = >mib_stats[port * chip->num_mibs];
> + for (i = 0; i < chip->num_mibs; i++) {
> + mib_name = chip->mib_decs[i].name;
> + mib_data = mib_stats[i];
> + if (!strcmp(mib_name, "TxByte"))
> + stats->tx_bytes = mib_data;
> + if (!strcmp(mib_name, "RxGoodByte"))
> + stats->rx_bytes = mib_data;
> + }

Fetching the entire port stats only to look up two fields seems rather
excessive. Please make a function instead that will look up the register
number and fetch only the relevant registers.
The lookup can be further simplified by adding an enum for the mib_stats
array index.

- Felix

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

[LEDE-DEV] [RFC] Need help to support CPU frequency setting on Mikrotik RB devices

[Thibaut]

Hi,

I’m currently working with Alex Samorukov on bringing cpu frequency setting to 
rbcfg for Mikrotik Routerboards devices, and in doing so, we would need a bit 
of input from people owning that hardware and running LEDE on it:

1. output of `cat /proc/cpuinfo`
2. output of `dmesg | grep board=`
3. if possible, whether or not RouterBOOT offers a “cpu frequency” setting 
(typically under key ‘f’) at boot time
4. if possible, for various cpu frequency settings (ideally for all of them), 
the output of `dmesg | grep Clocks; hexdump -C /dev/mtdblockN` where mtdblockN 
is the soft_config partition. Please provide this output at least once, even if 
there’s no frequency setting.
5. Finally, which frequency setting is the factory default one

We already have the data for the RB mAP lite and hAP lite.

I think that covers it!

Thanks in advance,
Thibaut
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] replacing mountd with blockd - looking for testers

[Alberto Bursi]

On 02/27/2017 11:48 AM, John Crispin wrote:
>
>
>
> dont get this, why is a kernel patch required ?

That's how I saw some of such NAS stock firmwares (and some Debian/Arch 
for ARM targeting those devices) do.
Someone patched the sata driver (and the kernel) to create a "sata 
activity on port X" trigger that will show disk activity on "sata port 
X" (devices that have at least 2 sata ports, usually have a sata led per 
disk)

The Sata led trigger from upstream will trigger on ANY activity on Sata, 
so it's not useful to drive more than one Sata led.

> * off - no device attached
> * on - device attached
> * blink - device mounted
>

Hm, better than nothing.

I think the above led behaviours should be user-configurable though.

-Alberto

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

Re: [LEDE-DEV] replacing mountd with blockd - looking for testers

[John Crispin]

On 27/02/2017 11:36, Daniel Golle wrote:
> Hi John,
> 
> On Mon, Feb 27, 2017 at 11:20:40AM +0100, John Crispin wrote:
>> Hi,
>>
>> i have created a branch in my staging tree [1] that removes mountd in
>> favour of blockd. blockd is part of the fstools package and uses the
>> block tool and /etc/config/fstab as a backend.
>>
>> blockd is an optional daemon and when installed will provide these
>> features in addition to what block-mount already does :
>>
>> * autofs4 support
>> * ubus call block info - for status info on attached block devices
>> * reload_config support - mount move or change from named to autofs to
>> anon mounts
> 
> Great news!
> 
>>
>> What else should we add :
>>
>> * support for eject buttons and LEDs
>> * ubus notifications upon state changes
>> * ubus interface for mount/unmount
>> * anything else that folks might like to see being added ?
> 
> I haven't had a look at your work yet, so something might already
> be supported implicitely. However, I imagine it'd be useful to have
>  * waiting with service bring-up until specific device got mounted
>(eg. for transmission or postgresql)

we could add this to blockd but would need to figure out where to put
this info. maybe add it as private data to the service/instance inside
procd ?

>  * support for attaching and activating LVM2 volumes
>  * support for using cryptsetup to open LUKS and TrueCrypt volumes
>see https://github.com/openwrt/packages/pull/3259

these are really features that should be added to block-mount ?

John

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

Re: [LEDE-DEV] replacing mountd with blockd - looking for testers

[John Crispin]

On 27/02/2017 11:43, Alberto Bursi wrote:
> 
> 
> On 02/27/2017 11:20 AM, John Crispin wrote:
>> Hi,
>>
>> * support for eject buttons and LEDs
> 
> Can this daemon light up a led every time a specific mounted partition 
> is accessed (read/written)?

not yet, which is why this action item is listed under the "What else
should we add" section. however the idea is that you can specify the led
either in the mount section or the global section.

> 
> There are quite a few NAS devices that have 2+ disk activity leds (one 
> for each disk) that could really use a generic system instead of adding 
> patches to drivers/kernel.

dont get this, why is a kernel patch required ? if there is an
appropriate trigger at hand, we will use it otherwise it will be

* off - no device attached
* on - device attached
* blink - device mounted

John

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

Re: [LEDE-DEV] [PATCH] Add ip_vs kernel netfilter modules to enable load balancing, capabilities

[John Crispin]

On 24/02/2017 12:42, Mauro Mozzarelli wrote:
> IPVS (IP Virtual Server) implements transport-layer load balancing
> inside the Linux kernel, so called Layer-4 switching. IPVS running on a
> host acts as a load balancer at the front of a cluster of real servers,
> it can direct requests for TCP/UDP based services to the real servers,
> and makes services of the real servers to appear as a virtual service on
> a single IP address.
> 
> This patch adds kmod-nf-ipvs kernel modules option to LEDE kernel netfilter
> 
> Signed-off-by: Mauro Mozzarelli 

Hi Mauro,

How do you send your patches ? patchwork fails to pick them up properly

https://patchwork.ozlabs.org/patch/732113/

John


> ---
>  package/kernel/linux/modules/netfilter.mk | 89
> +++
>  1 file changed, 89 insertions(+)
> 
> diff --git a/package/kernel/linux/modules/netfilter.mk
> b/package/kernel/linux/modules/netfilter.mk
> index 6162dbc..9cef8fd 100644
> --- a/package/kernel/linux/modules/netfilter.mk
> +++ b/package/kernel/linux/modules/netfilter.mk
> @@ -77,6 +77,17 @@ endef
>  $(eval $(call KernelPackage,nf-conntrack))
> 
> 
> +define KernelPackage/nf-conntrack-ftp
> +  SUBMENU:=$(NF_MENU)
> +  TITLE:=FTP connection tracking
> +  KCONFIG:=CONFIG_NF_CONNTRACK_FTP
> +  DEPENDS:=kmod-nf-conntrack
> +  FILES:=$(LINUX_DIR)/net/netfilter/nf_conntrack_ftp.ko
> +endef
> +
> +$(eval $(call KernelPackage,nf-conntrack-ftp))
> +
> +
>  define KernelPackage/nf-conntrack6
>SUBMENU:=$(NF_MENU)
>TITLE:=Netfilter IPv6 connection tracking
> @@ -271,6 +282,84 @@ define KernelPackage/ipt-ipset
>  endef
>  $(eval $(call KernelPackage,ipt-ipset))
> 
> +IPVS_MODULES:= \
> +ipvs/ip_vs \
> +ipvs/ip_vs_lc \
> +ipvs/ip_vs_wlc \
> +ipvs/ip_vs_rr \
> +ipvs/ip_vs_wrr \
> +ipvs/ip_vs_lblc \
> +ipvs/ip_vs_lblcr \
> +ipvs/ip_vs_dh \
> +ipvs/ip_vs_sh \
> +ipvs/ip_vs_fo \
> +ipvs/ip_vs_ovf \
> +ipvs/ip_vs_nq \
> +ipvs/ip_vs_sed \
> +xt_ipvs
> +
> +define KernelPackage/nf-ipvs
> +  SUBMENU:=Netfilter Extensions
> +  TITLE:=IP Virtual Server modules
> +  DEPENDS:=@IPV6 +kmod-lib-crc32c +kmod-ipt-conntrack +kmod-nf-conntrack
> +  KCONFIG:= \
> +CONFIG_IP_VS \
> +CONFIG_IP_VS_IPV6=y \
> +CONFIG_IP_VS_DEBUG=n \
> +CONFIG_IP_VS_PROTO_TCP=y \
> +CONFIG_IP_VS_PROTO_UDP=y \
> +CONFIG_IP_VS_PROTO_AH_ESP=y \
> +CONFIG_IP_VS_PROTO_ESP=y \
> +CONFIG_IP_VS_PROTO_AH=y \
> +CONFIG_IP_VS_PROTO_SCTP=y \
> +CONFIG_IP_VS_TAB_BITS=12 \
> +CONFIG_IP_VS_RR \
> +CONFIG_IP_VS_WRR \
> +CONFIG_IP_VS_LC \
> +CONFIG_IP_VS_WLC \
> +CONFIG_IP_VS_FO \
> +CONFIG_IP_VS_OVF \
> +CONFIG_IP_VS_LBLC \
> +CONFIG_IP_VS_LBLCR \
> +CONFIG_IP_VS_DH \
> +CONFIG_IP_VS_SH \
> +CONFIG_IP_VS_SED \
> +CONFIG_IP_VS_NQ \
> +CONFIG_IP_VS_SH_TAB_BITS=8 \
> +CONFIG_IP_VS_NFCT=y \
> +CONFIG_NETFILTER_XT_MATCH_IPVS
> +
> +  FILES:=$(foreach
> mod,$(IPVS_MODULES),$(LINUX_DIR)/net/netfilter/$(mod).ko)
> +  $(call AddDepends/ipt,+kmod-ipt-conntrack,+kmod-nf-conntrack)
> +endef
> +$(eval $(call KernelPackage,nf-ipvs))
> +
> +define KernelPackage/nf-ipvs/description
> + IPVS (IP Virtual Server) implements transport-layer load balancing
> inside the Linux kernel
> + so called Layer-4 switching.
> +endef
> +
> +define KernelPackage/nf-ipvs-ftp
> +  SUBMENU:=$(NF_MENU)
> +  TITLE:=Virtual Server FTP protocol support
> +  KCONFIG:=CONFIG_IP_VS_FTP
> +  DEPENDS:=kmod-nf-ipvs +kmod-nf-nat +kmod-nf-conntrack-ftp
> +  FILES:=$(LINUX_DIR)/net/netfilter/ipvs/ip_vs_ftp.ko
> +endef
> +
> +$(eval $(call KernelPackage,nf-ipvs-ftp))
> +
> +
> +define KernelPackage/nf-ipvs-sip
> +  SUBMENU:=$(NF_MENU)
> +  TITLE:=Virtual Server SIP protocol support
> +  KCONFIG:=CONFIG_IP_VS_PE_SIP
> +  DEPENDS:=kmod-nf-ipvs +kmod-nf-nathelper-extra
> +  FILES:=$(LINUX_DIR)/net/netfilter/ipvs/ip_vs_pe_sip.ko
> +endef
> +
> +$(eval $(call KernelPackage,nf-ipvs-sip))
> +
> 
>  define KernelPackage/ipt-nat
>TITLE:=Basic NAT targets

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

[LEDE-DEV] replacing mountd with blockd - looking for testers

[John Crispin]

Hi,

i have created a branch in my staging tree [1] that removes mountd in
favour of blockd. blockd is part of the fstools package and uses the
block tool and /etc/config/fstab as a backend.

blockd is an optional daemon and when installed will provide these
features in addition to what block-mount already does :

* autofs4 support
* ubus call block info - for status info on attached block devices
* reload_config support - mount move or change from named to autofs to
anon mounts

What else should we add :

* support for eject buttons and LEDs
* ubus notifications upon state changes
* ubus interface for mount/unmount
* anything else that folks might like to see being added ?

Please help test the new daemon.

John

[1]
https://git.lede-project.org/?p=lede/blogic/staging.git;a=shortlog;h=refs/heads/blockd

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

[LEDE-DEV] [PATCH] procd: service gets deleted when its last instance is freed

[Alin Nastac]

This fixes the following regression introduced in commit
961dc692aff7457f874bce61f8e766514edcf794:
 1) reboot using the following configuration
root@OpenWrt:~# uci show system.ntp
system.ntp=timeserver
system.ntp.enable_server='0'
system.ntp.use_dhcp='1'
system.ntp.dhcp_interface='wan'
root@OpenWrt:~# uci show network.wan
network.wan=interface
network.wan.proto='dhcp'
network.wan.ifname='eth4'
network.wan.reqopts='1 3 6 15 33 42 51 121 249'
 2) if obtained DHCP lease has an option 42 sysntpd service will have an
 instance
 3) run "ifup wan"
 4) although the same DHCP lease was obtained, sysntpd would be stopped

Because sysntpd service is deleted when last instance is freed, its triggers
will also be released. Without these triggers in place, sysntpd will not be
reloaded when a new DHCP lease containing option 42 will be received.

Signed-off-by: Alin Nastac 
---
 service/service.c | 5 -
 service/service.h | 1 +
 2 files changed, 5 insertions(+), 1 deletion(-)

diff --git a/service/service.c b/service/service.c
index 0584ee0..9675ba2 100644
--- a/service/service.c
+++ b/service/service.c
@@ -140,6 +140,8 @@ service_update(struct service *s, struct blob_attr **tb, 
bool add)
vlist_flush(>instances);
}
 
+   s->deleted = false;
+
rc(s->name, "running");
 
return 0;
@@ -149,6 +151,7 @@ static void
 service_delete(struct service *s)
 {
vlist_flush_all(>instances);
+   s->deleted = true;
service_stopped(s);
 }
 
@@ -602,7 +605,7 @@ service_start_early(char *name, char *cmdline)
 
 void service_stopped(struct service *s)
 {
-   if (avl_is_empty(>instances.avl)) {
+   if (s->deleted && avl_is_empty(>instances.avl)) {
service_event("service.stop", s->name, NULL);
avl_delete(, >avl);
trigger_del(s);
diff --git a/service/service.h b/service/service.h
index d4f0a83..cc629b1 100644
--- a/service/service.h
+++ b/service/service.h
@@ -40,6 +40,7 @@ struct validate {
 struct service {
struct avl_node avl;
const char *name;
+   bool deleted;
 
struct blob_attr *trigger;
struct vlist_tree instances;
-- 
1.7.12.4


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