[LEDE-DEV] [PATCH procd] upgraded: cmake: Find and include uloop.h

2017-05-31 Thread Florian Fainelli
Add a CMake FIND_PATH and INCLUDE_DIRECTORIES searching for
libubox/uloop.h. Some external toolchains which do not include standard
locations would fail to find the header otherwise.

Signed-off-by: Florian Fainelli 
---
 upgraded/CMakeLists.txt | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/upgraded/CMakeLists.txt b/upgraded/CMakeLists.txt
index 00d8ce575c25..fd7d6bb58b78 100644
--- a/upgraded/CMakeLists.txt
+++ b/upgraded/CMakeLists.txt
@@ -1,6 +1,8 @@
 cmake_minimum_required(VERSION 2.6)
 
 PROJECT(upgraded C)
+FIND_PATH(ubox_include_dir libubox/uloop.h)
+INCLUDE_DIRECTORIES(${ubox_include_dir})
 ADD_DEFINITIONS(-Os -ggdb -Wall -Werror --std=gnu99 -Wmissing-declarations)
 ADD_EXECUTABLE(upgraded upgraded.c ../watchdog.c)
 TARGET_LINK_LIBRARIES(upgraded ubox)
-- 
2.13.0


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


Re: [LEDE-DEV] openwrt and lede - remerge proposal V3

2017-05-31 Thread Alexander Couzens
On Mon, 29 May 2017 09:03:57 +0200
John Crispin  wrote:

> (resend, this time as plain text)
> 
> Hi,
> 
> here is a V3 of the remerge proposal, I tried to fold all the
> comments people made into it, if anything is missing let me know.
> Please remeber that post remerge anything can be voted on, so
> cluttering the proposal with many details will delay the remerge even
> more.
> 
> Ideally we manage to vote during this week.
> 
> 
>  John

ACK.


> 
> *) rules
> - owrt will adopt the lede rules and voting system
> 
> *) branding
> - the owrt side sees no option of using the lede brand
> - a (minor) majority voted for openwrt as a name over lede whilst
> most people said they did not care
> - as the last vote had a 100% ACK for a remerge using the owrt brand
> is the only feasible option
> 
> *) domain
> - transfer owner ship to SPI for openwrt.org and lede-project.org
> - add them to the pool of urls at digital ocean
> - post remerge build a setup where we have several DNS servers in 
> various locations
> - point git.openwrt.org at the lede git server
> - point bugs.openwrt.org to the lede flyspray instance
> - keep both wikis and forums as is (we should decide post remerge how
> to proceed to avoid these issues blocking the progress)
> - update the lede domain entries for build/download/rsync/... servers
> so that the openwrt domain also points at them
> 
> *) SPI
> - nominate a new liaison team (imre and john offer to do this, if
> anyone else is interested let us know)
> - inform SPI of the new liaisons, voters and project rules
> - this should be done early in the remerge process s.t. the domains
> can be handed over
> 
> *) github
> - start pushing to the openwrt organisation
> - cleanup the list of owners in the openwrt organisation
> - obsolete all issues on the openwrt organisation and close the issue 
> tracker
> - go through the open openwrt and lede PRs, pickup whats useful and 
> close the rest, asking people to repost (things wont be rebasable
> anyhow)
> - close the lede PR tracker
> - obsolete the lede github org after a grace period of 3-6 months
> 
> *) landing page
> - add a letter of intent / notice to both current landing pages 
> announcing the remerge
> - update the lede landing page to represent the openwrt name
> - update the landing page to have the same look & feel as the current 
> openwrt landing page
> - point openwrt.org at the lede landing page
> - try to find some design guru that will transform the owrt theme to
> one appropriate to this century
> 
> *) trac
> - trac is already readonly, keep content so that search engines can 
> still find the it
> - edit the trac html templates, adding a note pointing at the 
> bug.openwrt.org instance
> 
> *) IRC
> - add back cloaking
> - give people channel ownership/admin rights
> 
> *) email accounts
> - currently there are around ~20 active openwrt.org mail accounts
> (the 3 owrt devs would like to keep theirs active)
> - turn all the webmaster@, hostmaster@, ... accounts into aliases
> that anyone with voting rights can be subscribed to
> - ask those people that are no longer active to voluntarily give up 
> their accounts
> - mail addresses may under no conditions be used for any personal 
> business, consultancy, applying for jobs, ... purposes
> - any mail sent from an openwrt.org account needs to adhere the 
> trademark policy and should only be used for FOSS purposes
> 
> *) wiki / forum
> - TBD
> - asking in either forum/wiki will get a biased vote so keep them
> both around
> - start a separate discussion regarding these post remerge
> 
> *) LF
> - find out what doubts folks have about LF
> - find out benefits - we would have their hosting and sponsorship ?!
> - start a separate discussion regarding these post remerge
> 
> *) git trees
> - rebrand the lede tree to openwrt
> - work out what has happened inside the openwrt tree since the reboot 
> and pick up the useful bits (zoltan has done some prior work on this 
> already)
> 
> *) mailing list
> - ask david to add the openwrt-adm and openwrt lists
> - send out invitation mails to the new list
> - setup redirect/auto-reply for the existing lists
> 
> *) trademark policy
> - review/ack imres trademark policy (https://openwrt.org/trademark)
> 
> *) timeline
> - vote / agree on the proposal within the next week
> - work on the action items in the 4 weeks after that
> 
>  John
> 
> 
> 
> ___
> Lede-dev mailing list
> Lede-dev@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev
> 
> 
> ___
> openwrt-devel mailing list
> openwrt-de...@lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
> 
> 
> ___
> lede-adm mailing list
> lede-...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-adm



