Re: [OpenWrt-Devel] ubus: potential regression in request processing

2015-08-31 Thread Zefir Kurtisi
On 08/27/2015 02:17 PM, Felix Fietkau wrote: > [...] > This change (mostly untested) might fix the issue while still preserving > processing of pending notifications, what do you think? > > [...] Thank you for the suggestion, Felix. Alas, while trying to dig deeper, I noticed another recent

Re: [OpenWrt-Devel] ubus: potential regression in request processing

2015-08-31 Thread Felix Fietkau
On 2015-08-31 19:02, Zefir Kurtisi wrote: > On 08/27/2015 02:17 PM, Felix Fietkau wrote: >> [...] >> This change (mostly untested) might fix the issue while still preserving >> processing of pending notifications, what do you think? >> >> [...] > > Thank you for the suggestion, Felix. Alas,

Re: [OpenWrt-Devel] [PATCH 0/3] Add support of ARC architecture

2015-08-31 Thread Alexey Brodkin
Hello, On Thu, 2015-08-27 at 14:03 +0300, Alexey Brodkin wrote: > This patch series adds support for the Synopsys DesignWare ARC architecture. > > DesignWare ARC700 is family of 32-bit CPUs developed by Synopsys, Inc. > > Since version 3.9 ARC architecture is supported in mainline Linux

Re: [OpenWrt-Devel] [rt3050f] A small question

2015-08-31 Thread Ben Agor
Layne Edwards astrumtech.net> writes: > > > Andrew, > Did you modify the eeprom extract hotplug for your board? > trunk/target/linux/ramips/base-files/etc/hotplug.d/firmware/10-rt2x00-eeprom > Regards,Layne Hi Layne or who it may concern, I'm having a similar problem. I'm wondering what I

[OpenWrt-Devel] [PATCH 1/5] packages: uboot-mxs: place binaries in the designated path

2015-08-31 Thread Michael Heimpold
Signed-off-by: Michael Heimpold --- package/boot/uboot-mxs/Makefile |6 ++ 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/package/boot/uboot-mxs/Makefile b/package/boot/uboot-mxs/Makefile index 1686f60..a6a137c 100644 --- a/package/boot/uboot-mxs/Makefile

[OpenWrt-Devel] [PATCH 5/5] packages: uboot-mxs: fix I2SE Duckbill variant

2015-08-31 Thread Michael Heimpold
The current patch to add Duckbill support is wrong and does not even compile. So replace this patch with a working one. Signed-off-by: Michael Heimpold --- .../uboot-mxs/patches/001-add-i2se-duckbill.patch | 82 +++- 1 file changed, 46 insertions(+), 36

[OpenWrt-Devel] [PATCH 2/5] packages: uboot-mxs: do no modify the U-Boot image, copy as-is

2015-08-31 Thread Michael Heimpold
Signed-off-by: Michael Heimpold --- package/boot/uboot-mxs/Makefile |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/package/boot/uboot-mxs/Makefile b/package/boot/uboot-mxs/Makefile index a6a137c..eee73d2 100644 --- a/package/boot/uboot-mxs/Makefile +++

[OpenWrt-Devel] [PATCH 4/5] target/mxs: adopt SD card generation to fixed U-Boot path

2015-08-31 Thread Michael Heimpold
Signed-off-by: Michael Heimpold --- target/linux/mxs/image/Makefile |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/target/linux/mxs/image/Makefile b/target/linux/mxs/image/Makefile index 256d4e6..7e6a1a0 100644 --- a/target/linux/mxs/image/Makefile

[OpenWrt-Devel] [PATCH 3/5] packages: uboot-mxs: bless UBOOT_IMAGE with a meaning, otherwise we could drop this C left-over

2015-08-31 Thread Michael Heimpold
Signed-off-by: Michael Heimpold --- package/boot/uboot-mxs/Makefile |6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/package/boot/uboot-mxs/Makefile b/package/boot/uboot-mxs/Makefile index eee73d2..373b8d8 100644 --- a/package/boot/uboot-mxs/Makefile

[OpenWrt-Devel] [PATCH 0/5] packages: uboot-mxs: various fixes

2015-08-31 Thread Michael Heimpold
This patch series is the first step to bring OpenWrt's Duckbill support back in shape. U-Boot mainline support is still on my TODO list, so for the meantime, handle this with a proper patch. Michael Heimpold (5): packages: uboot-mxs: place binaries in the designated path packages: uboot-mxs:

[OpenWrt-Devel] [PATCH] ugps: fix filename to eliminate build problems

2015-08-31 Thread Dirk Neukirchen
due to ordering PKG_SOURCE_VERSION is not defined leading to a filename "ugps-.tar.bz2" This errors out when an older version is in the dl/ dir (or LOCALMIRROR) fix order and use uhttpd file naming scheme to visibly include date Signed-off-by: Dirk Neukirchen ---

