W dniu 2019-12-06 o 18:44, Joe Ayers pisze:
Possibly the same symptoms don't exist on 128MB RAM devices.
Like there is some if condition, which is doing some nasty things on 64M
devices? I admit, that I don't have ath10k-ct source code under my pillow, but
it doesn't make much sense to me.
C
Hi,
please rephrase the "commit message" to be a sentence (or two ...).
Just send the text as reply to this e-mail, I will add it when merging the
patch. (So I do not need to add my SOB)
Best
Adrian
> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt
* replace strange error_info[0]=0 with complete zeroing of the buffer
* make the function body shorter and more clear, decrease indentation
levels
* fix format string warnings:
libuci.c:172:24: error: format string is not a string literal
[-Werror,-Wformat-nonliteral]
libuci.c:181:19: err
In order to extend test coverage and help testing refactoring.
Signed-off-by: Petr Štetiar
---
tests/cram/config/broken | 1 +
tests/cram/lua/basic.lua | 2 ++
tests/cram/test_ucilua.t | 1 +
3 files changed, 4 insertions(+)
create mode 100644 tests/cram/config/broken
diff --git a/tests/cram/c
From: Rosen Penev
Fixes:
cli.c:196:19: error: format string is not a string literal
[-Werror=format-nonliteral]
Signed-off-by: Rosen Penev
[split into separate commit]
Signed-off-by: Petr Štetiar
---
cli.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/cli.c b/cli.c
index 8970f4f0b8ce
In order to spot possible issues with direct impact on security during
QA on CI (GCC version 6 and higher).
Ref:
https://developers.redhat.com/blog/2018/03/21/compiler-and-linker-flags-gcc/
Signed-off-by: Petr Štetiar
---
CMakeLists.txt | 11 +--
1 file changed, 9 insertions(+), 2 delet
Fixes following warning reported by clang-10:
lua/uci.c:1050:1: error: no previous declaration for ‘luaopen_uci’
[-Werror=missing-declarations]
Signed-off-by: Petr Štetiar
---
lua/uci.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/lua/uci.c b/lua/uci.c
index ecfb2998d749..196a25bcf0
The DTS variable has been removed in 402138d12dca ("ramips: Derive
DTS name from device name in Makefile"), but the DEVICE_VARS entry
has been overlooked.
Remove it now since we are not using this variable.
This must _not_ be backported to 19.07, where the variable is still
in use.
Signed-off-by
> - SUNXI_DTS:=sun7i-a20-olinuxino-micro
> + SUNXI_SOC := =sun7i
The extra "=" has already been removed during my build tests (just forgot to
commit it). If someone tests on this device, please remove it manually.
Adrian
openpgp-digital-signature.asc
Description: PGP signature
_
This changes device definition to resemble the vendor_device scheme
already present for the majority of device compatible strings.
By doing this, we achieve several advantages at once:
- Image names and node names are more consistent with other targets.
- SUPPORTED_DEVICES can be set automatically
This consolidates the various repetitions of device names
in sunxi image Makefiles, and makes naming more consistent
in general.
This is achieved by calculating SUPPORTED_DEVICES from the
node name (as in ath79/ramips) and build the DTS name based
on that.
With this change, future device support
The device part in the SUNXI_DTS variable always corresponds to
device node name. This is another redundancy that can be removed
by calculating the DTS name from a newly introduced SUNXI_SOC
variable and the node name.
Signed-off-by: Adrian Schmutzler
---
target/linux/sunxi/image/Makefile |
On Sat, Dec 07, 2019 at 11:11:27PM +0100, m...@adrianschmutzler.de wrote:
> Well, address the issues we have agreed on in a v3.
Sure, will do tomorrow, thanks!
--
Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software!
mailto:fercer...@gmail.com
Well, address the issues we have agreed on in a v3.
From my scanning of the open discussion points, the following was unresolved in
some way:
1. Name prefix for LED labels
In ar71xx, all devices use "d-link". In ath79, so far two devices use "d-link"
and four devices use the device name.
Since d
On Sat, Dec 07, 2019 at 09:58:26PM +0100, Petr Štetiar wrote:
> > I'll be happy to change the patch in any way that will get it accepted.
>
> Then just do the requested changes in v3, solved.
I got an impression Adrian is not sure anymore he's requesting all the
changes we talked about, as I prov
Paul Fertser [2019-12-07 23:10:11]:
> Regarding this specific patch, I'd really like to hear the opinion of
> a maintainer (it seems like ath79 doesn't have an official maintainer
To me it seems like its maintained by a community, by developers like you,
with the little help of team members like
I'm planning to implement a Ubus client using Boost.Asio / C++'s Networking
TS, in C++, complete with a new implementation of the ubus wire protocol
(in C++).
Is there any documentation available about the Ubus wire protocol?
___
openwrt-devel mailing li
Hi Petr,
On Sat, Dec 07, 2019 at 04:04:13PM +0100, Petr Štetiar wrote:
> > You changed the status of the patch to "Changes requested" but you
>
> I've marked it as such, because of that discussion[1], but I admit, that I
> didn't read it thoroughly.
One thing I find a bit annoying about Patchwor
A const char * variable is being passed as a format string. Unfortunately,
this is not correct.
A constant expression needs to be passed so that GCC can determine the
types of the format properly.
Also fixed a different warning that needs a printf attribute.
Fixes:
error: format not a string li
echi->ehci
ochi->ohci
Signed-off-by: DENG Qingfang
---
target/linux/ath79/dts/ar7161_buffalo_wzr-hp-ag300h.dts | 6 +++---
target/linux/ath79/dts/ar7161_dlink_dir-825-b1.dts | 6 +++---
target/linux/ath79/dts/ar7161_netgear_wndr3700.dtsi | 6 +++---
target/linux/ath79/dts/ar7161_ubnt_ro
On Sat, Dec 7, 2019 at 5:19 AM Hauke Mehrtens wrote:
>
> On 12/6/19 7:02 PM, Ben Greear wrote:
> > On 12/6/19 9:44 AM, Joe Ayers wrote:
> >>>
> >>>
> Possibly the same symptoms don't exist on 128MB RAM devices.
> >>>
> >>> Like there is some if condition, which is doing some nasty things on 6
Paul Fertser [2019-12-07 17:04:06]:
Hi,
> You changed the status of the patch to "Changes requested" but you
I've marked it as such, because of that discussion[1], but I admit, that I
didn't read it thoroughly.
1. https://patchwork.ozlabs.org/patch/1192429/
-- ynezz
_
Hello dear maintainer,
You changed the status of the patch to "Changes requested" but you
haven't expressed your opinion on the topics raised during the
discussion. Please do so that I can make the changes to your liking.
--
Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software
On 12/6/19 7:02 PM, Ben Greear wrote:
> On 12/6/19 9:44 AM, Joe Ayers wrote:
>>>
>>>
Possibly the same symptoms don't exist on 128MB RAM devices.
>>>
>>> Like there is some if condition, which is doing some nasty things on 64M
>>> devices? I admit, that I don't have ath10k-ct source code under
Use extern "C" { ... } if using libubus.h in a C++ project.
Signed-off-by: Peter Stadler
---
libubus.h | 8
1 file changed, 8 insertions(+)
diff --git a/libubus.h b/libubus.h
index dc42ea7..6925514 100644
--- a/libubus.h
+++ b/libubus.h
@@ -14,6 +14,10 @@
#ifndef __LIBUBUS_H
#define
25 matches
Mail list logo