-- 
Alexander Couzens

mail: lyn...@fe80.eu
jabber: 

Re: [LEDE-DEV] USB or SD card not mounted in Omega2+ router with LEDE iamge

2017-05-31 Thread Arun Kumar
> Hi All,
>
> I am facing an error where I can't find my USB or SD card and hence cant 
> upgrade to a new image.
>
> SD Card or USB device plugged in would be usually automounted at /tmp/mounts
> But after sysupgrading to the latest LEDE image, the Omega2+ router detects 
> the USB device getting plugged in but doesnt display anywhere. Not even in 
> /dev/sdaX location.
>
> When I plugin a USB device, I get this message:
> [ 6382.201671] usb 1-1: new high-speed USB device number 3 using ehci-platform
>
> root@Omega-FB25:/# ls /dev/
> bus mtd5ro  ttyS1
> console mtd6ttyS10
> cpu_dma_latency mtd6ro  ttyS11
> fullmtdblock0   ttyS12
> hwrng   mtdblock1   ttyS13
> kmsgmtdblock2   ttyS14
> log mtdblock3   ttyS15
> memory_bandwidthmtdblock4   ttyS2
> mmcblk0 mtdblock5   ttyS3
> mmcblk0p1   mtdblock6   ttyS4
> mtd0network_latency ttyS5
> mtd0ro  network_throughput  ttyS6
> mtd1nullttyS7
> mtd1ro  portttyS8
> mtd2ppp ttyS9
> mtd2ro  ptmxurandom
> mtd3pts watchdog
> mtd3ro  random  watchdog0
> mtd4shm zero
> mtd4ro  tty
> mtd5ttyS0
> root@Omega-FB25:/# dmesg | grep usb
> [2.584787] usbcore: registered new interface driver usbfs
> [2.590508] usbcore: registered new interface driver hub
> [2.596060] usbcore: registered new device driver usb
> [2.630320] phy phy-1012.usbphy.0: remote usb device wakeup disabled
> [2.637134] phy phy-1012.usbphy.0: UTMI 16bit 30MHz
> [3.118388] usb 1-1: new high-speed USB device number 2 using ehci-platform
> [ 6377.744209] usb 1-1: USB disconnect, device number 2
> [ 6382.201671] usb 1-1: new high-speed USB device number 3 using ehci-platform
>
> root@Omega-FB25:/# df -h
> FilesystemSize  Used Available Use% Mounted on
> /dev/root 2.5M  2.5M 0 100% /rom
> tmpfs61.5M 56.0K 61.5M   0% /tmp
> /dev/mtdblock6   28.3M820.0K 27.4M   3% /overlay
> overlayfs:/overlay   28.3M820.0K 27.4M   3% /
> tmpfs   512.0K 0512.0K   0% /dev
> root@Omega-FB25:/# cd /tmp/mounts
> /bin/ash: cd: can't cd to /tmp/mounts
>
> Tried with both USB 1 and USB 2.0 devices. So tried to connect to Wifi and 
> download new image. But iwconfig is not working.
>
> root@Omega-FB25:/# iwconfig
> /bin/ash: iwconfig: not found
>
> Note: This was working fine earlier and I did multiple image swaps between my 
> personal built ones and official images. I upgraded image from Omega2+ image 
> to LEDE image[1].
>
> Any suggestions on how to overcome this would be helpful.
>
> [1] 
> https://downloads.lede-project.org/releases/17.01.1/targets/ramips/mt7688/lede-17.01.1-ramips-mt7688-omega2p-squashfs-sysupgrade.bin
>
> Thanks,
> Arun

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


