Avoids redefining bool.
Signed-off-by: Rosen Penev
---
package/network/utils/iperf/Makefile | 2 +-
package/network/utils/iperf/patches/010-libcxx.patch | 12
2 files changed, 13 insertions(+), 1 deletion(-)
create mode 100644 package/network/utils/iperf/patches/01
Currently in OpenWrt, there are two libc++: libstdcpp and uClibc++. The
former is huge and the latter supports only C++98 with some basic support
for C++11. Those C++ versions seem to be specific to the compiler version
libcxx supports C++11 and above while being much smaller than libstdcpp.
On mt
Hey Sven,
On Fri, Dec 13, 2019 at 11:51:14PM +0100, Sven Roederer wrote:
> good point. But also on master seems to be no entry for this board in
> "01_leds". So I assume the default case fits for it.
I looked several times through the config and was unable to see the
default case. Apparently, y
Am Freitag, 13. Dezember 2019, 21:07:23 CET schrieb Paul Fertser:
> Hello,
>
> On Fri, Dec 13, 2019 at 08:50:46PM +0100, Sven Roederer wrote:
> > .../ath79/base-files/etc/board.d/02_network | 5 +
> > .../etc/hotplug.d/firmware/11-ath10k-caldata | 1 +
> > .../ath79/dts/qca9531_glinet_gl-a
Adrian,
it's just that I've this patch around for some time, as I use this device on
19.07. So just sharing this patch ...
Sven
Am Freitag, 13. Dezember 2019, 21:21:14 CET schrieb Adrian Schmutzler:
> Hi Sven,
>
> so, the primary question remains unanswered: Why should exactly this device
> be
Hi Sven,
> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org] On
> Behalf Of Sven Roederer
> Sent: Freitag, 13. Dezember 2019 20:51
> To: openwrt-devel@lists.openwrt.org
> Cc: Luochongjun
> Subject: [OpenWrt-Devel] [PATCH 19.07] ath79: add support fo
Hello,
On Fri, Dec 13, 2019 at 08:50:46PM +0100, Sven Roederer wrote:
> .../ath79/base-files/etc/board.d/02_network | 5 +
> .../etc/hotplug.d/firmware/11-ath10k-caldata | 1 +
> .../ath79/dts/qca9531_glinet_gl-ar750.dts | 142 ++
> target/linux/ath79/image/generic.mk
From: Luochongjun
This patch supports gl-ar750, which was previously supported by ar71xx.
Specification:
- SOC: QCA9531 (650MHz)
- Flash: 16 MiB (W25Q128FVSG)
- RAM: 128 MiB DDR2
- Ethernet: 10/100: 2xLAN + 10/100: 1xWAN
- Wireless: 2.4GHz (bgn) and 5GHz (ac)
- USB: 1x USB 2.0 port
- Switch: 1x
Hi,
> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org] On
> Behalf Of DENG Qingfang
> Sent: Freitag, 13. Dezember 2019 17:24
> To: openwrt-devel@lists.openwrt.org
> Subject: [OpenWrt-Devel] [PATCH] ramips: add support for JCG JHR-AC876M
>
> JCG JHR
JCG JHR-AC876M is an AC2600M router
Hardware specs:
SoC: MT7621AT
2.4GHz: MT7615N 4x4 @ PCIe0
5GHz: MT7615N 4x4 @ PCIe1
Flash: Winbond W25Q128JVSQ 16MiB
RAM: Nanya NT5CB128M16 256MiB
USB 2.0 and 3.0 ports
6 LEDs, 3 of which are connected to SoC GPIO
Reset and WPS buttons
Flash ins
Move the set-irq-affinity script to mt7621 because it is the only
SMP subtarget.
Signed-off-by: DENG Qingfang
---
.../ramips/{ => mt7621}/base-files/etc/init.d/set-irq-affinity| 0
1 file changed, 0 insertions(+), 0 deletions(-)
rename target/linux/ramips/{ => mt7621}/base-files/etc/init.d/
Hi John,
> -Original Message-
> From: John Crispin [mailto:j...@phrozen.org]
> Sent: Freitag, 13. Dezember 2019 14:07
> To: Adrian Schmutzler ; openwrt-
> de...@lists.openwrt.org
> Subject: Re: [OpenWrt-Devel] [RFT PATCH v2] mediatek: split base-files into
> subtargets
>
> On 13/12/2019 1
Was inadvertantly missed from the inital forward port from ar71xx to
ath79.
Fixes: 1588114cf2 ath79: add etactica-eg200 support
Signed-off-by: Karl Palsson
---
package/boot/uboot-envtools/files/ath79 | 1 +
1 file changed, 1 insertion(+)
diff --git a/package/boot/uboot-envtools/files/ath79
b/
W dniu 11.12.2019 o 11:42, Adrian Schmutzler pisze:
> Hi,
>
>> -Original Message-
>> From: Tomasz Maciej Nowak [mailto:tome...@o2.pl]
>> Sent: Dienstag, 10. Dezember 2019 14:39
>> To: Adrian Schmutzler ; openwrt-
>> de...@lists.openwrt.org
>> Subject: Re: [OpenWrt-Devel] [PATCH 2/2] sunxi:
On 13/12/2019 11:05, Rafał Miłecki wrote:
From: Rafał Miłecki
I noticed that "ubus call block info" was listing only the last added
devices for me. It has appeared to be a wrong vlist usage + memory
corruption.
After review/apply I'd like to cherry-pick those fixes to 19.07.
Acked-by: John C
On 13/12/2019 12:11, Adrian Schmutzler wrote:
This splits some base-files across subtargets, as done previously
on ath79 and ramips and also introduced for mt7629 subtarget here
already.
While at it, apply the following fixes:
- Remove lots of trailing whitespaces
- Remove wildcard on unielec,u7
On 26.08.2019 17:33, Rafał Miłecki wrote:
I noticed a bug in "block" tool behavior. It was providing inconsistent
UUIDs for my disks with NTFS partitions.
(...)
That bug was exposed by cache_load(0) vs. cache_load(1). Those calls
result in different order of buffer allocation in the
blkid_probe
This splits some base-files across subtargets, as done previously
on ath79 and ramips and also introduced for mt7629 subtarget here
already.
While at it, apply the following fixes:
- Remove lots of trailing whitespaces
- Remove wildcard on unielec,u7623-02-emmc-512m
- Remove inconsistent quotation
From: Rafał Miłecki
The point of "hotplug" call is to add or remove a single entry to/from
devices list. Using vlist_update() and vlist_flush() was clearing whole
list (and leaving the last entry in case of adding a devices).
Signed-off-by: Rafał Miłecki
---
blockd.c | 2 --
1 file changed, 2
From: Rafał Miłecki
vlist_add() expects key to point a persistent memory as it doesn't make
its copy. Passing blob_attr of current message was resulting in
undefined/random behavior including list corruption and possible
crashes.
Signed-off-by: Rafał Miłecki
---
blockd.c | 2 +-
1 file changed
From: Rafał Miłecki
I noticed that "ubus call block info" was listing only the last added
devices for me. It has appeared to be a wrong vlist usage + memory
corruption.
After review/apply I'd like to cherry-pick those fixes to 19.07.
Rafał Miłecki (2):
blockd: fix vlist memory corruption
bl
On Fri, 13 Dec 2019 at 16:58, Jo-Philipp Wich wrote:
>
> Hi,
>
> per definition, zone forward policies were only ever meant to apply to
> traffic between interfaces within the same zone *not* to traffic
> anywhere else.
>
> Your patch would break that assumption as far as I can see.
>
> ~ Jo
I se
Hi,
per definition, zone forward policies were only ever meant to apply to
traffic between interfaces within the same zone *not* to traffic
anywhere else.
Your patch would break that assumption as far as I can see.
~ Jo
signature.asc
Description: OpenPGP digital signature
23 matches
Mail list logo