Re: [OpenWrt-Devel] [PATCHv3 openwrt 1/2] Revert "kernel: disable multicast-to-unicast translation for ipv6 neighbor solicitation (#17625)"

2015-08-31 Thread Linus Lüssing
On Mon, Aug 31, 2015 at 11:29:45AM +0200, Steven Barth wrote: > > > > >Ok, I was able to easily reproduce the issue here. Looking at the > >tcpdump the wifi client receives its own Neighbor Solicitation > >again, reflected through the bridge-hairpin option. > > Why are we reflecting packets

Re: [OpenWrt-Devel] [PATCHv3 openwrt 1/2] Revert "kernel: disable multicast-to-unicast translation for ipv6 neighbor solicitation (#17625)"

2015-08-31 Thread Steven Barth
>Ok, I was able to easily reproduce the issue here. Looking at the >tcpdump the wifi client receives its own Neighbor Solicitation >again, reflected through the bridge-hairpin option. Why are we reflecting packets back to the originator anyway? Could it not be excluded? Btw. once we are bit

[OpenWrt-Devel] [PATCH] Restore buildability of the AP121 target

2015-08-31 Thread Attila Lendvai
hi! resending this patch properly, including a signed-off entry. it would be nice if this could make its way into CC, because this is a regression. the obsolete copy is this: https://patchwork.ozlabs.org/patch/508527/ -- • attila lendvai • PGP: 963F 5D5F 45C7 DFCD 0A39 -- “In a democracy,

[OpenWrt-Devel] [PATCH] AP121 target: fix board detection in ar71xx.sh

2015-08-31 Thread Attila Lendvai
hi! resending this patch properly, including a signed-off entry. it would be nice if this could make its way into CC, because this fixes a regression. the obsolete copy is this: https://patchwork.ozlabs.org/patch/508527/ -- • attila lendvai • PGP: 963F 5D5F 45C7 DFCD 0A39 -- We are all

Re: [OpenWrt-Devel] QUALCOMM spoof attempt detected: [PATCH 1/4] ar71xx: uci-defaults: fix ap143 to appropriate group

2015-08-31 Thread McClintock, Matthew
This mailing list should already be whitelist’ed - what’s going on? -M On 8/31/15, 11:22 PM, "request.allow.sp...@qualcomm.com on behalf of request.allow.spoof" wrote: >PLEASE RESEND THE INFORMATION USING A PERSONAL EMAIL ADDRESS.

[OpenWrt-Devel] [PATCH 4/4] mac80211: ath9k: enable hw manual peak calibration for QCA9561

2015-08-31 Thread miaoqing
From: Miaoqing Pan This patch fix https://lists.openwrt.org/pipermail/openwrt-devel/ 2015-August/034979.html. As the peak detect calibration is set incorrectly. Signed-off-by: Miaoqing Pan --- ...6-ath9k_enable_hw_manual_peak_calibration.patch

[OpenWrt-Devel] AR9344 OpenWrt (Scanning Device)

2015-08-31 Thread John kerry
Hi, I am working on AR9344 openWrt project. When I am doing scanning the device wireless It's taking very long time to display the Scanning devices. Could anyone help me, how I can reduce the delay. Thanks, ___ openwrt-devel mailing list

[OpenWrt-Devel] [PATCH 3/4] ar71xx: add support for ap152 reference board

2015-08-31 Thread miaoqing
From: Miaoqing Pan Signed-off-by: Miaoqing Pan --- target/linux/ar71xx/base-files/lib/ar71xx.sh | 3 + target/linux/ar71xx/config-4.1 | 1 + .../ar71xx/files/arch/mips/ath79/mach-ap152.c | 141

[OpenWrt-Devel] [PATCH 1/4] ar71xx: uci-defaults: fix ap143 to appropriate group

2015-08-31 Thread miaoqing
From: Miaoqing Pan Signed-off-by: Miaoqing Pan --- target/linux/ar71xx/base-files/etc/uci-defaults/02_network | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/target/linux/ar71xx/base-files/etc/uci-defaults/02_network

[OpenWrt-Devel] [PATCH 2/4] ath79: dev-eth: fix QCA9561 set phy interface mode and mask

2015-08-31 Thread miaoqing
From: Miaoqing Pan QCA9563 and QCA9561 are two series of Qualcomm SoC Dragonfly. The only different is QCA9563 w/o internal switch. It has one GMAC with SGMII interface. But they have the same device ID(0x1150). So they share the same codes. Signed-off-by: Miaoqing Pan

Re: [OpenWrt-Devel] [PATCHv3 openwrt 1/2] Revert "kernel: disable multicast-to-unicast translation for ipv6 neighbor solicitation (#17625)"

2015-08-31 Thread Linus Lüssing
On Mon, Aug 31, 2015 at 12:19:44PM +0200, Linus Lüssing wrote: > I had somehow expected that mac80211 would exclude it. But looks like it > doesn't. Looks like mac80211 on an STA does that for frames with a multicast destination (to prevent getting the own multicast packets echo'd back once the