Re: [LEDE-DEV] dropbear & gcc 7.1.0

2017-05-31 Thread e9hack
Am 30.05.2017 um 08:25 schrieb Syrone Wong:
> Can this related to endianness? Based on current reports, it only
> occurs on big-endian platforms.
> 
> I found:
> 
> * Note: in order to use the optimized macros your platform must
> support unaligned 32 and 64 bit read/writes.
> * The x86 platforms allow this but some others [ARM for instance] do
> not. On those platforms you **MUST**
> * use the portable [slower] macros.
> 
> in 
> https://github.com/mkj/dropbear/blob/master/libtomcrypt/src/headers/tomcrypt_cfg.h
> 
> A quick way to verify this might be define LTC_NO_ASM.

Defining LTC_NO_ASM doesn't help. It seems, the problem is somewhere in 
libtommath. Patching of Makefile.in in
libtommath solves the problem for me:

#
--- a/libtommath/Makefile.in2017-05-18 16:47:02.0 +0200
+++ b/libtommath/Makefile.in2017-05-31 18:21:24.318437603 +0200
@@ -11,6 +11,8 @@
 # So that libtommath can include Dropbear headers for options and m_burn()
 CFLAGS += -I. -I$(srcdir) -I../libtomcrypt/src/headers/ 
-I$(srcdir)/../libtomcrypt/src/headers/ -I../ -I$(srcdir)/../

+CFLAGS += -O2
+
 ifndef IGNORE_SPEED

 #for speed
#

Regards,
Hartmut

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


[LEDE-DEV] [PATCH v4 1/2] ipq806x: Updated various ipq40xx pin definitions

2017-05-31 Thread Ram Chandra Jangir
This change populates default values for various GPIO functions
in ipq40xx pinctrl driver.

Signed-off-by: Ram Chandra Jangir 
---

Changes since v3:
*Added pinctrl defs,required for nand pinmux pullups.

 ...9-pinctrl-Updated-various-Pin-definitions.patch | 1332 
 1 file changed, 1332 insertions(+)
 create mode 100644 
target/linux/ipq806x/patches-4.9/852-ipq4019-pinctrl-Updated-various-Pin-definitions.patch

diff --git 
a/target/linux/ipq806x/patches-4.9/852-ipq4019-pinctrl-Updated-various-Pin-definitions.patch
 
b/target/linux/ipq806x/patches-4.9/852-ipq4019-pinctrl-Updated-various-Pin-definitions.patch
new file mode 100644
index 000..4267d47
--- /dev/null
+++ 
b/target/linux/ipq806x/patches-4.9/852-ipq4019-pinctrl-Updated-various-Pin-definitions.patch
@@ -0,0 +1,1332 @@
+From fc6cf61517b8b4ab4678659936fc7572f699d6e7 Mon Sep 17 00:00:00 2001
+From: Ram Chandra Jangir 
+Date: Tue, 28 Mar 2017 14:00:00 +0530
+Subject: [PATCH] ipq4019: pinctrl: Updated various Pin definitions
+
+Populate default values for various GPIO functions
+
+Signed-off-by: Ram Chandra Jangir 
+---
+ drivers/pinctrl/qcom/pinctrl-ipq4019.c | 1189 +---
+ 1 file changed,  insertions(+), 78 deletions(-)
+
+diff --git a/drivers/pinctrl/qcom/pinctrl-ipq4019.c 
b/drivers/pinctrl/qcom/pinctrl-ipq4019.c
+index 743d1f4..571eb51 100644
+--- a/drivers/pinctrl/qcom/pinctrl-ipq4019.c
 b/drivers/pinctrl/qcom/pinctrl-ipq4019.c
