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.
>---
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 | 22 ++
1 file changed, 22 in
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
---
target/linux/ar71xx/
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 +
target/linux/ar71xx/generic/profiles/atheros
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
b/target/linux/ar71xx/base-files/etc/uci-defaults/02_netw
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@
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
---
package/utils/ugps/Makefile | 2
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: d
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
+++ b/package/boot
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
+++ b/target/linux/m
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
+++ b/package/boot/uboot
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 deletions(-)
diff --gi
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
+++ b/package/boot
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 nee
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 develope
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, while
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 modif
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 AP
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 work-in
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, mass
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 bac
>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 m
22 matches
Mail list logo
