Re: [OpenWrt-Devel] [PATCH] uci: do not access invalid memory when updating an existing section
Hello!
First of all, thank you very very much for your patience and review.
You are right, my patch introduces an unintended change in behaviour, and
actually does not solve the problem.
That day I didn't see this.
However, I think it is still useful to report what happens here, even just for
the sole purpose of understanding it, and learning something for me. :)
[mrkiko@gatosaldo build]$ # both system installed uci ("uci"), and the modified
one, have been built now. Some infos:
[mrkiko@gatosaldo build]$ cat /etc/config/normalcfg
config normal_section ns
option a 1
config normal_section ns2
option b 2
[mrkiko@gatosaldo build]$ cat /etc/config/exmcfg
config example_section "secttest"
option a1
option b2
option c 4
config example_section "secttest"
option d4
option e 5
[mrkiko@gatosaldo build]$ cat /tmp/r/valgrind.sh
#!/bin/sh
valgrind --suppressions=/tmp/valgrind.suppressions --leak-check=full
--leak-resolution=high --show-reachable=no --log-file=valgrind.out $@
[mrkiko@gatosaldo build]$ # system installed uci
[mrkiko@gatosaldo build]$ uci show normalcfg
normalcfg.ns=normal_section
normalcfg.ns.a='1'
normalcfg.ns2=normal_section
normalcfg.ns2.b='2'
[mrkiko@gatosaldo build]$ /tmp/r/valgrind.sh uci show normalcfg
normalcfg.ns=normal_section
normalcfg.ns.a='1'
normalcfg.ns2=normal_section
normalcfg.ns2.b='2'
[mrkiko@gatosaldo build]$ cat valgrind.out
==12860== Memcheck, a memory error detector
==12860== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==12860== Using Valgrind-3.14.0.GIT and LibVEX; rerun with -h for copyright info
==12860== Command: uci show normalcfg
==12860== Parent PID: 12859
==12860==
==12860==
==12860== HEAP SUMMARY:
==12860== in use at exit: 0 bytes in 0 blocks
==12860== total heap usage: 24 allocs, 24 frees, 6,315 bytes allocated
==12860==
==12860== All heap blocks were freed -- no leaks are possible
==12860==
==12860== For counts of detected and suppressed errors, rerun with: -v
==12860== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
[mrkiko@gatosaldo build]$ uci show exmcfg
exmcfg.secttest=example_section
exmcfg.secttest.a='1'
exmcfg.secttest.b='2'
exmcfg.secttest.c='4'
exmcfg.secttest.d='4'
exmcfg.secttest.e='5'
[mrkiko@gatosaldo build]$ /tmp/r/valgrind.sh uci show exmcfg
/tmp/r/valgrind.sh: line 2: 12864 Segmentation fault (core dumped)
valgrind --suppressions=/tmp/valgrind.suppressions --leak-check=full
--leak-resolution=high --show-reachable=no --log-file=valgrind.out $@
[mrkiko@gatosaldo build]$ cat valgrind.out
==12864== Memcheck, a memory error detector
==12864== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==12864== Using Valgrind-3.14.0.GIT and LibVEX; rerun with -h for copyright info
==12864== Command: uci show exmcfg
==12864== Parent PID: 12863
==12864==
==12864== Invalid read of size 4
==12864==at 0x486E601: uci_lookup_list (list.c:280)
==12864==by 0x4870A0D: uci_parse_option (file.c:478)
==12864==by 0x4871247: uci_parse_line (file.c:530)
==12864==by 0x4871247: uci_import (file.c:680)
==12864==by 0x487195B: uci_file_load (file.c:910)
==12864==by 0x486F10C: uci_load (libuci.c:216)
==12864==by 0x486F240: uci_lookup_ptr (list.c:394)
==12864==by 0x109787: package_cmd (cli.c:312)
==12864==by 0x10A1EF: uci_do_package_cmd (cli.c:422)
==12864==by 0x10A1EF: uci_cmd (cli.c:674)
==12864==by 0x1092CF: main (cli.c:767)
==12864== Address 0x4a6759c is 28 bytes inside a block of size 52 free'd
==12864==at 0x4837471: realloc (in
/usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==12864==by 0x4871A7C: uci_realloc (util.c:49)
==12864==by 0x486FDA5: uci_set (list.c:717)
==12864==by 0x487118D: uci_parse_config (file.c:448)
==12864==by 0x487118D: uci_parse_line (file.c:518)
==12864==by 0x487118D: uci_import (file.c:680)
==12864==by 0x487195B: uci_file_load (file.c:910)
==12864==by 0x486F10C: uci_load (libuci.c:216)
==12864==by 0x486F240: uci_lookup_ptr (list.c:394)
==12864==by 0x109787: package_cmd (cli.c:312)
==12864==by 0x10A1EF: uci_do_package_cmd (cli.c:422)
==12864==by 0x10A1EF: uci_cmd (cli.c:674)
==12864==by 0x1092CF: main (cli.c:767)
==12864== Block was alloc'd at
==12864==at 0x4835558: malloc (in
/usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==12864==by 0x4871A31: uci_malloc (util.c:39)
==12864==by 0x486E1B2: uci_alloc_generic (list.c:50)
==12864==by 0x486E2EE: uci_alloc_section (list.c:194)
==12864==by 0x486FCF2: uci_set (list.c:699)
==12864==by 0x487118D: uci_parse_config (file.c:448)
==12864==by 0x487118D: uci_parse_line (file.c:518)
==12864==by 0x487118D: uci_import (file.c:680)
==12864==by 0x487195B: uci_file_load (file.c:910)
==12864==by 0x486F10C: uci_load (libuci.c:216)
==12864==by 0x486F240: uci_lookup_ptr (list.c:394)
==12864==by 0x109787: package_cmd (cli.c:312)
Re: [OpenWrt-Devel] [PATCH] uci: do not access invalid memory when updating an existing section
On Tue, 14 Aug 2018 at 04:56, Enrico Mioso wrote: > > Hello, and thank you for your help, and review. > I agree on not changing behaviour. the problem is not actually a memory leak, > but the fact that ptr->s->options seems to not be a valid pointer at that > point. > At least, this is what valgrind suggested, if I am not wrong or interpreting > wrongly the output. > realloc(ptr->s) won't invalidate ptr->s->options. That must happened somewhere else before. By the way, commit with relevant valgrind logs recorded can be helpful. Regards, yousong ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] uci: do not access invalid memory when updating an existing section
Hello, and thank you for your help, and review.
I agree on not changing behaviour. the problem is not actually a memory leak,
but the fact that ptr->s->options seems to not be a valid pointer at that point.
At least, this is what valgrind suggested, if I am not wrong or interpreting
wrongly the output.
Thanks again for all,
Enrico
On Mon, Aug 13, 2018 at 09:07:32PM +0800, Yousong Zhou wrote:
> On Sun, 12 Aug 2018 at 14:41, Enrico Mioso wrote:
> >
> > If a new section with the same name and type of an old one is found, a
> > memory reallocation happens. Still, the options list for the section is
> > not reinitialized, hence a stale pointer is being used.
> >
> > Signed-off-by: Enrico Mioso
> > ---
> > list.c | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/list.c b/list.c
> > index 25aec56..d934216 100644
> > --- a/list.c
> > +++ b/list.c
> > @@ -717,6 +717,7 @@ int uci_set(struct uci_context *ctx, struct uci_ptr
> > *ptr)
> > ptr->last = uci_realloc(ctx, ptr->s, sizeof(struct
> > uci_section));
> > ptr->s = uci_to_section(ptr->last);
> > uci_list_fixup(>s->e.list);
> > + uci_list_init(>s->options);
> > } else {
> > free(ptr->s->type);
> > }
>
> If I understand the original code right, the intention is to just
> update the section type as long as the name matches, regardless of
> whether there is a section type change. In both cases, there will be
> cleanup of existing options list. This is an established behavior and
> should not be changed for backward compatibility considerations.
>
> Regards,
> yousong
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] automated hardware test setup
Hi, I've won the prototype fund to work for the next 6 months on building up an automated hardware testing infrastructure [0]. I'll use LAVA [1] for it. The rough idea is to bootstrap an infrastructure for hw tests which also allow the community to contribute. Documentation is part of project which will cover the setup to allow replicating the whole setup or parts of it. It's possible to contribute to the setup by adding tests or devices. To get the project started, I'll start integrating 1 or 2 devices of an architecture. While write test cases. Later on I'll create a dashboard of the test cases and overview of the tests. There should be even statistics over the performance of the devices while OpenWrt develops, e.g: iperf or nat performance. So far I've the following architectures in mind: ar71xx/ath79 ramips x86 lantiq Feel free to give me feedback or test cases, you like to see. Best, lynxis [0] (german) https://prototypefund.de/project/automatisches-hardware-testsystem-fuer-openwrt/ [1] (software) https://validation.linaro.org/ [2] (instance) https://lava.fe80.eu/ [3] (code) https://code.fe80.eu/openwrt-lava/ -- Alexander Couzens mail: lyn...@fe80.eu jabber: lyn...@fe80.eu mobile: +4915123277221 gpg: 390D CF78 8BF9 AA50 4F8F F1E2 C29E 9DA6 A0DF 8604 pgpdEmgLPtyCX.pgp Description: OpenPGP digital signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] openwrt/packages: [RFC] Regarding preferences re: switch to codeload
On 2018-08-13 01:45 PM, Rosen Penev wrote: >> Furthermore I dislike the idea of tailoring download mechanisms around a >> specific proprietary service. This I agree with >> >> If the allegations about hash changes for unknown reasons are correct, >> then this raises a huge red flag for me > I can only imagine this to be the case if git history gets changed. > I'm sure it's automated. Well it's been happening intermittently for a least 2-3 years from what I've seen myself and heard from others. My own theory is a flaw in their reproducible builds strategy, and for some reason or other automated rebuilding of the tarballs even when the code hasn't changed. >> and I see no reason to not >> assume that codeload tarballs will eventually change as well, become >> rate limited, redirected, discontinued or changed in other arbitrary ways. > Well, there are people who believe Microsoft will cripple GitHub. I don't MS is relevant to the question, only profit motive, TBH. It's more have a reasonable concern that the drive to monetize will result in changes that make community more difficult (at best). >> >> So TLDR; I prefer a locally reproducible, cached tarball of a given SCM >> clone over an opaque Github offer. > It's not reproducible in all cases. See > https://github.com/openwrt/openwrt/pull/815 > > We could not produce the same tarball with the same hash. I was using > Ubuntu 16.04 FWIW Can you reproduce the non-reproduction, or was it a one-off that could be attribute temporary local issues? I'm sure the OpenWrt core team would really like to know about verifiable cases of issues with failures to reproduce, since this is considered rather important. >> >> >> My 2cents, > Mine are that it's better to use a tarball that is not locally > generated. I understand that ultimately the buildbots generate the > tarballs but then you potentially have a situation where a package > bump has the wrong hash since the buildbot and someone's local > environment can differ enough to matter. The whole point of the drive for reproducible builds (and tarballs) is to identify all factors that influence the final hash and so that one can be guaranteed of the same result irrespective of environment. If there is verifiable evidence somethings been missed, please file details at https://bugs.openwrt.org as that's not just an issue with an individual package but with the core system. > > My understanding is that OpenWrt can be built on Linux and some BSDs > like macOS or FreeBSD. > > The initial motivation for moving packages to codeload was to adjust > uscan's reporting of version numbers as git revisions when there are > git tags available. eg: using > > PKG_SOURCE_VERSION:=1ee4c4eac2f1f771ecc57d4f7ce298739bbc8a82 vs. > PKG_SOURCE_VERSION:=v$(PKG_VERSION) I'm not exactly convinced that's a good reason to adopt a tree-wide change involving a propriety and opaque mechanism. > > I also don't see why both codeload and buildbot generated tarballs > can't coexist. Have you looked at how the build system works in this regard? Regards, Daniel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] openwrt/packages: [RFC] Regarding preferences re: switch to codeload
On Mon, Aug 13, 2018 at 2:45 AM Jo-Philipp Wich wrote: > > Hi, > > personally I'm opposed to the entire code load thing. > > First of all I was unable to reproduce the tarballs offered by Github. > > Github seems to use an extended tar (pax) format while we pack our SCM > clones using the more traditional ustar format, however even using `tar > -cp -H pax --numeric-owner --owner=0 --group=0 --sort=name --mtime ...` > seems to yield a different tar stream compared to whatever is offered by > Github; > > - The order of the entries in the archive also seems to deviate from >that of `tar --sort=name`, it looks as if Github archives are sorted >using the "C" collate while GNU tar uses something else. > > - The PAX header format seems to be different, Github uses a global PAX >header while GNU tar produces per-member headers > > - There seem to be proprietary tags inside Github tar (comment=) >which are not present in the GNU equivalent > > Furthermore I dislike the idea of tailoring download mechanisms around a > specific proprietary service. > > If the allegations about hash changes for unknown reasons are correct, > then this raises a huge red flag for me I can only imagine this to be the case if git history gets changed. I'm sure it's automated. > and I see no reason to not > assume that codeload tarballs will eventually change as well, become > rate limited, redirected, discontinued or changed in other arbitrary ways. Well, there are people who believe Microsoft will cripple GitHub. > > So TLDR; I prefer a locally reproducible, cached tarball of a given SCM > clone over an opaque Github offer. It's not reproducible in all cases. See https://github.com/openwrt/openwrt/pull/815 We could not produce the same tarball with the same hash. I was using Ubuntu 16.04 FWIW. > > > My 2cents, Mine are that it's better to use a tarball that is not locally generated. I understand that ultimately the buildbots generate the tarballs but then you potentially have a situation where a package bump has the wrong hash since the buildbot and someone's local environment can differ enough to matter. My understanding is that OpenWrt can be built on Linux and some BSDs like macOS or FreeBSD. The initial motivation for moving packages to codeload was to adjust uscan's reporting of version numbers as git revisions when there are git tags available. eg: using PKG_SOURCE_VERSION:=1ee4c4eac2f1f771ecc57d4f7ce298739bbc8a82 vs. PKG_SOURCE_VERSION:=v$(PKG_VERSION) I also don't see why both codeload and buildbot generated tarballs can't coexist. > Jo > > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] ath79: Add support of Tp_Link MR-3040 v2
13.08.2018 19:34, Mathias Kresin пишет:
2018-08-13 18:28 GMT+02:00 Dmitry Tunin :
Add support for the ar71xx supported Tp_link MR-3040 v2 to ath79.
Signed-off-by: Dmitry Tunin
---
.../linux/ath79/base-files/etc/board.d/02_network | 1 +
.../linux/ath79/dts/ar9331_tplink_tl-mr3040-v2.dts | 161 +
target/linux/ath79/image/tiny-tp-link.mk | 10 ++
3 files changed, 172 insertions(+)
create mode 100644 target/linux/ath79/dts/ar9331_tplink_tl-mr3040-v2.dts
diff --git a/target/linux/ath79/base-files/etc/board.d/02_network
b/target/linux/ath79/base-files/etc/board.d/02_network
index 9e315ee..bfbc1ac 100755
--- a/target/linux/ath79/base-files/etc/board.d/02_network
+++ b/target/linux/ath79/base-files/etc/board.d/02_network
@@ -16,6 +16,7 @@ ath79_setup_interfaces()
tplink,re450-v2|\
tplink,tl-mr10u|\
tplink,tl-mr3020-v1|\
+ tplink,tl-mr3040-v2|\
tplink,tl-wr703n|\
ubnt,unifiac-lite|\
ubnt,unifiac-mesh|\
diff --git a/target/linux/ath79/dts/ar9331_tplink_tl-mr3040-v2.dts
b/target/linux/ath79/dts/ar9331_tplink_tl-mr3040-v2.dts
new file mode 100644
index 000..d72839e
--- /dev/null
+++ b/target/linux/ath79/dts/ar9331_tplink_tl-mr3040-v2.dts
@@ -0,0 +1,161 @@
+// SPDX-License-Identifier: GPL-2.0
+/dts-v1/;
+
+#include
+#include
+
+#include "ar9331.dtsi"
+
+/ {
+ model = "TP-Link TL-MR3040 V2";
+ compatible = "tplink,tl-mr3040-v2", "qca,ar9331";
+
+ leds {
+ compatible = "gpio-leds";
+
+ wlan {
+ label = "tp-link:green:wlan";
+ gpios = < 26 GPIO_ACTIVE_LOW>;
+ default-state = "off";
+ linux,default-trigger = "phy0tpt";
+ };
+
+ lan {
+ label = "tp-link:green:lan";
+ gpios = < 17 GPIO_ACTIVE_LOW>;
+ default-state = "off";
+ linux,default-trigger = "netdev:eth0";
I'm not sure if we should do it this way. I already dislike the
phy0tpt trigger in the devicetree source files, as it makes assumption
on how the interface is named in linux/in which order the wireless is
registered.
Something similar to the way the usbport triggers are handled - with
device name evaluation during runtime - would make more sense to me.
Any opinions about it?
Mathias
The discussion can be closed. It doesn't work either way.
I left an old /etc/config/system that was set to eth0.
I'll redo it a normal way.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] ath79: Add support of Tp_Link MR-3040 v2
13.08.2018 19:34, Mathias Kresin пишет:
2018-08-13 18:28 GMT+02:00 Dmitry Tunin :
Add support for the ar71xx supported Tp_link MR-3040 v2 to ath79.
Signed-off-by: Dmitry Tunin
---
.../linux/ath79/base-files/etc/board.d/02_network | 1 +
.../linux/ath79/dts/ar9331_tplink_tl-mr3040-v2.dts | 161 +
target/linux/ath79/image/tiny-tp-link.mk | 10 ++
3 files changed, 172 insertions(+)
create mode 100644 target/linux/ath79/dts/ar9331_tplink_tl-mr3040-v2.dts
diff --git a/target/linux/ath79/base-files/etc/board.d/02_network
b/target/linux/ath79/base-files/etc/board.d/02_network
index 9e315ee..bfbc1ac 100755
--- a/target/linux/ath79/base-files/etc/board.d/02_network
+++ b/target/linux/ath79/base-files/etc/board.d/02_network
@@ -16,6 +16,7 @@ ath79_setup_interfaces()
tplink,re450-v2|\
tplink,tl-mr10u|\
tplink,tl-mr3020-v1|\
+ tplink,tl-mr3040-v2|\
tplink,tl-wr703n|\
ubnt,unifiac-lite|\
ubnt,unifiac-mesh|\
diff --git a/target/linux/ath79/dts/ar9331_tplink_tl-mr3040-v2.dts
b/target/linux/ath79/dts/ar9331_tplink_tl-mr3040-v2.dts
new file mode 100644
index 000..d72839e
--- /dev/null
+++ b/target/linux/ath79/dts/ar9331_tplink_tl-mr3040-v2.dts
@@ -0,0 +1,161 @@
+// SPDX-License-Identifier: GPL-2.0
+/dts-v1/;
+
+#include
+#include
+
+#include "ar9331.dtsi"
+
+/ {
+ model = "TP-Link TL-MR3040 V2";
+ compatible = "tplink,tl-mr3040-v2", "qca,ar9331";
+
+ leds {
+ compatible = "gpio-leds";
+
+ wlan {
+ label = "tp-link:green:wlan";
+ gpios = < 26 GPIO_ACTIVE_LOW>;
+ default-state = "off";
+ linux,default-trigger = "phy0tpt";
+ };
+
+ lan {
+ label = "tp-link:green:lan";
+ gpios = < 17 GPIO_ACTIVE_LOW>;
+ default-state = "off";
+ linux,default-trigger = "netdev:eth0";
I'm not sure if we should do it this way. I already dislike the
phy0tpt trigger in the devicetree source files, as it makes assumption
on how the interface is named in linux/in which order the wireless is
registered.
Something similar to the way the usbport triggers are handled - with
device name evaluation during runtime - would make more sense to me.
Any opinions about it?
Mathias
In this case the device has only one Ethernet port. In other cases I
agree that this is not the best idea to assign LEDs this way.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] ath79: Add support of Tp_Link MR-3040 v2
2018-08-13 18:28 GMT+02:00 Dmitry Tunin :
> Add support for the ar71xx supported Tp_link MR-3040 v2 to ath79.
>
> Signed-off-by: Dmitry Tunin
> ---
> .../linux/ath79/base-files/etc/board.d/02_network | 1 +
> .../linux/ath79/dts/ar9331_tplink_tl-mr3040-v2.dts | 161
> +
> target/linux/ath79/image/tiny-tp-link.mk | 10 ++
> 3 files changed, 172 insertions(+)
> create mode 100644 target/linux/ath79/dts/ar9331_tplink_tl-mr3040-v2.dts
>
> diff --git a/target/linux/ath79/base-files/etc/board.d/02_network
> b/target/linux/ath79/base-files/etc/board.d/02_network
> index 9e315ee..bfbc1ac 100755
> --- a/target/linux/ath79/base-files/etc/board.d/02_network
> +++ b/target/linux/ath79/base-files/etc/board.d/02_network
> @@ -16,6 +16,7 @@ ath79_setup_interfaces()
> tplink,re450-v2|\
> tplink,tl-mr10u|\
> tplink,tl-mr3020-v1|\
> + tplink,tl-mr3040-v2|\
> tplink,tl-wr703n|\
> ubnt,unifiac-lite|\
> ubnt,unifiac-mesh|\
> diff --git a/target/linux/ath79/dts/ar9331_tplink_tl-mr3040-v2.dts
> b/target/linux/ath79/dts/ar9331_tplink_tl-mr3040-v2.dts
> new file mode 100644
> index 000..d72839e
> --- /dev/null
> +++ b/target/linux/ath79/dts/ar9331_tplink_tl-mr3040-v2.dts
> @@ -0,0 +1,161 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/dts-v1/;
> +
> +#include
> +#include
> +
> +#include "ar9331.dtsi"
> +
> +/ {
> + model = "TP-Link TL-MR3040 V2";
> + compatible = "tplink,tl-mr3040-v2", "qca,ar9331";
> +
> + leds {
> + compatible = "gpio-leds";
> +
> + wlan {
> + label = "tp-link:green:wlan";
> + gpios = < 26 GPIO_ACTIVE_LOW>;
> + default-state = "off";
> + linux,default-trigger = "phy0tpt";
> + };
> +
> + lan {
> + label = "tp-link:green:lan";
> + gpios = < 17 GPIO_ACTIVE_LOW>;
> + default-state = "off";
> + linux,default-trigger = "netdev:eth0";
I'm not sure if we should do it this way. I already dislike the
phy0tpt trigger in the devicetree source files, as it makes assumption
on how the interface is named in linux/in which order the wireless is
registered.
Something similar to the way the usbport triggers are handled - with
device name evaluation during runtime - would make more sense to me.
Any opinions about it?
Mathias
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] ath79: Add support of Tp_Link MR-3040 v2
Add support for the ar71xx supported Tp_link MR-3040 v2 to ath79.
Signed-off-by: Dmitry Tunin
---
.../linux/ath79/base-files/etc/board.d/02_network | 1 +
.../linux/ath79/dts/ar9331_tplink_tl-mr3040-v2.dts | 161 +
target/linux/ath79/image/tiny-tp-link.mk | 10 ++
3 files changed, 172 insertions(+)
create mode 100644 target/linux/ath79/dts/ar9331_tplink_tl-mr3040-v2.dts
diff --git a/target/linux/ath79/base-files/etc/board.d/02_network
b/target/linux/ath79/base-files/etc/board.d/02_network
index 9e315ee..bfbc1ac 100755
--- a/target/linux/ath79/base-files/etc/board.d/02_network
+++ b/target/linux/ath79/base-files/etc/board.d/02_network
@@ -16,6 +16,7 @@ ath79_setup_interfaces()
tplink,re450-v2|\
tplink,tl-mr10u|\
tplink,tl-mr3020-v1|\
+ tplink,tl-mr3040-v2|\
tplink,tl-wr703n|\
ubnt,unifiac-lite|\
ubnt,unifiac-mesh|\
diff --git a/target/linux/ath79/dts/ar9331_tplink_tl-mr3040-v2.dts
b/target/linux/ath79/dts/ar9331_tplink_tl-mr3040-v2.dts
new file mode 100644
index 000..d72839e
--- /dev/null
+++ b/target/linux/ath79/dts/ar9331_tplink_tl-mr3040-v2.dts
@@ -0,0 +1,161 @@
+// SPDX-License-Identifier: GPL-2.0
+/dts-v1/;
+
+#include
+#include
+
+#include "ar9331.dtsi"
+
+/ {
+ model = "TP-Link TL-MR3040 V2";
+ compatible = "tplink,tl-mr3040-v2", "qca,ar9331";
+
+ leds {
+ compatible = "gpio-leds";
+
+ wlan {
+ label = "tp-link:green:wlan";
+ gpios = < 26 GPIO_ACTIVE_LOW>;
+ default-state = "off";
+ linux,default-trigger = "phy0tpt";
+ };
+
+ lan {
+ label = "tp-link:green:lan";
+ gpios = < 17 GPIO_ACTIVE_LOW>;
+ default-state = "off";
+ linux,default-trigger = "netdev:eth0";
+ };
+
+ led3g {
+ label = "tp-link:green:3g";
+ gpios = < 27 GPIO_ACTIVE_LOW>;
+ default-state = "off";
+ trigger-sources = <_port>;
+ linux,default-trigger = "usbport";
+ };
+ };
+
+ keys {
+ compatible = "gpio-keys-polled";
+ poll-interval = <20>;
+
+ reset {
+ label = "reset";
+ linux,code = ;
+ gpios = < 11 GPIO_ACTIVE_HIGH>;
+ debounce-interval = <60>;
+ };
+
+ sw1 {
+ label = "sw1";
+ linux,input-type = ;
+ linux,code = ;
+ gpios = < 19 GPIO_ACTIVE_HIGH>;
+ debounce-interval = <60>;
+ };
+
+ sw2 {
+ label = "sw2";
+ linux,input-type = ;
+ linux,code = ;
+ gpios = < 20 GPIO_ACTIVE_HIGH>;
+ debounce-interval = <60>;
+ };
+ };
+
+ reg_usb_vbus: reg_usb_vbus {
+ compatible = "regulator-fixed";
+ regulator-name = "usb_vbus";
+ regulator-min-microvolt = <500>;
+ regulator-max-microvolt = <500>;
+ gpio = < 18 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ };
+};
+
+ {
+ clock-frequency = <2500>;
+};
+
+ {
+ status = "okay";
+};
+
+ {
+ status = "okay";
+};
+
+ {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ dr_mode = "host";
+ vbus-supply = <_usb_vbus>;
+ status = "okay";
+
+ hub_port: port@1 {
+ reg = <1>;
+ #trigger-source-cells = <0>;
+ };
+};
+
+_phy {
+ status = "okay";
+};
+
+ {
+ num-chipselects = <1>;
+ status = "okay";
+
+ flash@0 {
+ compatible = "jedec,spi-nor";
+ spi-max-frequency = <10400>;
+ reg = <0>;
+
+ partitions {
+ compatible = "fixed-partitions";
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ uboot: partition@0 {
+ label = "u-boot";
+ reg = <0x00 0x02>;
+ read-only;
+ };
+
+ partition@2 {
+ label = "firmware";
+ reg = <0x02 0x3d>;
+ };
+
+ art: partition@3f {
+ label = "art";
+ reg = <0x3f 0x01>;
+ read-only;
+ };
+ };
+ };
+};
+
+ {
+
[OpenWrt-Devel] RFT: ar71xx/mac80211 update
Hi, as 19.01 will probably use v4.14 as baseline and ath79 wont be a full replacement for ar71xx by then we decided to bump ar71xx to v4.14. This is available for testing inside my staging tree -> https://git.openwrt.org/?p=openwrt/staging/blogic.git;a=shortlog;h=refs/heads/staging The tree also holds an update to mac80211, bumping it to the v4.18 wifi drivers. If anyone would like to test ar71xx and/or mac80211, feel free to do so. John ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] openwrt/packages: [RFC] Regarding preferences re: switch to codeload
On 13/08/18 11:45, Jo-Philipp Wich wrote: So TLDR; I prefer a locally reproducible, cached tarball of a given SCM clone over an opaque Github offer. I would like to second that notion John ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] uci: do not access invalid memory when updating an existing section
On Sun, 12 Aug 2018 at 14:41, Enrico Mioso wrote:
>
> If a new section with the same name and type of an old one is found, a
> memory reallocation happens. Still, the options list for the section is
> not reinitialized, hence a stale pointer is being used.
>
> Signed-off-by: Enrico Mioso
> ---
> list.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/list.c b/list.c
> index 25aec56..d934216 100644
> --- a/list.c
> +++ b/list.c
> @@ -717,6 +717,7 @@ int uci_set(struct uci_context *ctx, struct uci_ptr *ptr)
> ptr->last = uci_realloc(ctx, ptr->s, sizeof(struct
> uci_section));
> ptr->s = uci_to_section(ptr->last);
> uci_list_fixup(>s->e.list);
> + uci_list_init(>s->options);
> } else {
> free(ptr->s->type);
> }
If I understand the original code right, the intention is to just
update the section type as long as the name matches, regardless of
whether there is a section type change. In both cases, there will be
cleanup of existing options list. This is an established behavior and
should not be changed for backward compatibility considerations.
Regards,
yousong
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH 1/2] ar7: remove linux 3.18 support
This target is on 4.9 currently. It seems the support for this old kernel never got dropped. Signed-off-by: Koen Vandeputte --- target/linux/ar7/config-3.18 | 129 .../001-mips-ar7-fix-serial.patch | 23 -- ...re-the-port-type-s-FCR-value-is-used.patch | 48 --- .../patches-3.18/100-fix-highmem-offset.patch | 11 - ...R7-allow-NULL-clock-for-clk_get_rate.patch | 45 --- target/linux/ar7/patches-3.18/110-flash.patch | 22 -- .../160-vlynq_try_remote_first.patch | 300 -- .../200-free-mem-below-kernel-offset.patch| 15 - .../patches-3.18/300-add-ac49x-platform.patch | 85 - .../patches-3.18/310-ac49x-prom-support.patch | 20 -- .../320-ac49x-mtd-partitions.patch| 35 -- .../linux/ar7/patches-3.18/920-ar7part.patch | 118 --- .../ar7/patches-3.18/925-actiontec_leds.patch | 95 -- .../ar7/patches-3.18/950-cpmac_titan.patch| 52 --- 14 files changed, 998 deletions(-) delete mode 100644 target/linux/ar7/config-3.18 delete mode 100644 target/linux/ar7/patches-3.18/001-mips-ar7-fix-serial.patch delete mode 100644 target/linux/ar7/patches-3.18/002-MIPS-AR7-ensure-the-port-type-s-FCR-value-is-used.patch delete mode 100644 target/linux/ar7/patches-3.18/100-fix-highmem-offset.patch delete mode 100644 target/linux/ar7/patches-3.18/101-MIPS-AR7-allow-NULL-clock-for-clk_get_rate.patch delete mode 100644 target/linux/ar7/patches-3.18/110-flash.patch delete mode 100644 target/linux/ar7/patches-3.18/160-vlynq_try_remote_first.patch delete mode 100644 target/linux/ar7/patches-3.18/200-free-mem-below-kernel-offset.patch delete mode 100644 target/linux/ar7/patches-3.18/300-add-ac49x-platform.patch delete mode 100644 target/linux/ar7/patches-3.18/310-ac49x-prom-support.patch delete mode 100644 target/linux/ar7/patches-3.18/320-ac49x-mtd-partitions.patch delete mode 100644 target/linux/ar7/patches-3.18/920-ar7part.patch delete mode 100644 target/linux/ar7/patches-3.18/925-actiontec_leds.patch delete mode 100644 target/linux/ar7/patches-3.18/950-cpmac_titan.patch diff --git a/target/linux/ar7/config-3.18 b/target/linux/ar7/config-3.18 deleted file mode 100644 index a91d45e8d79e.. --- a/target/linux/ar7/config-3.18 +++ /dev/null @@ -1,129 +0,0 @@ -CONFIG_ADM6996_PHY=y -CONFIG_AR7=y -CONFIG_AR7_TI=y -# CONFIG_AR7_TYPE_AC49X is not set -CONFIG_AR7_TYPE_TI=y -CONFIG_AR7_WDT=y -CONFIG_ARCH_BINFMT_ELF_RANDOMIZE_PIE=y -CONFIG_ARCH_DISCARD_MEMBLOCK=y -CONFIG_ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE=y -CONFIG_ARCH_HAVE_CUSTOM_GPIO_H=y -CONFIG_ARCH_HIBERNATION_POSSIBLE=y -CONFIG_ARCH_MIGHT_HAVE_PC_PARPORT=y -CONFIG_ARCH_MIGHT_HAVE_PC_SERIO=y -CONFIG_ARCH_REQUIRE_GPIOLIB=y -CONFIG_ARCH_SUSPEND_POSSIBLE=y -CONFIG_ARCH_WANT_IPC_PARSE_VERSION=y -CONFIG_BOOT_ELF32=y -CONFIG_CEVT_R4K=y -CONFIG_CLONE_BACKWARDS=y -CONFIG_CMDLINE="rootfstype=squashfs,jffs2" -CONFIG_CMDLINE_BOOL=y -# CONFIG_CMDLINE_OVERRIDE is not set -CONFIG_CPMAC=y -CONFIG_CPU_GENERIC_DUMP_TLB=y -CONFIG_CPU_HAS_PREFETCH=y -CONFIG_CPU_HAS_SYNC=y -CONFIG_CPU_LITTLE_ENDIAN=y -CONFIG_CPU_MIPS32=y -CONFIG_CPU_MIPS32_R1=y -CONFIG_CPU_MIPSR1=y -CONFIG_CPU_R4K_CACHE_TLB=y -CONFIG_CPU_R4K_FPU=y -CONFIG_CPU_SUPPORTS_32BIT_KERNEL=y -CONFIG_CPU_SUPPORTS_HIGHMEM=y -CONFIG_CSRC_R4K=y -CONFIG_DMA_NONCOHERENT=y -CONFIG_EARLY_PRINTK=y -CONFIG_ETHERNET_PACKET_MANGLE=y -CONFIG_FIXED_PHY=y -CONFIG_GENERIC_ATOMIC64=y -CONFIG_GENERIC_CLOCKEVENTS=y -CONFIG_GENERIC_CLOCKEVENTS_BUILD=y -CONFIG_GENERIC_CMOS_UPDATE=y -CONFIG_GENERIC_IO=y -CONFIG_GENERIC_IRQ_SHOW=y -CONFIG_GENERIC_PCI_IOMAP=y -CONFIG_GENERIC_SMP_IDLE_THREAD=y -CONFIG_GPIOLIB=y -CONFIG_GPIO_DEVRES=y -CONFIG_HARDWARE_WATCHPOINTS=y -CONFIG_HAS_DMA=y -CONFIG_HAS_IOMEM=y -CONFIG_HAS_IOPORT=y -# CONFIG_HAVE_64BIT_ALIGNED_ACCESS is not set -CONFIG_HAVE_ARCH_JUMP_LABEL=y -CONFIG_HAVE_ARCH_KGDB=y -CONFIG_HAVE_ARCH_TRACEHOOK=y -# CONFIG_HAVE_BOOTMEM_INFO_NODE is not set -CONFIG_HAVE_CC_STACKPROTECTOR=y -CONFIG_HAVE_CLK=y -CONFIG_HAVE_CONTEXT_TRACKING=y -CONFIG_HAVE_C_RECORDMCOUNT=y -CONFIG_HAVE_DEBUG_KMEMLEAK=y -CONFIG_HAVE_DEBUG_STACKOVERFLOW=y -CONFIG_HAVE_DMA_API_DEBUG=y -CONFIG_HAVE_DMA_ATTRS=y -CONFIG_HAVE_DYNAMIC_FTRACE=y -CONFIG_HAVE_FTRACE_MCOUNT_RECORD=y -CONFIG_HAVE_FUNCTION_GRAPH_TRACER=y -CONFIG_HAVE_FUNCTION_TRACER=y -CONFIG_HAVE_FUNCTION_TRACE_MCOUNT_TEST=y -CONFIG_HAVE_GENERIC_DMA_COHERENT=y -CONFIG_HAVE_IDE=y -CONFIG_HAVE_KERNEL_BZIP2=y -CONFIG_HAVE_KERNEL_GZIP=y -CONFIG_HAVE_KERNEL_LZ4=y -CONFIG_HAVE_KERNEL_LZMA=y -CONFIG_HAVE_KERNEL_LZO=y -CONFIG_HAVE_KERNEL_XZ=y -CONFIG_HAVE_MEMBLOCK=y -CONFIG_HAVE_MEMBLOCK_NODE_MAP=y -CONFIG_HAVE_MOD_ARCH_SPECIFIC=y -CONFIG_HAVE_NET_DSA=y -CONFIG_HAVE_OPROFILE=y -CONFIG_HAVE_PERF_EVENTS=y -CONFIG_HAVE_SYSCALL_TRACEPOINTS=y -CONFIG_HW_RANDOM=y -CONFIG_HZ_PERIODIC=y -CONFIG_INITRAMFS_SOURCE="" -CONFIG_IP17XX_PHY=y -CONFIG_IRQ_CPU=y -CONFIG_IRQ_FORCED_THREADING=y -CONFIG_IRQ_WORK=y -CONFIG_KALLSYMS=y -CONFIG_LEDS_GPIO=y -CONFIG_LEDS_TRIGGER_HEARTBEAT=y
[OpenWrt-Devel] [PATCH 2/2] kernel: bump 3.18 to 3.18.118
Refreshed all patches. Compile-tested on: adm5120, adm8668, au1000, mcs814x, ppc40x, ppc44x, xburst Runtime-tested on: none Signed-off-by: Koen Vandeputte --- include/kernel-version.mk | 4 +- .../patches-3.18/007-adm5120_pci.patch| 2 +- .../101-cfi_fixup_macronix_bootloc.patch | 2 +- .../patches-3.18/120-rb153_cf_driver.patch| 2 +- .../patches-3.18/002-adm8668_pci.patch| 2 +- .../patches-3.18/004-tulip_pci_split.patch| 56 +-- .../patches-3.18/005-tulip_platform.patch | 36 ++-- .../pending-3.18/001-mtdsplit_backport.patch | 2 +- .../002-phy_drivers_backport.patch| 16 +++--- ...11-Allow-set-network-namespace-by-fd.patch | 2 +- ...eue-to-die-properly-when-a-PADT-is-r.patch | 4 +- ...ppp-remove-PPPOX_ZOMBIE-socket-state.patch | 2 +- ...ry-corruption-in-padt-work-structure.patch | 6 +- ...ment-fix-headroom-tests-and-skb-leak.patch | 8 +-- ...ame2-and-add-RENAME_WHITEOUT-support.patch | 6 +- ...11-jffs2-add-RENAME_EXCHANGE-support.patch | 10 ++-- ...-support-for-Quectel-EC20-Mini-PCIe-.patch | 4 +- ...-quirk-for-Quectel-EC20-Mini-PCIe-mo.patch | 19 +++ .../pending-3.18/202-reduce_module_size.patch | 2 +- .../214-spidev_h_portability.patch| 2 +- ...prevent-redefinition-of-struct-ethhd.patch | 2 +- ...et_0002-add-buffer-write-cmd-timeout.patch | 2 +- .../476-mtd-spi-nor-add-eon-en25qh32.patch| 2 +- ...mtd-device-named-ubi-or-data-on-boot.patch | 4 +- ...etfilter_match_bypass_default_checks.patch | 8 +-- .../pending-3.18/630-packet_socket_type.patch | 16 +++--- .../645-bridge_multicast_to_unicast.patch | 6 +- .../pending-3.18/650-pppoe_header_pad.patch | 20 --- .../653-disable_netlink_trim.patch| 2 +- ...Add-support-for-MAP-E-FMRs-mesh-mode.patch | 28 +- ...urce-specific-default-route-handling.patch | 4 +- ...ng-with-source-address-failed-policy.patch | 18 +++--- ...T-skip-GRO-for-foreign-MAC-addresses.patch | 12 ++-- .../pending-3.18/701-phy_extension.patch | 4 +- .../702-phy_add_aneg_done_function.patch | 2 +- ...detach-callback-to-struct-phy_driver.patch | 2 +- ...710-phy-add-mdio_register_board_info.patch | 2 +- .../pending-3.18/721-phy_packets.patch| 2 +- .../pending-3.18/834-ledtrig-libata.patch | 8 +-- .../pending-3.18/902-debloat_proc.patch | 14 ++--- .../linux/mcs814x/patches-3.18/004-usb.patch | 2 +- ...mtd-cfi_cmdset_0002-force-word-write.patch | 4 +- .../patches-3.18/013-ohci_workarounds.patch | 10 ++-- ...-Optimize-NAND_ECC_HW_OOB_FIRST-read.patch | 4 +- ...-for-subpage-reads-for-NAND_ECC_HW_O.patch | 4 +- ...e-3-wire-spi-mode-for-the-display-fo.patch | 2 +- 46 files changed, 173 insertions(+), 198 deletions(-) diff --git a/include/kernel-version.mk b/include/kernel-version.mk index fb1ad321b9cd..90b1b0e6ebdd 100644 --- a/include/kernel-version.mk +++ b/include/kernel-version.mk @@ -2,11 +2,11 @@ LINUX_RELEASE?=1 -LINUX_VERSION-3.18 = .71 +LINUX_VERSION-3.18 = .118 LINUX_VERSION-4.9 = .119 LINUX_VERSION-4.14 = .62 -LINUX_KERNEL_HASH-3.18.71 = 5abc9778ad44ce02ed6c8ab52ece8a21c6d20d21f6ed8a19287b4a38a50c1240 +LINUX_KERNEL_HASH-3.18.118 = f94c9e2931829f4c972f005a7dc643f7e0c8eac87239c2a1060af763b8e3f8af LINUX_KERNEL_HASH-4.9.119 = 49e17f01a1a607b4b1ab28dc7177e103943151866c3956fd83edc8a4aae60b35 LINUX_KERNEL_HASH-4.14.62 = 51ca4d7e8ee156dc0f19bc7768915cfae41dbb0b4f251e4fa8b178c5674c22ab diff --git a/target/linux/adm5120/patches-3.18/007-adm5120_pci.patch b/target/linux/adm5120/patches-3.18/007-adm5120_pci.patch index a5a0abf43bca..7a84217beee2 100644 --- a/target/linux/adm5120/patches-3.18/007-adm5120_pci.patch +++ b/target/linux/adm5120/patches-3.18/007-adm5120_pci.patch @@ -10,7 +10,7 @@ obj-$(CONFIG_PCI_AR724X) += pci-ar724x.o --- a/include/linux/pci_ids.h +++ b/include/linux/pci_ids.h -@@ -1820,6 +1820,9 @@ +@@ -1821,6 +1821,9 @@ #define PCI_VENDOR_ID_CB 0x1307 /* Measurement Computing */ diff --git a/target/linux/adm5120/patches-3.18/101-cfi_fixup_macronix_bootloc.patch b/target/linux/adm5120/patches-3.18/101-cfi_fixup_macronix_bootloc.patch index a0caa680bc2f..92937fce14da 100644 --- a/target/linux/adm5120/patches-3.18/101-cfi_fixup_macronix_bootloc.patch +++ b/target/linux/adm5120/patches-3.18/101-cfi_fixup_macronix_bootloc.patch @@ -67,7 +67,7 @@ --- a/drivers/mtd/chips/Kconfig +++ b/drivers/mtd/chips/Kconfig -@@ -188,6 +188,14 @@ config MTD_CFI_AMDSTD +@@ -189,6 +189,14 @@ config MTD_CFI_AMDSTD provides support for command set 0002, used on chips including the AMD Am29LV320. diff --git a/target/linux/adm5120/patches-3.18/120-rb153_cf_driver.patch b/target/linux/adm5120/patches-3.18/120-rb153_cf_driver.patch index c5d4d3a57edf..5390bd95b726 100644 --- a/target/linux/adm5120/patches-3.18/120-rb153_cf_driver.patch +++
Re: [OpenWrt-Devel] openwrt/packages: [RFC] Proposed flattening of menuconfig menus
On 2018-08-13 06:19 AM, Karl Palsson wrote: > > "Daniel F. Dickinson" wrote: >> Posting on list as I think the discussion should include as >> folks as possible in the discussion. >> >> https://github.com/openwrt/packages/issues/6745 >> >>> Especially when getting started with OpenWrt finding things in menuconfig >>> is complicated by the second level menus that are sometimes used and >>> sometimes not, even when the category exists. >>> >>> Further not everything fits neatly in a category. >>> >>> Finally when, years ago, I tried to improve the situation the above >>> resulted in titles that I think make it harder to find things (in >>> retrospect). >>> >>> Therefore I would like to do a mass removal of the second-level menus, >>> leaving only the broad top-level categories like 'net', and 'utlitiies'. >>> >>> Thoughts? > > I agree that the earlier attempts at adding more categories was > probably unhelpful, and just required more places to try checking > for things. I think there's still room for _some_ second level > menus (all of the iotivity stuff is fine in it's own menu for > instance) , but they would need to have a "maintainer" of sorts, Yeah, it's not *all* bad... > to try and sheperd new packages into that menu. You're only > talking about the net/utilities/libraries trees right? > luci/languages/kernel are all well maintained. Ah thank you for reminding of that, it's a good point. > > What I honestly think is the biggest missing thing sometimes is > proper package descriptions. > > I'd support undoing many of the nestings that were done, > especially under networking. Especially the vague ones like "file > transfer" and "bit torrent" and "download managers" and the > "routing" ""vpn" "wwan" "firewall tunnel Hwell it's more work, but I think a better solution would be do do a better job of defining the second level. In most cases I think my efforts at the second level tried too hard to keep the number of second level menus low, resulting in vague/confusing terminology. I wonder if there are 4-5 categories (plus certain specialty labels like iotivity and a 'vpn' (and only vpn) category) that can be used as a way to make looking for net and utilities (especially) more manageable (libraries I'm still thinking more of just flat because their purpose is to support other package rather than to exist for their own sake), without ending up with an overly large number of submenus (which I think is more detrimental than helpful). Regards, Daniel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] openwrt/packages: [RFC] Proposed flattening of menuconfig menus
"Daniel F. Dickinson" wrote: > Posting on list as I think the discussion should include as > folks as possible in the discussion. > > https://github.com/openwrt/packages/issues/6745 > > > Especially when getting started with OpenWrt finding things in menuconfig > > is complicated by the second level menus that are sometimes used and > > sometimes not, even when the category exists. > > > > Further not everything fits neatly in a category. > > > > Finally when, years ago, I tried to improve the situation the above > > resulted in titles that I think make it harder to find things (in > > retrospect). > > > > Therefore I would like to do a mass removal of the second-level menus, > > leaving only the broad top-level categories like 'net', and 'utlitiies'. > > > > Thoughts? I agree that the earlier attempts at adding more categories was probably unhelpful, and just required more places to try checking for things. I think there's still room for _some_ second level menus (all of the iotivity stuff is fine in it's own menu for instance) , but they would need to have a "maintainer" of sorts, to try and sheperd new packages into that menu. You're only talking about the net/utilities/libraries trees right? luci/languages/kernel are all well maintained. What I honestly think is the biggest missing thing sometimes is proper package descriptions. I'd support undoing many of the nestings that were done, especially under networking. Especially the vague ones like "file transfer" and "bit torrent" and "download managers" and the "routing" ""vpn" "wwan" "firewall tunnel Cheers, Karl P signature.html Description: OpenPGP Digital Signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] openwrt/packages: [RFC] Regarding preferences re: switch to codeload
Hi, personally I'm opposed to the entire code load thing. First of all I was unable to reproduce the tarballs offered by Github. Github seems to use an extended tar (pax) format while we pack our SCM clones using the more traditional ustar format, however even using `tar -cp -H pax --numeric-owner --owner=0 --group=0 --sort=name --mtime ...` seems to yield a different tar stream compared to whatever is offered by Github; - The order of the entries in the archive also seems to deviate from that of `tar --sort=name`, it looks as if Github archives are sorted using the "C" collate while GNU tar uses something else. - The PAX header format seems to be different, Github uses a global PAX header while GNU tar produces per-member headers - There seem to be proprietary tags inside Github tar (comment=) which are not present in the GNU equivalent Furthermore I dislike the idea of tailoring download mechanisms around a specific proprietary service. If the allegations about hash changes for unknown reasons are correct, then this raises a huge red flag for me and I see no reason to not assume that codeload tarballs will eventually change as well, become rate limited, redirected, discontinued or changed in other arbitrary ways. So TLDR; I prefer a locally reproducible, cached tarball of a given SCM clone over an opaque Github offer. My 2cents, Jo ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 2/2] ath79: add support for Fritz!Box 4020
13.08.2018 08:23, John Crispin: Hi this following chunk need to be annotated and sent upstream. also using initvals might not be the best option. please also check if there is a binding doc and add this new property. You might want to name the property "lines-initial-states" as defined for the pcf857x i2c gpio expander[0]. Mathias [0] https://www.kernel.org/doc/Documentation/devicetree/bindings/gpio/gpio-pcf857x.txt ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 2/2] ath79: add support for Fritz!Box 4020
Hi this following chunk need to be annotated and sent upstream. also using initvals might not be the best option. please also check if there is a binding doc and add this new property. John diff --git a/target/linux/ath79/patches-4.14/005-gpio-74x164-add-initvals.patch b/target/linux/ath79/patches-4.14/005-gpio-74x164-add-initvals.patch new file mode 100644 index 00..d437ada3e0 --- /dev/null +++ b/target/linux/ath79/patches-4.14/005-gpio-74x164-add-initvals.patch @@ -0,0 +1,12 @@ +--- a/drivers/gpio/gpio-74x164.c b/drivers/gpio/gpio-74x164.c +@@ -151,6 +151,9 @@ static int gen_74x164_probe(struct spi_d + chip->gpio_chip.parent = >dev; + chip->gpio_chip.owner = THIS_MODULE; + ++ of_property_read_u8_array(spi->dev.of_node, "initvals", chip->buffer, ++chip->registers); ++ + mutex_init(>lock); + + ret = __gen_74x164_write_config(chip); ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] openwrt/packages: [RFC] Proposed flattening of menuconfig menus
On 2018-08-13 01:51 AM, Eric Luehrsen wrote: > On 08/13/2018 01:29 AM, Daniel F. Dickinson wrote: >> Posting on list as I think the discussion should include as folks as >> possible in the discussion. >> >> https://github.com/openwrt/packages/issues/6745 >> >>> Especially when getting started with OpenWrt finding things in >>> menuconfig is complicated by the second level menus that are >>> sometimes used and sometimes not, even when the category exists. >>> >>> Further not everything fits neatly in a category. >>> >>> Finally when, years ago, I tried to improve the situation the above >>> resulted in titles that I think make it harder to find things (in >>> retrospect). >>> >>> Therefore I would like to do a mass removal of the second-level >>> menus, leaving only the broad top-level categories like 'net', and >>> 'utlitiies'. >>> >>> Thoughts? > > I see some pragmatic challenges. Without some sorting, a category such > as "Network" on a project for open source routers becomes a mess (take a > second; let it soak in). This can be compensated in a few ways, but they The problem, for me, is that, at present, there *is* a lot of unsorted stuff in the Network section, which I view as making it worse than if it were either all unsorted or not at sorted. I don't know how often you try and find things in menuconfig, or do a general browse of all packages, but it's a mess. > are all a lot of work, and some could fetch unwanted emotional feedback. > For one example, more aggressive use of "packages-abandoned" is probably > needed even outside this topics consideration, but how do you qualify > user interest or proactive maintenance? For another example, remove the > catch-all "Network" and create 4-5 other named top level menus, but > while a few categories may be obvious and well stocked, some other > categories may not be so clear. I like the idea of a small number of additional top-level menus (though I still think some kind catchall for what doesn't really fit anywhere is needed, but not have that be the go-to practise). Part of the problem (and reason I initially proposed flattening) is that sorting seems to not really happen consistently, and it is a great deal of work to sort after the fact. Regards, Daniel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] openwrt/packages: [RFC] Regarding preferences re: switch to codeload
Posting here as this seems to me to be a project decision: From: https://github.com/openwrt/packages/issues/6748 > @neheb Has submitted a number of PR's (referenced in #6584), full list of > his/her PR's (which probably include the codeload thing for any github > pulls): https://github.com/openwrt/packages/pulls/neheb > > @diizzyy has also mentioned codeload. @karlp appears to feel the change is > for marginal gain (based on #6584 (comment)). > > I personally think that tree-wide changes, especially for something @yousong > has been trying solve another way ought t be clearly discussed and not just > brought in through the back door, hence this ticket and I'll be following up > on openwrt-devel as well. ** Clarification for neheb this is for GitHub projects without release tarballs; of course as I understand the GitHub release tarball situation, the hash changes for unknown reasons for time to time, which makes them useless. Regards, Daniel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