+@@ -276,16 +276,531 @@ DECLARE_QCA_GPIO_PINS(99);
+
+
+ enum ipq4019_functions {
++  qca_mux_rmii0_refclk,
++  qca_mux_wifi0_rfsilient0,
++  qca_mux_wifi1_rfsilient0,
++  qca_mux_smart2,
++  qca_mux_led4,
++  qca_mux_wifi0_cal,
++  qca_mux_wifi1_cal,
++  qca_mux_wifi_wci0,
++  qca_mux_rmii0_dv,
++  qca_mux_wifi_wci1,
++  qca_mux_rmii1_refclk,
++  qca_mux_blsp_spi1,
++  qca_mux_led5,
++  qca_mux_rmii10,
++  qca_mux_led6,
++  qca_mux_rmii11,
++  qca_mux_led7,
++  qca_mux_rmii1_dv,
++  qca_mux_led8,
++  qca_mux_rmii1_tx,
++  qca_mux_aud_pin,
++  qca_mux_led9,
++  qca_mux_rmii1_rx,
++  qca_mux_led10,
++  qca_mux_wifi0_rfsilient1,
++  qca_mux_wifi1_rfsilient1,
++  qca_mux_led11,
++  qca_mux_boot7,
++  qca_mux_qpic_pad,
++  qca_mux_pcie_clk,
++  qca_mux_tm_clk0,
++  qca_mux_wifi00,
++  qca_mux_wifi10,
++  qca_mux_mdio1,
++  qca_mux_prng_rosc,
++  qca_mux_dbg_out,
++  qca_mux_tm0,
++  qca_mux_wifi01,
++  qca_mux_wifi11,
++  qca_mux_atest_char3,
++  qca_mux_pmu0,
++  qca_mux_boot8,
++  qca_mux_tm1,
++  qca_mux_atest_char2,
++  qca_mux_pmu1,
++  qca_mux_boot9,
++  qca_mux_tm2,
++  qca_mux_atest_char1,
++  qca_mux_tm_ack,
++  qca_mux_wifi03,
++  qca_mux_wifi13,
++  qca_mux_qpic_pad4,
++  qca_mux_atest_char0,
++  qca_mux_tm3,
++  qca_mux_wifi02,
++  qca_mux_wifi12,
++  qca_mux_qpic_pad5,
++  qca_mux_smart3,
++  qca_mux_wcss0_dbg14,
++  qca_mux_tm4,
++  qca_mux_wifi04,
++  qca_mux_wifi14,
++  qca_mux_qpic_pad6,
++  qca_mux_wcss0_dbg15,
++  qca_mux_qdss_tracectl_a,
++  qca_mux_boot18,
++  qca_mux_tm5,
++  qca_mux_qpic_pad7,
++  qca_mux_atest_char,
++  qca_mux_wcss0_dbg4,
++  qca_mux_qdss_traceclk_a,
++  qca_mux_boot19,
++  qca_mux_tm6,
++  qca_mux_wcss0_dbg5,
++  qca_mux_qdss_cti_trig_out_a0,
++  qca_mux_boot14,
++  qca_mux_tm7,
++  qca_mux_chip_rst,
++  qca_mux_wcss0_dbg6,
++  qca_mux_qdss_cti_trig_out_b0,
++  qca_mux_boot11,
++  qca_mux_tm8,
++  qca_mux_wcss0_dbg7,
++  qca_mux_wcss1_dbg7,
++  qca_mux_boot20,
++  qca_mux_tm9,
++  qca_mux_qpic_pad1,
++  qca_mux_wcss0_dbg8,
++  qca_mux_wcss1_dbg8,
++  qca_mux_qpic_pad2,
++  qca_mux_wcss0_dbg9,
++  qca_mux_wcss1_dbg9,
++  qca_mux_qpic_pad3,
++  qca_mux_wcss0_dbg10,
++  qca_mux_wcss1_dbg10,
++  qca_mux_qpic_pad0,
++  qca_mux_wcss0_dbg11,
++  qca_mux_wcss1_dbg11,
++  qca_mux_qpic_pad8,
++  qca_mux_wcss0_dbg12,
++  qca_mux_wcss1_dbg12,
++  qca_mux_wifi034,
++  qca_mux_wifi134,
++  qca_mux_jtag_tdi,
+   qca_mux_gpio,
++  qca_mux_i2s_rx_bclk,
++  qca_mux_jtag_tck,
++  qca_mux_i2s_rx_fsync,
++  qca_mux_jtag_tms,
++  qca_mux_i2s_rxd,
++  qca_mux_smart0,
++  qca_mux_jtag_tdo,
++  qca_mux_jtag_rst,
++  qca_mux_jtag_trst,
++  qca_mux_mdio0,
++  qca_mux_wcss0_dbg18,
++  qca_mux_wcss1_dbg18,
++  qca_mux_qdss_tracedata_a,
++  qca_mux_mdc,
++  qca_mux_wcss0_dbg19,
++  qca_mux_wcss1_dbg19,
+   qca_mux_blsp_uart1,
++  qca_mux_wifi0_uart,
++  qca_mux_wifi1_uart,
++  qca_mux_smart1,
++  qca_mux_wcss0_dbg20,
++  qca_mux_wcss1_dbg20,
++  qca_mux_wifi0_uart0,
++  

[LEDE-DEV] [PATCH v4 2/2] ipq806x: Enable ubi image for ipq40xx AP-DK04.1-C1 board

2017-05-31 Thread Ram Chandra Jangir
This change add IPQ40xx AP-DK04.1-C1 board image support,
enables ubi image for IPQ40xx AP-DK04.1-C1 board and also
add sysupgrage support for AP-DK04.1-C1 and generates a
sysupgrade.tar image.

Testing:
 *Tested on IPQ40xx AP-DK04.1-C1:
   a. NAND boot
   b. ubi sysupgrade

Signed-off-by: Ram Chandra Jangir 
---

Changes since v3:
*Rebased the patch with TOT

 target/linux/ipq806x/base-files/lib/upgrade/platform.sh |  1 +
 target/linux/ipq806x/image/Makefile | 15 ++-
 2 files changed, 15 insertions(+), 1 deletion(-)

diff --git a/target/linux/ipq806x/base-files/lib/upgrade/platform.sh 
b/target/linux/ipq806x/base-files/lib/upgrade/platform.sh
index 8970285..fd08db3 100644
--- a/target/linux/ipq806x/base-files/lib/upgrade/platform.sh
+++ b/target/linux/ipq806x/base-files/lib/upgrade/platform.sh
@@ -12,6 +12,7 @@ platform_pre_upgrade() {
 
case "$board" in
ap148 |\
+   ap-dk04.1-c1 |\
d7800 |\
nbg6817 |\
r7500 |\
diff --git a/target/linux/ipq806x/image/Makefile 
b/target/linux/ipq806x/image/Makefile
index de6ddb6..4ed05eb 100644
--- a/target/linux/ipq806x/image/Makefile
+++ b/target/linux/ipq806x/image/Makefile
@@ -250,7 +250,20 @@ define Device/VR2600v
IMAGE/sysupgrade.bin := pad-extra 512 | append-kernel | pad-to 
{KERNEL_SIZE} | append-rootfs | pad-rootfs | append-metadata
 endef
 
+define Device/AP-DK04.1-C1
+   $(call Device/FitImage)
+   $(call Device/UbiFit)
+   DEVICE_DTS := qcom-ipq4019-ap.dk04.1-c1
+   KERNEL_LOADADDR := 0x80208000
+   KERNEL_INSTALL := 1
+   KERNEL_SIZE := 4048k
+   BLOCKSIZE := 128k
+   PAGESIZE := 2048
+   BOARD_NAME := ap-dk04.1-c1
+   DEVICE_TITLE := QCA AP-DK04.1-C1
+endef
+
 TARGET_DEVICES += AP148 AP148-legacy C2600 D7800 DB149 EA8500 FRITZ4040 R7500 \
- R7500v2 R7800 NBG6817 VR2600v
+ R7500v2 R7800 NBG6817 VR2600v AP-DK04.1-C1
 
 $(eval $(call BuildImage))
-- 
2.7.2


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


[LEDE-DEV] [PATCH] busybox: ash/hush fix for read-builtin command

2017-05-31 Thread Bastian Bittorf
this is a cherrypick from busybox-git HEAD:
f5470419404d643070db99d058405b714695b817

and can be removed when upgrading to
next busybox release. discussion here:
http://lists.busybox.net/pipermail/busybox/2017-May/085439.html

Signed-off-by: Bastian Bittorf 
---
 ...ush-fix-SIGCHLD-interrupting-read-builtin.patch | 147 +
 1 file changed, 147 insertions(+)
 create mode 100644 
package/utils/busybox/501-ash-hush-fix-SIGCHLD-interrupting-read-builtin.patch

diff --git 
a/package/utils/busybox/501-ash-hush-fix-SIGCHLD-interrupting-read-builtin.patch
 
b/package/utils/busybox/501-ash-hush-fix-SIGCHLD-interrupting-read-builtin.patch
new file mode 100644
index 000..1386dad
--- /dev/null
+++ 
b/package/utils/busybox/501-ash-hush-fix-SIGCHLD-interrupting-read-builtin.patch
@@ -0,0 +1,147 @@
+From f5470419404d643070db99d058405b714695b817 Mon Sep 17 00:00:00 2001
+From: Denys Vlasenko 
+Date: Mon, 22 May 2017 19:34:45 +0200
+Subject: [PATCH] ash,hush: fix SIGCHLD interrupting read builtin
+
+function old new   delta
+readcmd  169 217 +48
+shell_builtin_read  10871097 +10
+localcmd 366 364  -2
+builtin_read 197 193  -4
+--
+(add/remove: 0/0 grow/shrink: 2/2 up/down: 58/-6)  Total: 52 bytes
+
+Signed-off-by: Denys Vlasenko 
+Signed-off-by: Bastian Bittorf 
+---
+ shell/ash.c  |  7 +++
+ shell/ash_test/ash-read/read_SIGCHLD.right   |  2 ++
+ shell/ash_test/ash-read/read_SIGCHLD.tests   |  4 
+ shell/hush.c |  5 -
+ shell/hush_test/hush-read/read_SIGCHLD.right |  2 ++
+ shell/hush_test/hush-read/read_SIGCHLD.tests |  4 
+ shell/shell_common.c | 20 +++-
+ 7 files changed, 34 insertions(+), 10 deletions(-)
+ create mode 100644 shell/ash_test/ash-read/read_SIGCHLD.right
+ create mode 100755 shell/ash_test/ash-read/read_SIGCHLD.tests
+ create mode 100644 shell/hush_test/hush-read/read_SIGCHLD.right
+ create mode 100755 shell/hush_test/hush-read/read_SIGCHLD.tests
+
+diff --git a/shell/ash.c b/shell/ash.c
+index 70ee15e..60c8ffe 100644
+--- a/shell/ash.c
 b/shell/ash.c
+@@ -13268,6 +13268,7 @@ readcmd(int argc UNUSED_PARAM, char **argv 
UNUSED_PARAM)
+   /* "read -s" needs to save/restore termios, can't allow ^C
+* to jump out of it.
+*/
++ again:
+   INT_OFF;
+   r = shell_builtin_read(setvar0,
+   argptr,
+@@ -13280,6 +13281,12 @@ readcmd(int argc UNUSED_PARAM, char **argv 
UNUSED_PARAM)
+   );
+   INT_ON;
+ 
++  if ((uintptr_t)r == 1 && errno == EINTR) {
++  /* to get SIGCHLD: sleep 1 & read x; echo $x */
++  if (pending_sig == 0)
++  goto again;
++  }
++
+   if ((uintptr_t)r > 1)
+   ash_msg_and_raise_error(r);
+ 
+diff --git a/shell/ash_test/ash-read/read_SIGCHLD.right 
b/shell/ash_test/ash-read/read_SIGCHLD.right
+new file mode 100644
+index 000..b3dc7ab
+--- /dev/null
 b/shell/ash_test/ash-read/read_SIGCHLD.right
+@@ -0,0 +1,2 @@
++x='Ok'
++exitcode:0
+diff --git a/shell/ash_test/ash-read/read_SIGCHLD.tests 
b/shell/ash_test/ash-read/read_SIGCHLD.tests
+new file mode 100755
+index 000..c5f673a
+--- /dev/null
 b/shell/ash_test/ash-read/read_SIGCHLD.tests
+@@ -0,0 +1,4 @@
++x=BAD
++{ sleep 0.4; echo Ok; } | { sleep 0.2 & read x; echo "x='$x'"; }
++echo "exitcode:$?"
++
+diff --git a/shell/hush.c b/shell/hush.c
+index e18920f..125463a 100644
+--- a/shell/hush.c
 b/shell/hush.c
+@@ -9038,6 +9038,9 @@ static int FAST_FUNC builtin_type(char **argv)
+  * - terminates shell (regardless of interactivity);
+  * if it has non-empty trap:
+  * - executes trap and returns to read;
++ * SIGCHLD from children:
++ * - does not interrupt read regardless of interactivity:
++ *   try: sleep 1 & read x; echo $x
+  */
+ static int FAST_FUNC builtin_read(char **argv)
+ {
+@@ -9071,7 +9074,7 @@ static int FAST_FUNC builtin_read(char **argv)
+ 
+   if ((uintptr_t)r == 1 && errno == EINTR) {
+   unsigned sig = check_and_run_traps();
+-  if (sig && sig != SIGINT)
++  if (sig != SIGINT)
+   goto again;
+   }
+ 
+diff --git a/shell/hush_test/hush-read/read_SIGCHLD.right 
b/shell/hush_test/hush-read/read_SIGCHLD.right
+new file mode 100644
+index 000..b3dc7ab
+--- /dev/null
 b/shell/hush_test/hush-read/read_SIGCHLD.right
+@@ -0,0 +1,2 @@
++x='Ok'
++exitcode:0
+diff --git a/shell/hush_test/hush-read/read_SIGCHLD.tests 
b/shell/hush_test/hush-read/read_SIGCHLD.tests
+new file mode 100755
+index 

Re: [LEDE-DEV] [PATCH mdns] Fix sending replies to PTR questions

2017-05-31 Thread Cristian Morales Vega
On 10 May 2017 at 13:44, Rafał Miłecki  wrote:
> On 10 May 2017 at 14:20, Cristian Morales Vega  wrote:
>>> On 10 May 2017 at 13:14, Rafał Miłecki  wrote:
 After reading your comment & analyzing the code: yes. I expect this to 
 break
 support for queries you mentioned.

 My problem is that even without this commit or my local fix avahi-browse
 still doesn't detect services announced by umdns. I can see answers being
 sent so I assume there is something wrong with them.

 I've to debug it further.
>>
>> See http://lists.infradead.org/pipermail/lede-dev/2017-April/007177.html
>> and http://lists.infradead.org/pipermail/lede-dev/2017-April/007188.html
>> (yes, I have to improve my email workflow... and I managed to top-post 
>> before!)
>>
>> With those patches it works for me.
>
> Tip of the day: opening UDP port 5353 may help.
>
> Sorry for that mistake. I can see this working now.

This definitively still fails for me with an iPad as per
http://lists.infradead.org/pipermail/lede-dev/2017-April/007188.html

This is what I see

09:18:53.732502 IP SamKnowsiPadAir.sk.lan.mdns > 224.0.0.251.mdns: 0
[2q] [1au] PTR (QU)? _skhttp._tcp.local. PTR (QU)?
_skjitter._tcp.local. (81)
09:18:53.732776 IP 10.0.2.186.mdns > SamKnowsiPadAir.sk.lan.mdns: 0*-
[0q] 1/0/0 PTR SKWB8-d8:37:be:f8:21:25._skhttp._tcp.local. (86)
09:18:53.732859 IP 10.0.2.186.mdns > SamKnowsiPadAir.sk.lan.mdns: 0*-
[0q] 2/0/0 SRV SKWB8-d8:37:be:f8:21:25.local.:6500 5971 19287, TXT
"daemon=skhttp_server" (178)
09:18:53.732930 IP 10.0.2.186.mdns > SamKnowsiPadAir.sk.lan.mdns: 0*-
[0q] 1/0/0 PTR SKWB8-d8:37:be:f8:21:25._skjitter._tcp.local. (90)
09:18:53.732981 IP 10.0.2.186.mdns > SamKnowsiPadAir.sk.lan.mdns: 0*-
[0q] 2/0/0 SRV SKWB8-d8:37:be:f8:21:25.local.:6003 5971 19287, TXT
"daemon=hjitter_server" (183)
09:18:53.734287 IP6 fe80::8f2:45ac:2ef8:a5da.mdns > ff02::fb.mdns: 0
[2q] [1au] PTR (QU)? _skhttp._tcp.local. PTR (QU)?
_skjitter._tcp.local. (81)
09:18:53.866207 IP SamKnowsiPadAir.sk.lan.mdns > 224.0.0.251.mdns: 0
[4q] [1au] SRV (QU)? SKWB8-d8:37:be:f8:21:25._skhttp._tcp.local. TXT
(QU)? SKWB8-d8:37:be:f8:21:25._skhttp._tcp.local. SRV (QU)?
SKWB8-d8:37:be:f8:21:25._skjitter._tcp.local. TXT (QU)?
SKWB8-d8:37:be:f8:21:25._skjitter._tcp.local. (141)
09:18:53.866919 IP6 fe80::8f2:45ac:2ef8:a5da.mdns > ff02::fb.mdns: 0
[4q] [1au] SRV (QU)? SKWB8-d8:37:be:f8:21:25._skhttp._tcp.local. TXT
(QU)? SKWB8-d8:37:be:f8:21:25._skhttp._tcp.local. SRV (QU)?
SKWB8-d8:37:be:f8:21:25._skjitter._tcp.local. TXT (QU)?
SKWB8-d8:37:be:f8:21:25._skjitter._tcp.local. (141)

The iPad seems to expect the PTR and SRV records in the same packet
(12.1 from RFC6763 says they "should", not "must") and since the SRV
is not there it ends up asking for it... and not noticing we have sent
it before in a different packet.

So we need to handle SRV questions
(http://lists.infradead.org/pipermail/lede-dev/2017-April/007177.html).
But that's not enough because there is a timeout
(http://lists.infradead.org/pipermail/lede-dev/2017-April/007179.html),
which I am still not sure should be there.


-- 
Cristian Morales Vega

Email crist...@samknows.com
Office +44 (0) 20 3111 4330
Web:  www.samknows.com


This email is sent for and on behalf of SamKnows Limited.

This email and any attachments are confidential, legally privileged
and protected by copyright. If you are not the intended recipient
dissemination or copying of this email is prohibited. If you have
received this in error, please notify the sender by replying by email
and then delete the email completely from your system.

SamKnows Limited, Registered Number: 06510477, Registered Office: Hill
House, 1 Little New Street, London, EC4A 3TR. Registered in England
and Wales. Trade Mark 2507103

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


[LEDE-DEV] [PATCH] ar71xx: Fix UBIFS work on Mikrotik RB95x devices

2017-05-31 Thread adron
From: Sergey Sergeev 

If nand chip has no NAND_NO_SUBPAGE_WRITE flag on its options
ubifs can't use it mtd devices and the kernel crashes with error:
__nand_correct_data: uncorrectable ECC error

Signed-off-by: Sergey Sergeev 
---
 target/linux/ar71xx/files/arch/mips/ath79/mach-rb95x.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/target/linux/ar71xx/files/arch/mips/ath79/mach-rb95x.c 
b/target/linux/ar71xx/files/arch/mips/ath79/mach-rb95x.c
index 05e15e7..e940d6c 100644
--- a/target/linux/ar71xx/files/arch/mips/ath79/mach-rb95x.c
+++ b/target/linux/ar71xx/files/arch/mips/ath79/mach-rb95x.c
@@ -165,6 +165,8 @@ static int rb95x_nand_scan_fixup(struct mtd_info *mtd)
chip->ecc.layout = _nand_ecclayout;
}
 
+   chip->options = NAND_NO_SUBPAGE_WRITE;
+
return 0;
 }
 
-- 
2.7.4


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


Re: [LEDE-DEV] [PATCH] Fix UBIFS work on Mikrotik RB95x devices

2017-05-31 Thread John Crispin

Hi,

please resend the patch with a proper prefix in the subject "ar71xx:" 
and also an Signed-off-by line added in the description


John


On 30/05/17 22:30, ad...@yapic.net wrote:

From: Sergey Sergeev 

If nand chip has no NAND_NO_SUBPAGE_WRITE flag on its options
ubifs can't use it mtd devices and the kernel crashes with error:
__nand_correct_data: uncorrectable ECC error
---
  target/linux/ar71xx/files/arch/mips/ath79/mach-rb95x.c | 2 ++
  1 file changed, 2 insertions(+)

diff --git a/target/linux/ar71xx/files/arch/mips/ath79/mach-rb95x.c 
b/target/linux/ar71xx/files/arch/mips/ath79/mach-rb95x.c
index 05e15e7..e940d6c 100644
--- a/target/linux/ar71xx/files/arch/mips/ath79/mach-rb95x.c
+++ b/target/linux/ar71xx/files/arch/mips/ath79/mach-rb95x.c
@@ -165,6 +165,8 @@ static int rb95x_nand_scan_fixup(struct mtd_info *mtd)
chip->ecc.layout = _nand_ecclayout;
}
  
+	chip->options = NAND_NO_SUBPAGE_WRITE;

+
return 0;
  }
  



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


[LEDE-DEV] Patchwork opt-out confirmation

2017-05-31 Thread Patchwork
Hi,

This email is to confirm that you would like to opt-out from all email
from the patchwork system at patchwork.ozlabs.org.

To complete the opt-out process, visit:

 http://patchwork.ozlabs.org/confirm/b95f923f84317d568eb50df08f5bd8114d59a664/

If you didn't request this opt-out, you don't need to do anything.

Happy patchworking.

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


[LEDE-DEV] [lede] Patch notification: 1 patch updated

2017-05-31 Thread Patchwork
Hello,

The following patch (submitted by you) has been updated in patchwork:

 * lede: [LEDE-DEV] base-files: nand: use CI_KERNPART whenever the kernel 
volume is needed
 - http://patchwork.ozlabs.org/patch/768781/
 - for: LEDE development
was: New
now: Accepted

This email is a notification only - you do not need to respond.

Happy patchworking.

--

This is an automated mail sent by the patchwork system at
patchwork.ozlabs.org. To stop receiving these notifications, edit
your mail settings at:
  http://patchwork.ozlabs.org/mail/

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


Re: [LEDE-DEV] [PATCH] Adding acct_interval to wireless configuration

2017-05-31 Thread Yury Shvedov

Hi, Nick!

This is good point, but radius acct could be configured without radius 
auth. Even for open, wep and wpa/psk networks. I'm using radius acct to 
collect wireless client statistic among all of my networks. So there no 
Access-Accept messages available.



On 05/30/2017 11:42 PM, Nick Lowe wrote:

Hi Yury,

Have you tried returning an Acct-Interim-Interval attribute in the
Access-Accept packets sent by your RADIUS server, which should
configure this on a per client/station basis?

Cheers,

Nick


--
Kind regards
Yury Shvedov


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