Re: [OpenWrt-Devel] [OpenWrt-Commits] r48171 - trunk/include

[Felix Fietkau]

On 2016-01-10 21:00, Daniel Curran-Dickinson wrote:
> Hi Felix,
> 
> I sent this to the list, but since you seem to have taken an interest in 
> this, I'm also sending direct; don't take that as a need to rush, just 
> thought you might be interested.
Please don't send duplicate emails to me and the list separately, it
makes dealing with email threads really annoying. Think about whether
you want to Cc me or not before you hit send the first time...
If you sent something to the list and forgot to Cc me, you can also
point me at the mail on IRC. I'm already having a hard time keeping the
size of my inbox under control...

> I will try to try this patch soon, since you've got something out before 
> me.  I believe this resolves the issues I mentioned previously, bit not 
> another issue I ran into when working on my own patch; namely the fact 
> that if a package is not built then 
> /pkginfo(?)/.provides is not generated and 
> therefore the package-ipkg dependecy search logic fails to see that the 
> dependency has been satisfied (e.g. kmod-cryptodev requires that e.g. 
> kmod-crypto-authenc which depends on kmod-crypto-manager which depends 
> on kmod-crypto-aead which supplies aead.ko be built during *this* build 
> (i.e. by SDK, albeit by just packaging the *.ko shipped with SDK) so 
> that kmod-aead.provides contains the text 'aead.ko', which gives the 
> information package-ipkg needs to believe that kmod-cryptodev's 
> dependencies have been met.
> 
> The issue is legacy $(if $(SDK) in include/kernel.mk which actually 
> prevents building of kernel packages from the SDK.  Long term it would 
> probably be better to have a way ship the .provides and create necessary 
> stamp, since the kernel binaries themselves are not actually needed by 
> the SDK; they exist only permit the build system to resolve dependencies 
> (that is I see no reason ship .ko files in order for the SDK to create 
> duplicate copies of packages already built elsewhere, nor am I aware of 
> other reasons for the SDK to use .ko files, except that it's the easiest 
> way to get the build machinery to acknowledge dependencies and deal with 
> all the various stamps and such).
I disagree with your proposed long term plan. I want to have fewer SDK
related special cases, not more. I've taken care of the kmod-* build
issue that you described in r48206 and r48207.

Thanks for looking into this,

- Felix
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] swconfig: support setting SWITCH_TYPE_LINK attributes

[Rafał Miłecki]

On 7 January 2016 at 07:53, Rafał Miłecki  wrote:
> On 30 December 2015 at 12:10, Rafał Miłecki  wrote:
>> Supported syntax is inspired by ethtool. Example usage:
>> swconfig dev switch0 port 2 set link "duplex half speed 100 autoneg off"
>
> Any comments to this usage/syntax? It doesn't look too nice (this long
> quoted string as a value), but swconfig is strongly focused on simple
> values.

One more RFC... anyone?

-- 
Rafał
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] Has buildbot died? lost its schedule?

[Hannu Nyman]

Buildbot has not initiated any new builds since Friday.
All buildslaves sit idle waiting for new orders.

http://buildbot.openwrt.org:8010/buildslaves
http://buildbot.openwrt.org:8010/builders

It looks like the buildbot has somehow lost its triggering schedule.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] base-files: For sysfixtime use hwclock if RTC available

[Daniel Dickinson]

Hmmm...actually this may be a case of an old non-POSIX conformant shell 
I once had to work in.


Anyway any modern POSIX-compliant shell doesn't have this issue.

Regards,

Daniel
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] base-files: For sysfixtime use hwclock if RTC available

[Daniel Dickinson]

Hi,

On 10/01/16 06:42 AM, bittorf wireless )) Bastian Bittorf wrote:

+
+start() {
+   if [ -e /dev/rtc ]; then
+   hwclock -s


please use the short form [ -e /dev/rtc ] && ...



Per private mail I've learned this is the current codebase standard, so 
will follow that, but the reason I tend to prefer the if..then is that 
if..then has the correct semantics when using set -e (that is causes 
termination on error, but not under normal operation) whereas [ xx ] && 
yy is not set -e safe and simply adding || true results in error 
conditions not being detected, so it is actually doing the wrong thing 
if you use set -e (unless the initial condition being false is an error 
and not just normal operation).


Regards,

Daniel
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] base-files: For sysfixtime use hwclock if RTC available

[Daniel Dickinson]

Actually I must have been smoking something when I thought I saw that 
problem (and no I don't actually).  I think it must have been in 
combination with some other error that I misremembered.


I just checked both bash and ash (and the docs) and they 'do the right 
thing'.


Regards,

Daniel

On 11/01/16 03:19 AM, Daniel Dickinson wrote:

Hi,

On 10/01/16 06:42 AM, bittorf wireless )) Bastian Bittorf wrote:

+
+start() {
+if [ -e /dev/rtc ]; then
+hwclock -s


please use the short form [ -e /dev/rtc ] && ...



Per private mail I've learned this is the current codebase standard, so
will follow that, but the reason I tend to prefer the if..then is that
if..then has the correct semantics when using set -e (that is causes
termination on error, but not under normal operation) whereas [ xx ] &&
yy is not set -e safe and simply adding || true results in error
conditions not being detected, so it is actually doing the wrong thing
if you use set -e (unless the initial condition being false is an error
and not just normal operation).

Regards,

Daniel
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH] kernel: Update kernel 4.4 to 4.4.0

[Martin Blumenstingl]

This removes one patch which was applied upstream with commit
67b9bcd36906e12a15ffec19463afbbd6a41660e. All other patches were
refreshed.

Signed-off-by: Martin Blumenstingl 
---
 include/kernel-version.mk  |  4 +--
 ...spi-nor-disable-protection-for-Winbond-fl.patch | 35 --
 .../480-mtd-set-rootfs-to-be-root-dev.patch|  2 +-
 .../patches-4.4/662-use_fq_codel_by_default.patch  |  2 +-
 .../generic/patches-4.4/902-debloat_proc.patch |  2 +-
 5 files changed, 5 insertions(+), 40 deletions(-)
 delete mode 100644 
target/linux/generic/patches-4.4/141-Revert-mtd-spi-nor-disable-protection-for-Winbond-fl.patch

diff --git a/include/kernel-version.mk b/include/kernel-version.mk
index 97dc592..26b9643 100644
--- a/include/kernel-version.mk
+++ b/include/kernel-version.mk
@@ -5,12 +5,12 @@ LINUX_RELEASE?=1
 LINUX_VERSION-3.18 = .23
 LINUX_VERSION-4.1 = .13
 LINUX_VERSION-4.3 =
-LINUX_VERSION-4.4 = -rc7
+LINUX_VERSION-4.4 =
 
 LINUX_KERNEL_MD5SUM-3.18.23 = dc6d265ab38716be3676ac294b481ad8
 LINUX_KERNEL_MD5SUM-4.1.13 = af9dd5d8f71185a64a8eccface15fc00
 LINUX_KERNEL_MD5SUM-4.3 = 58b35794eee3b6d52ce7be39357801e7
-LINUX_KERNEL_MD5SUM-4.4-rc7 = 7f4b1d85736a180df73af45adde8937b
+LINUX_KERNEL_MD5SUM-4.4 = 9a78fa2eb6c68ca5a40ed5af08142599
 
 ifdef KERNEL_PATCHVER
   LINUX_VERSION:=$(KERNEL_PATCHVER)$(strip $(LINUX_VERSION-$(KERNEL_PATCHVER)))
diff --git 
a/target/linux/generic/patches-4.4/141-Revert-mtd-spi-nor-disable-protection-for-Winbond-fl.patch
 
b/target/linux/generic/patches-4.4/141-Revert-mtd-spi-nor-disable-protection-for-Winbond-fl.patch
deleted file mode 100644
index 10b43d5..000
--- 
a/target/linux/generic/patches-4.4/141-Revert-mtd-spi-nor-disable-protection-for-Winbond-fl.patch
+++ /dev/null
@@ -1,35 +0,0 @@
-From: Felix Fietkau 
-Date: Thu, 26 Nov 2015 17:03:46 +0100
-Subject: [PATCH] Revert "mtd: spi-nor: disable protection for Winbond flash at
- startup"
-
-This reverts commit c6fc2171b249e73745c497b578b417a2946f1b2f.
-
-This commit is breaking read access on at least s25fl064k, but also
-possibly other Spansion flash chips.
-
-Any mtd read seems to succeed, but simply returns a zero-filled buffer.
-
-Signed-off-by: Felix Fietkau 

-
 a/drivers/mtd/spi-nor/spi-nor.c
-+++ b/drivers/mtd/spi-nor/spi-nor.c
-@@ -1194,14 +1194,13 @@ int spi_nor_scan(struct spi_nor *nor, co
-   mutex_init(>lock);
- 
-   /*
--   * Atmel, SST, Intel/Numonyx, and others serial NOR tend to power up
--   * with the software protection bits set
-+   * Atmel, SST and Intel/Numonyx serial nor tend to power
-+   * up with the software protection bits set
-*/
- 
-   if (JEDEC_MFR(info) == SNOR_MFR_ATMEL ||
-   JEDEC_MFR(info) == SNOR_MFR_INTEL ||
--  JEDEC_MFR(info) == SNOR_MFR_SST ||
--  JEDEC_MFR(info) == SNOR_MFR_WINBOND) {
-+  JEDEC_MFR(info) == SNOR_MFR_SST) {
-   write_enable(nor);
-   write_sr(nor, 0);
-   }
diff --git 
a/target/linux/generic/patches-4.4/480-mtd-set-rootfs-to-be-root-dev.patch 
b/target/linux/generic/patches-4.4/480-mtd-set-rootfs-to-be-root-dev.patch
index b565b52..d20bd8d 100644
--- a/target/linux/generic/patches-4.4/480-mtd-set-rootfs-to-be-root-dev.patch
+++ b/target/linux/generic/patches-4.4/480-mtd-set-rootfs-to-be-root-dev.patch
@@ -8,7 +8,7 @@
  
  #include 
  #include 
-@@ -473,6 +474,15 @@ int add_mtd_device(struct mtd_info *mtd)
+@@ -464,6 +465,15 @@ int add_mtd_device(struct mtd_info *mtd)
   of this try_ nonsense, and no bitching about it
   either. :) */
__module_get(THIS_MODULE);
diff --git a/target/linux/generic/patches-4.4/662-use_fq_codel_by_default.patch 
b/target/linux/generic/patches-4.4/662-use_fq_codel_by_default.patch
index 4ba20be..d3aeb92 100644
--- a/target/linux/generic/patches-4.4/662-use_fq_codel_by_default.patch
+++ b/target/linux/generic/patches-4.4/662-use_fq_codel_by_default.patch
@@ -42,7 +42,7 @@
  struct Qdisc_class_common {
 --- a/net/sched/sch_generic.c
 +++ b/net/sched/sch_generic.c
-@@ -726,7 +726,7 @@ static void attach_one_default_qdisc(str
+@@ -728,7 +728,7 @@ static void attach_one_default_qdisc(str
 void *_unused)
  {
struct Qdisc *qdisc;
diff --git a/target/linux/generic/patches-4.4/902-debloat_proc.patch 
b/target/linux/generic/patches-4.4/902-debloat_proc.patch
index 9f77858..6568836 100644
--- a/target/linux/generic/patches-4.4/902-debloat_proc.patch
+++ b/target/linux/generic/patches-4.4/902-debloat_proc.patch
@@ -134,7 +134,7 @@
 --- a/mm/vmstat.c
 +++ b/mm/vmstat.c
 @@ -1553,10 +1553,12 @@ static int __init setup_vmstat(void)
-   vmstat_wq = alloc_workqueue("vmstat", WQ_FREEZABLE|WQ_MEM_RECLAIM, 0);
+   cpu_notifier_register_done();
  #endif
  #ifdef CONFIG_PROC_FS
 -  proc_create("buddyinfo", S_IRUGO, NULL, _file_operations);
-- 
2.7.0

Re: [OpenWrt-Devel] [PATCH] base-files: For sysfixtime use hwclock if RTC available

[Daniel Dickinson]

I did one other test I hadn't thought of originally:

#!/bin/sh

set -e

/bin/false && /bin/false

echo "not killed"

displays "not killed", so there still the issue that unlike if..then 
with set -e, && fails to exit on error condition (for the purposes of 
set -e it's like there is an implicit || /bin/true (really the exit 
status just gets ignored for an AND-OR list in POSIX terms)).


Regards,

Daniel

On 11/01/16 03:30 AM, Daniel Curran-Dickinson wrote:

Actually I must have been smoking something when I thought I saw that
problem (and no I don't actually).  I think it must have been in
combination with some other error that I misremembered.

I just check both bash and ash (and the docs) and they 'do the right
thing'.

Regards,

Daniel

On 11/01/16 03:19 AM, Daniel Dickinson wrote:

Hi,

On 10/01/16 06:42 AM, bittorf wireless )) Bastian Bittorf wrote:

+
+start() {
+if [ -e /dev/rtc ]; then
+hwclock -s


please use the short form [ -e /dev/rtc ] && ...



Per private mail I've learned this is the current codebase standard, so
will follow that, but the reason I tend to prefer the if..then is that
if..then has the correct semantics when using set -e (that is causes
termination on error, but not under normal operation) whereas [ xx ] &&
yy is not set -e safe and simply adding || true results in error
conditions not being detected, so it is actually doing the wrong thing
if you use set -e (unless the initial condition being false is an error
and not just normal operation).

Regards,

Daniel
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH 1/1] [ar71xx] Use full 128MB flash on Netgear WNDR4300 and WNDR3700v4

[Chris Marchesi]

Change MTD on WNDR4300 and WNDR3700v4 to fully utilize the 128MB flash.

Credit to @Tuochenlyu on GitHub. Original patch here:
https://github.com/openwrt-mirror/openwrt/commit/1dbb652ea0594c284710ace5e479c1ac7fdd1cbb

Formally submitting this patch so that it is available upstream.

---
 target/linux/ar71xx/image/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/target/linux/ar71xx/image/Makefile 
b/target/linux/ar71xx/image/Makefile
index 4336697..fdb7ffc 100644
--- a/target/linux/ar71xx/image/Makefile
+++ b/target/linux/ar71xx/image/Makefile
@@ -1007,7 +1007,7 @@ 
wnr2200_mtdlayout=mtdparts=spi0.0:256k(u-boot)ro,64k(u-boot-env)ro,7808k(firmwar
 
wnr2000v3_mtdlayout=mtdparts=spi0.0:256k(u-boot)ro,64k(u-boot-env)ro,3712k(firmware),64k(art)ro
 
wnr2000v4_mtdlayout=mtdparts=spi0.0:192k(u-boot)ro,64k(u-boot-env)ro,3776k(firmware),64k(art)ro
 
r6100_mtdlayout=mtdparts=ar934x-nfc:128k(u-boot)ro,256k(caldata),256k(caldata-backup),512k(config),512k(pot),2048k(kernel),122240k(ubi),25600k@0x1a(firmware),2048k(language),3072k(traffic_meter)
-wndr4300_mtdlayout=mtdparts=ar934x-nfc:256k(u-boot)ro,256k(u-boot-env)ro,256k(caldata),512k(pot),2048k(language),512k(config),3072k(traffic_meter),2048k(kernel),23552k(ubi),25600k@0x6c(firmware),256k(caldata_backup),-(reserved)
+wndr4300_mtdlayout=mtdparts=ar934x-nfc:256k(u-boot)ro,256k(u-boot-env)ro,256k(caldata),512k(pot),2048k(language),512k(config),3072k(traffic_meter),2048k(kernel),120832k(ubi),122880k@0x6c(firmware),256k(caldata_backup),-(reserved)
 
zcn1523h_mtdlayout=mtdparts=spi0.0:256k(u-boot)ro,64k(u-boot-env)ro,6208k(rootfs),1472k(kernel),64k(configure)ro,64k(mfg)ro,64k(art)ro,7680k@0x5(firmware)
 
mynet_n600_mtdlayout=mtdparts=spi0.0:256k(u-boot)ro,64k(u-boot-env)ro,64k(devdata)ro,64k(devconf)ro,15872k(firmware),64k(radiocfg)ro
 
mynet_rext_mtdlayout=mtdparts=spi0.0:256k(u-boot)ro,7808k(firmware),64k(nvram)ro,64k(ART)ro
--
2.5.0
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH 0/1] [ar71xx] Use full 128MB flash on Netgear WNDR4300 and WNDR3700v4

[Chris Marchesi]

This patch expands the MTD layout on the Netgear WNDR4300 and WNDR3700v4 to
allow use of the full 128MB flash.

I previously mentioned this patch here:
https://lists.openwrt.org/pipermail/openwrt-devel/2016-January/038507.html

The original patch can be found here:
https://github.com/openwrt-mirror/openwrt/commit/1dbb652ea0594c284710ace5e479c1ac7fdd1cbb
and has been mentioned on the forums and what not in the WNDR3700 thread:
https://forum.openwrt.org/viewtopic.php?pid=258054#p258054, which is where
I actually found it.

I'd like to see it upstream because I don't necessarily want to be using a
custom build forever. ;) I've had this running on my device without issue.

One thing - I'm admittedly new to OpenWRT and while I grasp the concept of the
MTD layout, I'd appreciate another set of eyes to make sure that everything
looks good. Namely I'm wondering if the flash is actually undercut a bit as
the original author has listed 122880k for the firmware, possibly leaving 1MB
as reserved at the end, taking the rest into account.

Otherwise if there is anything else needed to get this merged let me know.

--Chris

Signed-off-by: Chris Marchesi 

Chris Marchesi (1):
  Use full 128MB flash on WNDR4300 and WNDR3700v4 (credit to @Tuochenlyu
on GitHub)

 target/linux/ar71xx/image/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--
2.5.0
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH 1/1] [ar71xx] Use full 128MB flash on Netgear WNDR4300 and WNDR3700v4

[Chris Marchesi]

Change MTD on WNDR4300 and WNDR3700v4 to fully utilize the 128MB flash.

Credit to @Tuochenlyu on GitHub.

Formally submitting this patch so that it is available upstream.

Signed-off-by: Chris Marchesi 

---
 target/linux/ar71xx/image/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/target/linux/ar71xx/image/Makefile 
b/target/linux/ar71xx/image/Makefile
index 4336697..fdb7ffc 100644
--- a/target/linux/ar71xx/image/Makefile
+++ b/target/linux/ar71xx/image/Makefile
@@ -1007,7 +1007,7 @@ 
wnr2200_mtdlayout=mtdparts=spi0.0:256k(u-boot)ro,64k(u-boot-env)ro,7808k(firmwar
 
wnr2000v3_mtdlayout=mtdparts=spi0.0:256k(u-boot)ro,64k(u-boot-env)ro,3712k(firmware),64k(art)ro
 
wnr2000v4_mtdlayout=mtdparts=spi0.0:192k(u-boot)ro,64k(u-boot-env)ro,3776k(firmware),64k(art)ro
 
r6100_mtdlayout=mtdparts=ar934x-nfc:128k(u-boot)ro,256k(caldata),256k(caldata-backup),512k(config),512k(pot),2048k(kernel),122240k(ubi),25600k@0x1a(firmware),2048k(language),3072k(traffic_meter)
-wndr4300_mtdlayout=mtdparts=ar934x-nfc:256k(u-boot)ro,256k(u-boot-env)ro,256k(caldata),512k(pot),2048k(language),512k(config),3072k(traffic_meter),2048k(kernel),23552k(ubi),25600k@0x6c(firmware),256k(caldata_backup),-(reserved)
+wndr4300_mtdlayout=mtdparts=ar934x-nfc:256k(u-boot)ro,256k(u-boot-env)ro,256k(caldata),512k(pot),2048k(language),512k(config),3072k(traffic_meter),2048k(kernel),120832k(ubi),122880k@0x6c(firmware),256k(caldata_backup),-(reserved)
 
zcn1523h_mtdlayout=mtdparts=spi0.0:256k(u-boot)ro,64k(u-boot-env)ro,6208k(rootfs),1472k(kernel),64k(configure)ro,64k(mfg)ro,64k(art)ro,7680k@0x5(firmware)
 
mynet_n600_mtdlayout=mtdparts=spi0.0:256k(u-boot)ro,64k(u-boot-env)ro,64k(devdata)ro,64k(devconf)ro,15872k(firmware),64k(radiocfg)ro
 
mynet_rext_mtdlayout=mtdparts=spi0.0:256k(u-boot)ro,7808k(firmware),64k(nvram)ro,64k(ART)ro
--
2.5.0
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Plans for CC 15.05.1 or DD 16.xx release?

[alzhao]

Great job!

May I know if the compile target for GL-AR150, GL-AR300, GL-Domino has been
backported to 15.05.1? They were submitted to trunk after CC1505. Hope they
have been back ported.


On Mon, Jan 11, 2016 at 8:12 PM, John Crispin  wrote:

>
>
> On 11/01/2016 12:56, Hannu Nyman wrote:
> > On 11.1.2016 13:40, John Crispin wrote:
> >> 15.05.1 is almost ready built. i had to do a refresh build to get
> >> felix's fixes from last night included. base builds finished last night
> >> and i started the SDK builder this morning which normally takes 2-3
> >> days. with a bit of luck 15.05.1 is ready early next week.
> >>
> >> I hope that we can do a DD in early spring, there are already plans for
> >> this but nothing definite yet. i have march as a rough date in mind to
> >> start working on it but take that with a large grain of salt please. we
> >> had already decided to do a release based on v4.4 a while back as it
> >> will be a LTS kernel.
> >>
> >> John
> >
> > Sounds great!
> >
> > (I guess that this 15.05.1 build effort also explains why the trunk
> > snapshots at the buildbot farm seem to be paused.)
>
> nope, different server. no idea whats up with the build farm.
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
>
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] scripts/metadata: Allow to select which profiles to build

[Daniel Dickinson]

On 11/01/16 04:05 PM, Felix Fietkau wrote:

On 2016-01-11 20:27, Eric Schultz wrote:

Felix,

Would it be unreasonable to have overridable defaults like suggested in
metadata.pl? Convention over configuration and all that.

I don't understand what you're asking. Could you elaborate?


To be honest I think you were supporting my effort, but I'm also not 
clear on quite what you were trying to say.


Regards,

Daniel
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH 1/1] [ar71xx] Use full 128MB flash on Netgear WNDR4300 and WNDR3700v4

[Chris Marchesi]

Oh crap - heh, forgot the no links part.

Will re-submit without links on the patch.


On Mon, Jan 11, 2016 at 9:33 PM, Chris Marchesi 
wrote:

> Change MTD on WNDR4300 and WNDR3700v4 to fully utilize the 128MB flash.
>
> Credit to @Tuochenlyu on GitHub. Original patch here:
>
> https://github.com/openwrt-mirror/openwrt/commit/1dbb652ea0594c284710ace5e479c1ac7fdd1cbb
>
> Formally submitting this patch so that it is available upstream.
>
> ---
>  target/linux/ar71xx/image/Makefile | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/target/linux/ar71xx/image/Makefile
> b/target/linux/ar71xx/image/Makefile
> index 4336697..fdb7ffc 100644
> --- a/target/linux/ar71xx/image/Makefile
> +++ b/target/linux/ar71xx/image/Makefile
> @@ -1007,7 +1007,7 @@
> wnr2200_mtdlayout=mtdparts=spi0.0:256k(u-boot)ro,64k(u-boot-env)ro,7808k(firmwar
>
>  
> wnr2000v3_mtdlayout=mtdparts=spi0.0:256k(u-boot)ro,64k(u-boot-env)ro,3712k(firmware),64k(art)ro
>
>  
> wnr2000v4_mtdlayout=mtdparts=spi0.0:192k(u-boot)ro,64k(u-boot-env)ro,3776k(firmware),64k(art)ro
>
>  
> r6100_mtdlayout=mtdparts=ar934x-nfc:128k(u-boot)ro,256k(caldata),256k(caldata-backup),512k(config),512k(pot),2048k(kernel),122240k(ubi),25600k@0x1a
> (firmware),2048k(language),3072k(traffic_meter)
>
> -wndr4300_mtdlayout=mtdparts=ar934x-nfc:256k(u-boot)ro,256k(u-boot-env)ro,256k(caldata),512k(pot),2048k(language),512k(config),3072k(traffic_meter),2048k(kernel),23552k(ubi),25600k@0x6c
> (firmware),256k(caldata_backup),-(reserved)
>
> +wndr4300_mtdlayout=mtdparts=ar934x-nfc:256k(u-boot)ro,256k(u-boot-env)ro,256k(caldata),512k(pot),2048k(language),512k(config),3072k(traffic_meter),2048k(kernel),120832k(ubi),122880k@0x6c
> (firmware),256k(caldata_backup),-(reserved)
>
>  
> zcn1523h_mtdlayout=mtdparts=spi0.0:256k(u-boot)ro,64k(u-boot-env)ro,6208k(rootfs),1472k(kernel),64k(configure)ro,64k(mfg)ro,64k(art)ro,7680k@0x5
> (firmware)
>
>  
> mynet_n600_mtdlayout=mtdparts=spi0.0:256k(u-boot)ro,64k(u-boot-env)ro,64k(devdata)ro,64k(devconf)ro,15872k(firmware),64k(radiocfg)ro
>
>  
> mynet_rext_mtdlayout=mtdparts=spi0.0:256k(u-boot)ro,7808k(firmware),64k(nvram)ro,64k(ART)ro
> --
> 2.5.0
>
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] WNDR3700v4 WAN LED not properly displaying netif state

[Chris Marchesi]

Anyone got any ideas on this one? Would just like to check to make sure I'm
not doing anything wrong or forgot to include a module before I go digging
further.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH 1/1] [ar71xx] Use full 128MB flash on Netgear WNDR4300 and WNDR3700v4

[Chris Marchesi]

Change MTD on WNDR4300 and WNDR3700v4 to fully utilize the 128MB flash.

Credit to @Tuochenlyu on GitHub.

Formally submitting this patch so that it is available upstream.

---
 target/linux/ar71xx/image/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/target/linux/ar71xx/image/Makefile 
b/target/linux/ar71xx/image/Makefile
index 4336697..fdb7ffc 100644
--- a/target/linux/ar71xx/image/Makefile
+++ b/target/linux/ar71xx/image/Makefile
@@ -1007,7 +1007,7 @@ 
wnr2200_mtdlayout=mtdparts=spi0.0:256k(u-boot)ro,64k(u-boot-env)ro,7808k(firmwar
 
wnr2000v3_mtdlayout=mtdparts=spi0.0:256k(u-boot)ro,64k(u-boot-env)ro,3712k(firmware),64k(art)ro
 
wnr2000v4_mtdlayout=mtdparts=spi0.0:192k(u-boot)ro,64k(u-boot-env)ro,3776k(firmware),64k(art)ro
 
r6100_mtdlayout=mtdparts=ar934x-nfc:128k(u-boot)ro,256k(caldata),256k(caldata-backup),512k(config),512k(pot),2048k(kernel),122240k(ubi),25600k@0x1a(firmware),2048k(language),3072k(traffic_meter)
-wndr4300_mtdlayout=mtdparts=ar934x-nfc:256k(u-boot)ro,256k(u-boot-env)ro,256k(caldata),512k(pot),2048k(language),512k(config),3072k(traffic_meter),2048k(kernel),23552k(ubi),25600k@0x6c(firmware),256k(caldata_backup),-(reserved)
+wndr4300_mtdlayout=mtdparts=ar934x-nfc:256k(u-boot)ro,256k(u-boot-env)ro,256k(caldata),512k(pot),2048k(language),512k(config),3072k(traffic_meter),2048k(kernel),120832k(ubi),122880k@0x6c(firmware),256k(caldata_backup),-(reserved)
 
zcn1523h_mtdlayout=mtdparts=spi0.0:256k(u-boot)ro,64k(u-boot-env)ro,6208k(rootfs),1472k(kernel),64k(configure)ro,64k(mfg)ro,64k(art)ro,7680k@0x5(firmware)
 
mynet_n600_mtdlayout=mtdparts=spi0.0:256k(u-boot)ro,64k(u-boot-env)ro,64k(devdata)ro,64k(devconf)ro,15872k(firmware),64k(radiocfg)ro
 
mynet_rext_mtdlayout=mtdparts=spi0.0:256k(u-boot)ro,7808k(firmware),64k(nvram)ro,64k(ART)ro
--
2.5.0
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH 1/1] [ar71xx] Use full 128MB flash on Netgear WNDR4300 and WNDR3700v4

[Chris Marchesi]

And one more time because I forgot the signoff.

Can you tell this is my first time doing an email PR? ;)


On Mon, Jan 11, 2016 at 9:42 PM, Chris Marchesi 
wrote:

> Change MTD on WNDR4300 and WNDR3700v4 to fully utilize the 128MB flash.
>
> Credit to @Tuochenlyu on GitHub.
>
> Formally submitting this patch so that it is available upstream.
>
> ---
>  target/linux/ar71xx/image/Makefile | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/target/linux/ar71xx/image/Makefile
> b/target/linux/ar71xx/image/Makefile
> index 4336697..fdb7ffc 100644
> --- a/target/linux/ar71xx/image/Makefile
> +++ b/target/linux/ar71xx/image/Makefile
> @@ -1007,7 +1007,7 @@
> wnr2200_mtdlayout=mtdparts=spi0.0:256k(u-boot)ro,64k(u-boot-env)ro,7808k(firmwar
>
>  
> wnr2000v3_mtdlayout=mtdparts=spi0.0:256k(u-boot)ro,64k(u-boot-env)ro,3712k(firmware),64k(art)ro
>
>  
> wnr2000v4_mtdlayout=mtdparts=spi0.0:192k(u-boot)ro,64k(u-boot-env)ro,3776k(firmware),64k(art)ro
>
>  
> r6100_mtdlayout=mtdparts=ar934x-nfc:128k(u-boot)ro,256k(caldata),256k(caldata-backup),512k(config),512k(pot),2048k(kernel),122240k(ubi),25600k@0x1a
> (firmware),2048k(language),3072k(traffic_meter)
>
> -wndr4300_mtdlayout=mtdparts=ar934x-nfc:256k(u-boot)ro,256k(u-boot-env)ro,256k(caldata),512k(pot),2048k(language),512k(config),3072k(traffic_meter),2048k(kernel),23552k(ubi),25600k@0x6c
> (firmware),256k(caldata_backup),-(reserved)
>
> +wndr4300_mtdlayout=mtdparts=ar934x-nfc:256k(u-boot)ro,256k(u-boot-env)ro,256k(caldata),512k(pot),2048k(language),512k(config),3072k(traffic_meter),2048k(kernel),120832k(ubi),122880k@0x6c
> (firmware),256k(caldata_backup),-(reserved)
>
>  
> zcn1523h_mtdlayout=mtdparts=spi0.0:256k(u-boot)ro,64k(u-boot-env)ro,6208k(rootfs),1472k(kernel),64k(configure)ro,64k(mfg)ro,64k(art)ro,7680k@0x5
> (firmware)
>
>  
> mynet_n600_mtdlayout=mtdparts=spi0.0:256k(u-boot)ro,64k(u-boot-env)ro,64k(devdata)ro,64k(devconf)ro,15872k(firmware),64k(radiocfg)ro
>
>  
> mynet_rext_mtdlayout=mtdparts=spi0.0:256k(u-boot)ro,7808k(firmware),64k(nvram)ro,64k(ART)ro
> --
> 2.5.0
>
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Plans for CC 15.05.1 or DD 16.xx release?

[alzhao]

Thanks. These patches are not back ported. Can this be done? If not
possible, that is OK. But if this can be back ported to CC15.05.1, that
would be very helpful.

including these patches.

ar71xx: add GL-AR150 support V3
ar71xx: add GL-AR300 support V3
ar71xx: add GL-Domino Pi support V3


On Tue, Jan 12, 2016 at 1:38 PM, Rafał Miłecki  wrote:

> On 12 January 2016 at 03:00, alzhao  wrote:
> > May I know if the compile target for GL-AR150, GL-AR300, GL-Domino has
> been
> > backported to 15.05.1? They were submitted to trunk after CC1505. Hope
> they
> > have been back ported.
>
> OpenWrt is open source with public repo:
> https://git.openwrt.org/?p=15.05/openwrt.git;a=summary
>
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] Improving ALL and ALL_KMODS (was Re: [PATCH] scripts/metadata: Allow to select which profiles to build)

[Daniel Dickinson]

Hi Felix,

On 11/01/16 03:28 PM, Felix Fietkau wrote:
> This is close to what I had in mind in my earlier response. Yes, it's
> ugly, but it's a lot less ugly than taking your approach without dealing
> with the issues that I pointed out.

Since a bit of ugliness for improved user experience seems to be 
acceptable, how do you feel about the following proposal to deal with 
current brokenness of ALL and ALL_KMODS (specifically that once there is 
an existing .config that selecting/deselecting those options no longer 
does anything; that is they only work when starting with no .config):


Make ALL a configuration option created by metadata.pl that does select 
 for all packages (except kmods), and
ALL_KMODS a configuration option create by metadata.pl that does select 
 for all kmods and is default y if ALL.


This generated config could go under tmp and be sourced by 
Config-build.in in the current location of ALL and ALL_KMODS.


Even though it's kind of ugly, since you dislike the similar issues with 
profile selection as menu enough to accept some ugliness, I'm wondering 
if you could accept some ugliness to make ALL and ALL_KMODS work better 
too (as I'm not sure you'd even realized there was in issue before).


Regards,

Daniel
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH 1/2] target/sdk: Do not allow SDK to reconfigure already built packages

[Daniel Dickinson]

On correction on the comments in the patch:  The install target is 
actually not applicable because it only applies to packages selected as 
y vs. m and refers to install into an actual image.  Packages which are 
m can only be recorded as built from a compile section, and marking 
packages from the compile section is non-trivial due to number of way in 
which compile sections come into being (i.e. there is no single 
convenient place to alter the compile target).


Regards,

Daniel

On 11/01/16 05:21 AM, open...@lists.openwrt.org wrote:

From: Daniel Dickinson 

If packages have already been built by the base system we don't want
a different version in another repo (e.g. built by SDK) because this
could cause conflicts with packaes that depend on it.  Therefore for
packages built by the base system, prevent the SDK from reconfiguring
the build options.

The approach taken is the one which least perturbs the build system
while still being reliable, of the ones considered.  Other approachs
involved modifying package-ipkg.mk and packages.mk in order to
override the compile or install targets, however there are rather a
lot of 'moving parts' to the compile target, and the number of fragile
changes required is quite high.  In addition, simply looking for .built
stamps is unreliable because packages which were once built due to a
previous configuration, but which are out-of-date and/or no longer
desired, would get recorded as built unless you remove the .built
stamp when doing package/compile, however that would result in every
package attempting to do a rebuild, even with no changes.

In any event the change to subdir.mk is required because of the
fact that the package name we need is the 'source' package name,
which corresponds to the last part of the subdirectory path in
which the package resides.

Signed-off-by: Daniel Dickinson 
---
  Makefile|  5 +++--
  include/package.mk  | 12 +++-
  include/subdir.mk   |  4 ++--
  include/toplevel.mk |  2 +-
  package/Makefile|  8 
  target/sdk/Makefile |  2 ++
  6 files changed, 27 insertions(+), 6 deletions(-)

diff --git a/Makefile b/Makefile
index a12e3ea..91c4779 100644
--- a/Makefile
+++ b/Makefile
@@ -41,8 +41,9 @@ else
  $(toolchain/stamp-install): $(tools/stamp-install)
  $(target/stamp-compile): $(toolchain/stamp-install) $(tools/stamp-install) 
$(BUILD_DIR)/.prepared
  $(package/stamp-compile): $(target/stamp-compile) $(package/stamp-cleanup)
-$(package/stamp-install): $(package/stamp-compile)
-$(target/stamp-install): $(package/stamp-compile) $(package/stamp-install)
+$(package/stamp-markforsdk): $(package/stamp-compile)
+$(package/stamp-install): $(package/stamp-compile) $(package/stamp-markforsdk)
+$(target/stamp-install): $(package/stamp-compile) $(package/stamp-markforsdk) 
$(package/stamp-install)

  printdb:
@true
diff --git a/include/package.mk b/include/package.mk
index 1dfbd68..0fd3455 100644
--- a/include/package.mk
+++ b/include/package.mk
@@ -7,7 +7,7 @@

  __package_mk:=1

-all: $(if $(DUMP),dumpinfo,compile)
+all: $(if $(DUMP),dumpinfo,compile markforsdk)

  PKG_BUILD_DIR ?= $(BUILD_DIR)/$(PKG_NAME)$(if $(PKG_VERSION),-$(PKG_VERSION))
  PKG_INSTALL_DIR ?= $(PKG_BUILD_DIR)/ipkg-install
@@ -66,6 +66,11 @@ STAMP_INSTALLED:=$(STAGING_DIR)/stamp/.$(PKG_DIR_NAME)$(if 
$(BUILD_VARIANT),.$(B
  STAGING_FILES_LIST:=$(PKG_DIR_NAME)$(if 
$(BUILD_VARIANT),.$(BUILD_VARIANT),).list

  define CleanStaging
+   $(if $(PKG_NAME), \
+   rm -f $(STAGING_DIR)/pkgstamp-current/$(PKG_NAME)
+   ,\
+   rm -rf $(STAGING_DIR)/pkgstamp-current \
+   )
rm -f $(STAMP_INSTALLED)
@-(\
cd "$(STAGING_DIR)"; \
@@ -214,6 +219,10 @@ define Build/DefaultTargets
rm -rf $(TMP_DIR)/stage-$(PKG_DIR_NAME)
touch $$@

+   markforsdk:
+   mkdir -p $(STAGING_DIR)/pkgstamp-current
+   touch $(STAGING_DIR)/pkgstamp-current/$(SRC_PKG_NAME)
+
ifdef Build/InstallDev
  compile: $(STAMP_INSTALLED)
endif
@@ -298,6 +307,7 @@ dumpinfo:
  download:
  prepare:
  configure:
+markforsdk:
  compile: prepare-package-install
  install: compile

diff --git a/include/subdir.mk b/include/subdir.mk
index 8dc9a78..380e602 100644
--- a/include/subdir.mk
+++ b/include/subdir.mk
@@ -9,7 +9,7 @@ ifeq ($(MAKECMDGOALS),prereq)
SUBTARGETS:=prereq
PREREQ_ONLY:=1
  else
-  SUBTARGETS:=clean download prepare compile install update refresh prereq 
dist distcheck configure
+  SUBTARGETS:=clean download prepare compile markforsdk install update refresh 
prereq dist distcheck configure
  endif

  subtarget-default = $(filter-out ., \
@@ -43,7 +43,7 @@ define subdir
$(call warn_eval,$(1)/$(bd),t,T,$(1)/$(bd)/$(target): $(if 
$(QUILT),,$($(1)/$(bd)/$(target)) $(call $(1)//$(target),$(1)/$(bd
$(if $(BUILD_LOG),@mkdir -p $(BUILD_LOG_DIR)/$(1)/$(bd))
  $(foreach variant,$(if 

Re: [OpenWrt-Devel] [PATCH 1/2] target/sdk: Do not allow SDK to reconfigure already built packages

[Daniel Dickinson]

On correction on the comments in the patch:  The install target is 
actually not applicable because it only applies to packages selected as 
y vs. m and refers to install into an actual image.  Packages which are 
m can only be recorded as built from a compile section, and marking 
packages from the compile section is non-trivial due to number of way in 
which compile sections come into being (i.e. there is no single 
convenient place to alter the compile target).


Regards,

Daniel

On 11/01/16 05:21 AM, open...@lists.openwrt.org wrote:

From: Daniel Dickinson 

If packages have already been built by the base system we don't want
a different version in another repo (e.g. built by SDK) because this
could cause conflicts with packaes that depend on it.  Therefore for
packages built by the base system, prevent the SDK from reconfiguring
the build options.

The approach taken is the one which least perturbs the build system
while still being reliable, of the ones considered.  Other approachs
involved modifying package-ipkg.mk and packages.mk in order to
override the compile or install targets, however there are rather a
lot of 'moving parts' to the compile target, and the number of fragile
changes required is quite high.  In addition, simply looking for .built
stamps is unreliable because packages which were once built due to a
previous configuration, but which are out-of-date and/or no longer
desired, would get recorded as built unless you remove the .built
stamp when doing package/compile, however that would result in every
package attempting to do a rebuild, even with no changes.

In any event the change to subdir.mk is required because of the
fact that the package name we need is the 'source' package name,
which corresponds to the last part of the subdirectory path in
which the package resides.

Signed-off-by: Daniel Dickinson 
---
  Makefile|  5 +++--
  include/package.mk  | 12 +++-
  include/subdir.mk   |  4 ++--
  include/toplevel.mk |  2 +-
  package/Makefile|  8 
  target/sdk/Makefile |  2 ++
  6 files changed, 27 insertions(+), 6 deletions(-)

diff --git a/Makefile b/Makefile
index a12e3ea..91c4779 100644
--- a/Makefile
+++ b/Makefile
@@ -41,8 +41,9 @@ else
  $(toolchain/stamp-install): $(tools/stamp-install)
  $(target/stamp-compile): $(toolchain/stamp-install) $(tools/stamp-install) 
$(BUILD_DIR)/.prepared
  $(package/stamp-compile): $(target/stamp-compile) $(package/stamp-cleanup)
-$(package/stamp-install): $(package/stamp-compile)
-$(target/stamp-install): $(package/stamp-compile) $(package/stamp-install)
+$(package/stamp-markforsdk): $(package/stamp-compile)
+$(package/stamp-install): $(package/stamp-compile) $(package/stamp-markforsdk)
+$(target/stamp-install): $(package/stamp-compile) $(package/stamp-markforsdk) 
$(package/stamp-install)

  printdb:
@true
diff --git a/include/package.mk b/include/package.mk
index 1dfbd68..0fd3455 100644
--- a/include/package.mk
+++ b/include/package.mk
@@ -7,7 +7,7 @@

  __package_mk:=1

-all: $(if $(DUMP),dumpinfo,compile)
+all: $(if $(DUMP),dumpinfo,compile markforsdk)

  PKG_BUILD_DIR ?= $(BUILD_DIR)/$(PKG_NAME)$(if $(PKG_VERSION),-$(PKG_VERSION))
  PKG_INSTALL_DIR ?= $(PKG_BUILD_DIR)/ipkg-install
@@ -66,6 +66,11 @@ STAMP_INSTALLED:=$(STAGING_DIR)/stamp/.$(PKG_DIR_NAME)$(if 
$(BUILD_VARIANT),.$(B
  STAGING_FILES_LIST:=$(PKG_DIR_NAME)$(if 
$(BUILD_VARIANT),.$(BUILD_VARIANT),).list

  define CleanStaging
+   $(if $(PKG_NAME), \
+   rm -f $(STAGING_DIR)/pkgstamp-current/$(PKG_NAME)
+   ,\
+   rm -rf $(STAGING_DIR)/pkgstamp-current \
+   )
rm -f $(STAMP_INSTALLED)
@-(\
cd "$(STAGING_DIR)"; \
@@ -214,6 +219,10 @@ define Build/DefaultTargets
rm -rf $(TMP_DIR)/stage-$(PKG_DIR_NAME)
touch $$@

+   markforsdk:
+   mkdir -p $(STAGING_DIR)/pkgstamp-current
+   touch $(STAGING_DIR)/pkgstamp-current/$(SRC_PKG_NAME)
+
ifdef Build/InstallDev
  compile: $(STAMP_INSTALLED)
endif
@@ -298,6 +307,7 @@ dumpinfo:
  download:
  prepare:
  configure:
+markforsdk:
  compile: prepare-package-install
  install: compile

diff --git a/include/subdir.mk b/include/subdir.mk
index 8dc9a78..380e602 100644
--- a/include/subdir.mk
+++ b/include/subdir.mk
@@ -9,7 +9,7 @@ ifeq ($(MAKECMDGOALS),prereq)
SUBTARGETS:=prereq
PREREQ_ONLY:=1
  else
-  SUBTARGETS:=clean download prepare compile install update refresh prereq 
dist distcheck configure
+  SUBTARGETS:=clean download prepare compile markforsdk install update refresh 
prereq dist distcheck configure
  endif

  subtarget-default = $(filter-out ., \
@@ -43,7 +43,7 @@ define subdir
$(call warn_eval,$(1)/$(bd),t,T,$(1)/$(bd)/$(target): $(if 
$(QUILT),,$($(1)/$(bd)/$(target)) $(call $(1)//$(target),$(1)/$(bd
$(if $(BUILD_LOG),@mkdir -p $(BUILD_LOG_DIR)/$(1)/$(bd))
  $(foreach variant,$(if 

Re: [OpenWrt-Devel] Plans for CC 15.05.1 or DD 16.xx release?

[Rafał Miłecki]

On 12 January 2016 at 03:00, alzhao  wrote:
> May I know if the compile target for GL-AR150, GL-AR300, GL-Domino has been
> backported to 15.05.1? They were submitted to trunk after CC1505. Hope they
> have been back ported.

OpenWrt is open source with public repo:
https://git.openwrt.org/?p=15.05/openwrt.git;a=summary
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] Fwd: [OpenWrt] #21573: hostapd: Full Dynamic VLAN support - vlan_bridge name list

[Vincent Fortier]

(Re-submitting as I needed to subscribe first... )

Thnx for the info.  I presume I should then submit my request for proposal
within this mailing list?  If so here is a bit more details surrounding my
use case:

It all started with this really well made documentation that I wished to
impleted (dynamic vlan over wifi):
https://wiki.openwrt.org/doc/howto/wireless.security.8021x

The issue I have is that we must provide a brige name suffix for this to
work.  I was hoping that instead it could be possible to provide a list of
bridge names instead.
Option could be either using a different parameter or something else?
1- if there is a single parameter to vlan_bridge use it as a suffix
or
2- if there are many parameter use the list of bridge names
This could also be implemented differently or using a new parameter, what
ever fits best (if any).

The underlying issue is that otherwise renaming all bridge to br-vlanX
totally removes the clarity of the various naming of each interfaces and
moves the configuration even farther from out of the box.

In my case I have 4 vlans whereas I would pass 3 of them as follow (if
feature ever added):
option vlan_bridge 'br-lan' 'br-media' 'br-guest'

To put more context to it here is an extract of the documentation:
...First, we must name our interfaces in /etc/config/network based on their
VLAN such as vlan1 and vlan3. This causes OpenWRT to name the bridges it
creates br-vlan1 and br-vlan3. Second, we set the vlan_bridge option in
/etc/config/wireless to "br-vlan" and the vlan_naming option to "0" what
this does is tell hostapd to create bridges using the br-vlanY naming
convention (where Y is the VLAN number)

I'm sure there are more to it which may block such a request but I tought
it was worth asking.

Thnx in advance!

- vin


Le lun. 11 janv. 2016 à 07:06, OpenWrt  a
écrit :

> #21573: hostapd: Full Dynamic VLAN support - vlan_bridge name list
> ---+
>   Reporter:  th0ma7|  Owner:  developers
>   Type:  defect| Status:  closed
>   Priority:  normal|  Milestone:
>  Component:  packages  |Version:  Chaos Calmer 15.05
> Resolution:  fixed |   Keywords:
> ---+
> Changes (by jow):
>
>  * status:  new => closed
>  * resolution:   => fixed
>
>
> Comment:
>
>  This is not valid uci:
>
>  `option 'vlan_bridge' 'br-lan' 'br-media' 'br-guest'`
>
>  Also, I see no indication that vanilla hostapd.conf allows multiple vlan
>  bridges either and finally this ticket is a feature request and not a bug.
>
>  Please send a *clear* and *detailed* proposal to the development list
>  outlining your wanted change.
>  Explain how the resulting hostapd.conf must be generated and how an
>  example (uci) configuration would look like.
>
>  Alternatively send your proposal in the form of a patch. Please do not
>  open a ticket unless there is an actual bug or regression.
>
> --
> Ticket URL: 
> OpenWrt 
> Opensource Wireless Router Technology
>
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] scripts/metadata: Allow to select which profiles to build

[Daniel Dickinson]

Actually I thought of a solution, but it starts to get ugly.  A choice 
submemenu with non-duplicate (i.e. TARGET_SINGLE_...) symbols that also 
select TARGET_SINGLE, AND have all the normal TARGET_... depend on 
!(TARGET_SYMBOL && !TARGET_SINGLE_..profile).


That would probably work, but it's rather ugly IMO.

Regards,

Daniel

On 11/01/16 08:35 AM, Felix Fietkau wrote:

On 2016-01-11 06:16, open...@daniel.thecshore.com wrote:

From: Daniel Dickinson 

Certain platforms have large numbers of possible images, and it can be
desirable to build neither all images nor only a single image,
therefore this patch makes selecting target profiles a menu instead of a
single choice, which allows the user to build a specific subset of all
possible images for a target.

Signed-off-by: Daniel Dickinson 
---
  scripts/metadata.pl | 32 +---
  1 file changed, 29 insertions(+), 3 deletions(-)

diff --git a/scripts/metadata.pl b/scripts/metadata.pl
index 48b1b7a..4487d26 100755
--- a/scripts/metadata.pl
+++ b/scripts/metadata.pl
@@ -275,8 +275,7 @@ EOF
  print <{conf}_$profile->{id}
bool "$profile->{name}"
depends on TARGET_$target->{conf}
+EOF
+
+   if (not (($profile->{id} eq 'Default') || 
($profile->{id} eq 'Minimal'))) {
+   print <{conf}_Default
+   default n if TARGET_$target->{conf}_Minimal
+EOF

I like the idea of allowing the user to select multiple profiles.
However, there also needs to be a clean and simple way to select a
single profile without going through the list and deselecting everything.
Also, I don't like hardcoded profile names in metadata.pl, a better
approach would be to have a flag as part of a profile that indicates
that it's not a device profile.

- Felix


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH v3] ar8327: add IGMP Snooping support

[Álvaro Fernández Rojas]

This add support for IGMP Snooping on atheros switches (disabled by default),
which avoids flooding the network with multicast data.

Tested on TL-WDR4300: disabling IGMP Snooping results in multicast flooding
on each specific port, enabling it back again prevents each port from
receiving all multicast packets.

Partially based on: http://patchwork.ozlabs.org/patch/418122/

Signed-off-by: Álvaro Fernández Rojas 
---
 v3: introduce changes suggested by Felix Fietkau
 - expose less knobs
 - merge igmp_mld, fast_join and fast_leave (according to the datasheet,
 igmp_mld enables both IGMP and MLD)
 - simplify code structure
 v2: introduce changes suggested by Linus Lüssing
 - switch to disabled by default
 - add MLD snooping support
 - allow enabling/disabling IGMP v3, join and leave
 - add functions for controlling settings on all ports
 At least igmp_snooping, igmp_fast_join and igmp_fast_leave must be enabled
 in order to get IGMP working. MLD Snooping and IGMP v3 are optional.

 .../linux/generic/files/drivers/net/phy/ar8327.c   | 167 +
 .../linux/generic/files/drivers/net/phy/ar8327.h   |  65 
 2 files changed, 232 insertions(+)

diff --git a/target/linux/generic/files/drivers/net/phy/ar8327.c 
b/target/linux/generic/files/drivers/net/phy/ar8327.c
index 90ee411..02fd2e7 100644
--- a/target/linux/generic/files/drivers/net/phy/ar8327.c
+++ b/target/linux/generic/files/drivers/net/phy/ar8327.c
@@ -783,6 +783,45 @@ ar8327_atu_flush_port(struct ar8xxx_priv *priv, int port)
return ret;
 }
 
+static int
+ar8327_get_port_igmp(struct ar8xxx_priv *priv, int port)
+{
+   u32 fwd_ctrl, frame_ack;
+
+   fwd_ctrl = (BIT(port) << AR8327_FWD_CTRL1_IGMP_S);
+   frame_ack = ((AR8327_FRAME_ACK_CTRL_IGMP_MLD |
+ AR8327_FRAME_ACK_CTRL_IGMP_JOIN |
+ AR8327_FRAME_ACK_CTRL_IGMP_LEAVE) <<
+AR8327_FRAME_ACK_CTRL_S(port));
+
+   return (ar8xxx_read(priv, AR8327_REG_FWD_CTRL1) &
+   fwd_ctrl) == fwd_ctrl &&
+   (ar8xxx_read(priv, AR8327_REG_FRAME_ACK_CTRL(port)) &
+   frame_ack) == frame_ack;
+}
+
+static void
+ar8327_set_port_igmp(struct ar8xxx_priv *priv, int port, int enable)
+{
+   int reg_frame_ack = AR8327_REG_FRAME_ACK_CTRL(port);
+   u32 val_frame_ack = (AR8327_FRAME_ACK_CTRL_IGMP_MLD |
+ AR8327_FRAME_ACK_CTRL_IGMP_JOIN |
+ AR8327_FRAME_ACK_CTRL_IGMP_LEAVE) <<
+AR8327_FRAME_ACK_CTRL_S(port);
+
+   if (enable) {
+   ar8xxx_rmw(priv, AR8327_REG_FWD_CTRL1,
+  BIT(port) << AR8327_FWD_CTRL1_MC_FLOOD_S,
+  BIT(port) << AR8327_FWD_CTRL1_IGMP_S);
+   ar8xxx_reg_set(priv, reg_frame_ack, val_frame_ack);
+   } else {
+   ar8xxx_rmw(priv, AR8327_REG_FWD_CTRL1,
+  BIT(port) << AR8327_FWD_CTRL1_IGMP_S,
+  BIT(port) << AR8327_FWD_CTRL1_MC_FLOOD_S);
+   ar8xxx_reg_clear(priv, reg_frame_ack, val_frame_ack);
+   }
+}
+
 static void
 ar8327_vtu_op(struct ar8xxx_priv *priv, u32 op, u32 val)
 {
@@ -1084,6 +1123,110 @@ ar8327_sw_hw_apply(struct switch_dev *dev)
return 0;
 }
 
+int
+ar8327_sw_get_port_igmp_snooping(struct switch_dev *dev,
+const struct switch_attr *attr,
+struct switch_val *val)
+{
+   struct ar8xxx_priv *priv = swdev_to_ar8xxx(dev);
+   int port = val->port_vlan;
+
+   if (port >= dev->ports)
+   return -EINVAL;
+
+   mutex_lock(>reg_mutex);
+   val->value.i = ar8327_get_port_igmp(priv, port);
+   mutex_unlock(>reg_mutex);
+
+   return 0;
+}
+
+int
+ar8327_sw_set_port_igmp_snooping(struct switch_dev *dev,
+const struct switch_attr *attr,
+struct switch_val *val)
+{
+   struct ar8xxx_priv *priv = swdev_to_ar8xxx(dev);
+   int port = val->port_vlan;
+
+   if (port >= dev->ports)
+   return -EINVAL;
+
+   mutex_lock(>reg_mutex);
+   ar8327_set_port_igmp(priv, port, val->value.i);
+   mutex_unlock(>reg_mutex);
+
+   return 0;
+}
+
+int
+ar8327_sw_get_igmp_snooping(struct switch_dev *dev,
+   const struct switch_attr *attr,
+   struct switch_val *val)
+{
+   int port;
+
+   for (port = 0; port < dev->ports; port++) {
+   val->port_vlan = port;
+   if (ar8327_sw_get_port_igmp_snooping(dev, attr, val) ||
+   !val->value.i)
+   break;
+   }
+
+   return 0;
+}
+
+int
+ar8327_sw_set_igmp_snooping(struct switch_dev *dev,
+   const struct switch_attr *attr,
+   struct switch_val *val)
+{
+   int port;
+
+   for (port = 0; port < dev->ports; 

Re: [OpenWrt-Devel] [PATCH] scripts/metadata: Allow to select which profiles to build

[Felix Fietkau]

On 2016-01-11 20:27, Eric Schultz wrote:
> Felix,
> 
> Would it be unreasonable to have overridable defaults like suggested in
> metadata.pl? Convention over configuration and all that.
I don't understand what you're asking. Could you elaborate?

- Felix
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] scripts/metadata: Allow to select which profiles to build

[Felix Fietkau]

On 2016-01-11 21:11, Daniel Dickinson wrote:
> On 11/01/16 08:35 AM, Felix Fietkau wrote:
>> I like the idea of allowing the user to select multiple profiles.
>> However, there also needs to be a clean and simple way to select a
>> single profile without going through the list and deselecting everything.
> 
> Actually, while it would need to be extended to other platforms, on 
> ar71xx that is exactly what Minimal does.  In fact, assuming your on the 
> first run of menuconfig (i.e. the only time defaults work, due to the 
> way KConfig works; this is also a problem for ALL_KMODS and ALL (that 
> de-selecting all kmods and for de-selecting all packages), if you 
> deselect Default, all the items selected will become unselected.
I think that will not be clear to users at all, and it means you can't
conveniently switch from a config with all profiles to one with just one
profile enabled without re-making your changes.

> It is not possible with KConfig to have an *existing* .config and have 
> an option that causes deselection of selected items, that does not also 
> force deselection without the option to override (e.g. depends on 
> !MINIMAL won't work because it would force the item to off without 
> option to override).
> 
> If you have some clever way to avoid this problem, I'd love to hear it, 
> because I don't know how to do it in KConfig.  I don't see how to allow 
> an *overridable* deselection of *all* items, unless perhaps one could 
> introduce a new submenu that is a choice section (I'd have to test to 
> see if that would actually work, or if duplicate symbols would be a 
> problem).
You could emit some extra code to have an option to select a single
profile, which will deselect all profiles except for one that is
selected by a choice value.

- Felix
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] scripts/metadata: Allow to select which profiles to build

[Felix Fietkau]

On 2016-01-11 21:23, Daniel Dickinson wrote:
> Actually I thought of a solution, but it starts to get ugly.  A choice 
> submemenu with non-duplicate (i.e. TARGET_SINGLE_...) symbols that also 
> select TARGET_SINGLE, AND have all the normal TARGET_... depend on 
> !(TARGET_SYMBOL && !TARGET_SINGLE_..profile).
> 
> That would probably work, but it's rather ugly IMO.
This is close to what I had in mind in my earlier response. Yes, it's
ugly, but it's a lot less ugly than taking your approach without dealing
with the issues that I pointed out.

- Felix
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Plans for CC 15.05.1 or DD 16.xx release?

[Hannu Nyman]

On 11.1.2016 13:40, John Crispin wrote:

15.05.1 is almost ready built. i had to do a refresh build to get
felix's fixes from last night included. base builds finished last night
and i started the SDK builder this morning which normally takes 2-3
days. with a bit of luck 15.05.1 is ready early next week.

I hope that we can do a DD in early spring, there are already plans for
this but nothing definite yet. i have march as a rough date in mind to
start working on it but take that with a large grain of salt please. we
had already decided to do a release based on v4.4 a while back as it
will be a LTS kernel.

John


Sounds great!

(I guess that this 15.05.1 build effort also explains why the trunk snapshots 
at the buildbot farm seem to be paused.)

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] lantiq: Change the xbar register range to match the datasheet

[Martin Blumenstingl]

On Mon, Jan 11, 2016 at 2:59 PM, John Crispin  wrote:
> 0x1F40-0x1F400FFF means that its size is 0x1000. i think you having
> a off-by-one thinko ...
...and I think you are right!
Sorry for the noise, please drop this patch.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [BB 14.07] samba: Security update (3 CVEs)

[jow]

The samba package has been rebuilt and was uploaded to the Barrier
Breaker 14.07 repository due to multiple security issues.


VERSION

3.6.25-1 => 3.6.25-1.1


CHANGELOG

[Mon, 11 Jan 2016 11:57:36 + e483830]

This is a patch for CVE-2015-5252, CVE-2015-5296 and CVE-2015-5299. A
patchset for these vulnerabilities was published on 16th December 2015.


CHANGES

 package/network/services/samba36/Makefile |2 +-
 .../patches/010-patch-cve-2015-5252.patch |   43 +++
 .../patches/011-patch-cve-2015-5296.patch |  112 +
 .../patches/012-patch-cve-2015-5299.patch |   97 ++
 4 files changed, 253 insertions(+), 1 deletion(-)


REFERENCES

 * http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-5252
 * http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-5296
 * http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-5299
 * 
http://git.openwrt.org/?p=14.07/openwrt.git;a=commit;h=e48383023629a38ae42b81dc8c1d9f8c43102868
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH 3/3] lantiq: ltq-deu: Remove the "DEU test manager"

[Martin Blumenstingl]

Remove the "DEU test manager" code which has not been used for more than
two years (as the kernel module is not installed anymore since
aa65888e08ec7279cfecc24c5bfe71cf9a016b91).
This fixes compilation on kernel 4.3 (which removes
aead_request_set_assoc) and newer.

Signed-off-by: Martin Blumenstingl 
---
 package/kernel/lantiq/ltq-deu/src/Makefile |2 -
 .../kernel/lantiq/ltq-deu/src/ltq_deu_testmgr.c| 3961 
 2 files changed, 3963 deletions(-)
 delete mode 100644 package/kernel/lantiq/ltq-deu/src/ltq_deu_testmgr.c

diff --git a/package/kernel/lantiq/ltq-deu/src/Makefile 
b/package/kernel/lantiq/ltq-deu/src/Makefile
index f6cb9c9..555f0f6 100644
--- a/package/kernel/lantiq/ltq-deu/src/Makefile
+++ b/package/kernel/lantiq/ltq-deu/src/Makefile
@@ -22,5 +22,3 @@ ifeq ($(BUILD_VARIANT),vr9)
   ltq_deu_vr9-objs = ifxmips_deu.o ifxmips_deu_vr9.o ifxmips_des.o 
ifxmips_aes.o ifxmips_arc4.o \
ifxmips_sha1.o ifxmips_md5.o ifxmips_sha1_hmac.o 
ifxmips_md5_hmac.o
 endif
-
-obj-m += ltq_deu_testmgr.o
diff --git a/package/kernel/lantiq/ltq-deu/src/ltq_deu_testmgr.c 
b/package/kernel/lantiq/ltq-deu/src/ltq_deu_testmgr.c
deleted file mode 100644
index 054cac3..000
--- a/package/kernel/lantiq/ltq-deu/src/ltq_deu_testmgr.c
+++ /dev/null
@@ -1,3961 +0,0 @@
-/*
- * Algorithm testing framework and tests.
- *
- * Copyright (c) 2002 James Morris 
- * Copyright (c) 2002 Jean-Francois Dive 
- * Copyright (c) 2007 Nokia Siemens Networks
- * Copyright (c) 2008 Herbert Xu 
- *
- * This program is free software; you can redistribute it and/or modify it
- * under the terms of the GNU General Public License as published by the Free
- * Software Foundation; either version 2 of the License, or (at your option)
- * any later version.
- *
- */
-
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-
-#include "internal.h"
-#include "ifxmips_testmgr.h"
-#include "ifxmips_tcrypt.h"
-#include "ifxmips_deu.h"
-
-/* changes for LQ ablkcipher speedtest */
-#include 
-#include 
-#include 
-
-/*
- * Need slab memory for testing (size in number of pages).
- */
-#define XBUFSIZE   8
-
-/*
- * Indexes into the xbuf to simulate cross-page access.
- */
-#define IDX1   32
-#define IDX2   32400
-#define IDX3   1
-#define IDX4   8193
-#define IDX5   2
-#define IDX6   17101
-#define IDX7   27333
-#define IDX8   3000
-
-/*
-* Used by test_cipher()
-*/
-#define ENCRYPT 1
-#define DECRYPT 0
-
-/*
- * Need slab memory for testing (size in number of pages).
- */
-#define TVMEMSIZE  4
-
-/*
-* Used by test_cipher_speed()
-*/
-#define ENCRYPT 1
-#define DECRYPT 0
-
-/*
- * Used by test_cipher_speed()
- */
-
-#ifndef INIT_COMPLETION
-#define INIT_COMPLETION(a) reinit_completion()
-#endif
-
-
-static unsigned int sec;
-
-static char *alg = NULL;
-static u32 type;
-static u32 mask;
-static int mode;
-static char *tvmem[TVMEMSIZE];
-
-static char *check[] = {
-   "des", "md5", "des3_ede", "rot13", "sha1", "sha224", "sha256",
-   "blowfish", "twofish", "serpent", "sha384", "sha512", "md4", "aes",
-   "cast6", "arc4", "michael_mic", "deflate", "crc32c", "tea", "xtea",
-   "khazad", "wp512", "wp384", "wp256", "tnepres", "xeta",  "fcrypt",
-   "camellia", "seed", "salsa20", "rmd128", "rmd160", "rmd256", "rmd320",
-   "lzo", "cts", "zlib", NULL
-};
-struct tcrypt_result {
-   struct completion completion;
-   int err;
-};
-
-struct aead_test_suite {
-   struct {
-   struct aead_testvec *vecs;
-   unsigned int count;
-   } enc, dec;
-};
-
-struct cipher_test_suite {
-   struct {
-   struct cipher_testvec *vecs;
-   unsigned int count;
-   } enc, dec;
-};
-
-struct comp_test_suite {
-   struct {
-   struct comp_testvec *vecs;
-   unsigned int count;
-   } comp, decomp;
-};
-
-struct pcomp_test_suite {
-   struct {
-   struct pcomp_testvec *vecs;
-   unsigned int count;
-   } comp, decomp;
-};
-
-struct hash_test_suite {
-   struct hash_testvec *vecs;
-   unsigned int count;
-};
-
-struct cprng_test_suite {
-   struct cprng_testvec *vecs;
-   unsigned int count;
-};
-
-struct alg_test_desc {
-   const char *alg;
-   int (*test)(const struct alg_test_desc *desc, const char *driver,
-   u32 type, u32 mask);
-   int fips_allowed;   /* set if alg is allowed in fips mode */
-
-   union {
-   struct aead_test_suite aead;
-   struct cipher_test_suite cipher;
-   struct comp_test_suite comp;
-   struct pcomp_test_suite pcomp;
-   struct hash_test_suite hash;
-   struct 

[OpenWrt-Devel] [PATCH] lantiq: Change the xbar register range to match the datasheet

[Martin Blumenstingl]

According to the datasheet says that the xbar register range is
0x1F40-0x1F400FFF. Thanks to John Crispin for looking it up.

Signed-off-by: Martin Blumenstingl 
---
 target/linux/lantiq/dts/vr9.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/target/linux/lantiq/dts/vr9.dtsi b/target/linux/lantiq/dts/vr9.dtsi
index df63ce7..927a54a 100644
--- a/target/linux/lantiq/dts/vr9.dtsi
+++ b/target/linux/lantiq/dts/vr9.dtsi
@@ -78,7 +78,7 @@
 
xbar0: xbar@40 {
compatible = "lantiq,xbar-xway";
-   reg = <0x40 0x1000>;
+   reg = <0x40 0xfff>;
};
};
 
-- 
2.7.0
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Plans for CC 15.05.1 or DD 16.xx release?

[John Crispin]

On 11/01/2016 12:28, Hannu Nyman wrote:
> Are there any plans for a CC 15.05.1 maintenance release? Or will DD
> 16.xx be the next one?
> 
> There have been so many fixes to 15.05 that personally I would like to
> see a maintenance release 15.05.1. There have been both security fixes,
> but also new/improved features that should be adopted more widely as
> early as possible. One good example is r46848 (the backport of r46491),
> that will ease any subsequent upgrade thanks to improved opkg behaviour
> after sysupgrade with settings preserved.
> 
> There have been some questions about 15.05.1 at the forum every now and
> then, so it would be great if devs would publish some roadmap about the
> plans.

15.05.1 is almost ready built. i had to do a refresh build to get
felix's fixes from last night included. base builds finished last night
and i started the SDK builder this morning which normally takes 2-3
days. with a bit of luck 15.05.1 is ready early next week.

I hope that we can do a DD in early spring, there are already plans for
this but nothing definite yet. i have march as a rough date in mind to
start working on it but take that with a large grain of salt please. we
had already decided to do a release based on v4.4 a while back as it
will be a LTS kernel.

John
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Plans for CC 15.05.1 or DD 16.xx release?

[John Crispin]

On 11/01/2016 12:56, Hannu Nyman wrote:
> On 11.1.2016 13:40, John Crispin wrote:
>> 15.05.1 is almost ready built. i had to do a refresh build to get
>> felix's fixes from last night included. base builds finished last night
>> and i started the SDK builder this morning which normally takes 2-3
>> days. with a bit of luck 15.05.1 is ready early next week.
>>
>> I hope that we can do a DD in early spring, there are already plans for
>> this but nothing definite yet. i have march as a rough date in mind to
>> start working on it but take that with a large grain of salt please. we
>> had already decided to do a release based on v4.4 a while back as it
>> will be a LTS kernel.
>>
>> John
> 
> Sounds great!
> 
> (I guess that this 15.05.1 build effort also explains why the trunk
> snapshots at the buildbot farm seem to be paused.)

nope, different server. no idea whats up with the build farm.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] Plans for CC 15.05.1 or DD 16.xx release?

[Hannu Nyman]

Are there any plans for a CC 15.05.1 maintenance release? Or will DD 16.xx be 
the next one?


There have been so many fixes to 15.05 that personally I would like to see a 
maintenance release 15.05.1. There have been both security fixes, but also 
new/improved features that should be adopted more widely as early as 
possible. One good example is r46848 (the backport of r46491), that will ease 
any subsequent upgrade thanks to improved opkg behaviour after sysupgrade 
with settings preserved.


There have been some questions about 15.05.1 at the forum every now and then, 
so it would be great if devs would publish some roadmap about the plans.

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] scripts/metadata: Allow to select which profiles to build

[Felix Fietkau]

On 2016-01-11 06:16, open...@daniel.thecshore.com wrote:
> From: Daniel Dickinson 
> 
> Certain platforms have large numbers of possible images, and it can be
> desirable to build neither all images nor only a single image,
> therefore this patch makes selecting target profiles a menu instead of a
> single choice, which allows the user to build a specific subset of all
> possible images for a target.
> 
> Signed-off-by: Daniel Dickinson 
> ---
>  scripts/metadata.pl | 32 +---
>  1 file changed, 29 insertions(+), 3 deletions(-)
> 
> diff --git a/scripts/metadata.pl b/scripts/metadata.pl
> index 48b1b7a..4487d26 100755
> --- a/scripts/metadata.pl
> +++ b/scripts/metadata.pl
> @@ -275,8 +275,7 @@ EOF
>  print <  endchoice
>  
> -choice
> - prompt "Target Profile"
> +menu "Target Profile"
>  
>  EOF
>  
> @@ -288,8 +287,35 @@ EOF
>  config TARGET_$target->{conf}_$profile->{id}
>   bool "$profile->{name}"
>   depends on TARGET_$target->{conf}
> +EOF
> +
> + if (not (($profile->{id} eq 'Default') || 
> ($profile->{id} eq 'Minimal'))) {
> + print < + default y if TARGET_$target->{conf}_Default
> + default n if TARGET_$target->{conf}_Minimal
> +EOF
I like the idea of allowing the user to select multiple profiles.
However, there also needs to be a clean and simple way to select a
single profile without going through the list and deselecting everything.
Also, I don't like hardcoded profile names in metadata.pl, a better
approach would be to have a flag as part of a profile that indicates
that it's not a device profile.

- Felix
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] lantiq: Initial linux 4.4 support (with SPI problems)

[Martin Blumenstingl]

Hello,

this series adds linux 4.4 support to the lantiq target.
It depends on the linux/generic 4.4.0 update because -rc8 contains a
build-fix for MIPS devices.

I have tested it on two (VRX200) devices:
- VGV7510KW22 (seems to work fine)
- TD-W8970 (the mtd_reads in mtd_split seem to only return 0x)

Here's the kernel log from the TD-W8970: https://paste.kde.org/pia7p73i9
I have debugged it and split_tplink_kernel gets 0x2 as offset and
0x7A as size (which looks correct). However, when mtd_read tries to
read the magic bytes it only gets 0x.

I'm happy for any suggestions what could be wrong here.


Regards,
Martin
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] lantiq: Change the xbar register range to match the datasheet

[John Crispin]

On 11/01/2016 14:51, Martin Blumenstingl wrote:
> According to the datasheet says that the xbar register range is
> 0x1F40-0x1F400FFF. Thanks to John Crispin for looking it up.
> 
> Signed-off-by: Martin Blumenstingl 
> ---
>  target/linux/lantiq/dts/vr9.dtsi | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/target/linux/lantiq/dts/vr9.dtsi 
> b/target/linux/lantiq/dts/vr9.dtsi
> index df63ce7..927a54a 100644
> --- a/target/linux/lantiq/dts/vr9.dtsi
> +++ b/target/linux/lantiq/dts/vr9.dtsi
> @@ -78,7 +78,7 @@
>  
>   xbar0: xbar@40 {
>   compatible = "lantiq,xbar-xway";
> - reg = <0x40 0x1000>;
> + reg = <0x40 0xfff>;

0x1F40-0x1F400FFF means that its size is 0x1000. i think you having
a off-by-one thinko ...
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH 2/3] lantiq: ltq-deu: Make the DEU driver compatible with linux 4.2 and newer

[Martin Blumenstingl]

Upstream linux 4.2 commit 84be456f883c4685680fba8e5154b5f72e92957e
"remove " requires us to include linux/scatterlist.h
instead. This also works with older kernels (at least 4.1, thanks to
Hauke Mehrtens for testing).

Signed-off-by: Martin Blumenstingl 
---
 package/kernel/lantiq/ltq-deu/src/ifxmips_deu_ar9.h| 2 +-
 package/kernel/lantiq/ltq-deu/src/ifxmips_deu_danube.h | 2 +-
 package/kernel/lantiq/ltq-deu/src/ifxmips_deu_dma.h| 2 +-
 package/kernel/lantiq/ltq-deu/src/ifxmips_deu_vr9.h| 2 +-
 package/kernel/lantiq/ltq-deu/src/ifxmips_sha1.c   | 2 +-
 package/kernel/lantiq/ltq-deu/src/ifxmips_sha1_hmac.c  | 2 +-
 6 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/package/kernel/lantiq/ltq-deu/src/ifxmips_deu_ar9.h 
b/package/kernel/lantiq/ltq-deu/src/ifxmips_deu_ar9.h
index 1d84da3..6941455 100644
--- a/package/kernel/lantiq/ltq-deu/src/ifxmips_deu_ar9.h
+++ b/package/kernel/lantiq/ltq-deu/src/ifxmips_deu_ar9.h
@@ -54,7 +54,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 #include 
 #include 
 #include "ifxmips_deu.h"
diff --git a/package/kernel/lantiq/ltq-deu/src/ifxmips_deu_danube.h 
b/package/kernel/lantiq/ltq-deu/src/ifxmips_deu_danube.h
index 62ad96d..25efa04 100644
--- a/package/kernel/lantiq/ltq-deu/src/ifxmips_deu_danube.h
+++ b/package/kernel/lantiq/ltq-deu/src/ifxmips_deu_danube.h
@@ -53,7 +53,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 #include 
 #include 
 #include "ifxmips_deu.h"
diff --git a/package/kernel/lantiq/ltq-deu/src/ifxmips_deu_dma.h 
b/package/kernel/lantiq/ltq-deu/src/ifxmips_deu_dma.h
index 5198a4a..fde7a90 100644
--- a/package/kernel/lantiq/ltq-deu/src/ifxmips_deu_dma.h
+++ b/package/kernel/lantiq/ltq-deu/src/ifxmips_deu_dma.h
@@ -35,7 +35,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 #include 
 #include 
 #include 
diff --git a/package/kernel/lantiq/ltq-deu/src/ifxmips_deu_vr9.h 
b/package/kernel/lantiq/ltq-deu/src/ifxmips_deu_vr9.h
index d2cfd11..fcbda40 100644
--- a/package/kernel/lantiq/ltq-deu/src/ifxmips_deu_vr9.h
+++ b/package/kernel/lantiq/ltq-deu/src/ifxmips_deu_vr9.h
@@ -54,7 +54,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 #include 
 #include 
 #include "ifxmips_deu.h"
diff --git a/package/kernel/lantiq/ltq-deu/src/ifxmips_sha1.c 
b/package/kernel/lantiq/ltq-deu/src/ifxmips_sha1.c
index a5f5f90..2492549 100644
--- a/package/kernel/lantiq/ltq-deu/src/ifxmips_sha1.c
+++ b/package/kernel/lantiq/ltq-deu/src/ifxmips_sha1.c
@@ -48,7 +48,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 #include 
 
 #if defined(CONFIG_DANUBE)
diff --git a/package/kernel/lantiq/ltq-deu/src/ifxmips_sha1_hmac.c 
b/package/kernel/lantiq/ltq-deu/src/ifxmips_sha1_hmac.c
index a5a6c39..a447c15 100644
--- a/package/kernel/lantiq/ltq-deu/src/ifxmips_sha1_hmac.c
+++ b/package/kernel/lantiq/ltq-deu/src/ifxmips_sha1_hmac.c
@@ -47,7 +47,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 #include 
 #include 
 
-- 
2.7.0
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [CC 15.05] samba: Security update (3 CVEs)

[jow]

The samba package has been rebuilt and was uploaded to the Chaos Calmer
15.05 repository due to multiple security issues.


VERSION

3.6.25-4 => 3.6.25-5


CHANGELOG

[Tue, 5 Jan 2016 11:01:00 + 98bacec]

This is a patch for CVE-2015-5252, CVE-2015-5296 and CVE-2015-5299. A
patchset for these vulnerabilities was published on 16th December 2015.


CHANGES

 package/network/services/samba36/Makefile |2 +-
 .../patches/010-patch-cve-2015-5252.patch |   43 +++
 .../patches/011-patch-cve-2015-5296.patch |  112 +
 .../patches/012-patch-cve-2015-5299.patch |   97 ++
 4 files changed, 253 insertions(+), 1 deletion(-)


REFERENCES

 * http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-5252
 * http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-5296
 * http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-5299
 * 
http://git.openwrt.org/?p=15.05/openwrt.git;a=commit;h=98bacec57cade6f2fc7b1c5813ffbf23f44af8dd
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] uci commit bumping amount of dentry active slab objects

[Rafał Miłecki]

I was looking at slabinfo and noticed something about uci. Executing
"uci commit" increases amount of "dentry" active objects.

# echo 2 > /proc/sys/vm/drop_caches

# egrep "dentry|kmalloc-64" /proc/slabinfo
dentry   559   2040136   301 : tunables  120   608 : sla
kmalloc-64  5357   9324 64   631 : tunables  120   608 : sla

# for N in `seq 1 1 1000`; do uci commit network; done

# egrep "dentry|kmalloc-64" /proc/slabinfo
dentry  3540   3540136   301 : tunables  120   608 : sla
kmalloc-64  6457   9324 64   631 : tunables  120   608 : sla

# for N in `seq 1 1 1000`; do uci commit network; done

# egrep "dentry|kmalloc-64" /proc/slabinfo
dentry  6570   6570136   301 : tunables  120   608 : sla
kmalloc-64  7587   9324 64   631 : tunables  120   608 : sla

This is not critical. As you know Linux kernel loves caching. When
amount of free RAM goes below ~2 MiB I can see kernel freeing dentry
objects and it doesn't OOM.

But I'm still wondering if everything is OK. Is this normal kernel
keeps increasing pool of dentry objects as the result of "uci commit"
command?

I expected "uci command" first to bump amount of active and total
dentry objects. Then when uci exits I expected amount of active
objects to go down. Kernel could reuse inactive objects during next
"uci commit" call. In such scenario amount of active objects would
vary, but amount of total object would be more-or-less stable.

Can we be missing some (f)close in UCI? I checked uci_file_commit and
it looks alright. Or is this just how the filesystem works? I'm using
3.18.21 (OpenWrt 15.05 branch) on device with serial flash (so JFFS2).

-- 
Rafał
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] uci commit bumping amount of dentry active slab objects

[Felix Fietkau]

On 2016-01-11 13:19, Felix Fietkau wrote:
> On 2016-01-11 12:57, Rafał Miłecki wrote:
>> I was looking at slabinfo and noticed something about uci. Executing
>> "uci commit" increases amount of "dentry" active objects.
>> 
>> # echo 2 > /proc/sys/vm/drop_caches
>> 
>> # egrep "dentry|kmalloc-64" /proc/slabinfo
>> dentry   559   2040136   301 : tunables  120   608 : 
>> sla
>> kmalloc-64  5357   9324 64   631 : tunables  120   608 : 
>> sla
>> 
>> # for N in `seq 1 1 1000`; do uci commit network; done
>> 
>> # egrep "dentry|kmalloc-64" /proc/slabinfo
>> dentry  3540   3540136   301 : tunables  120   608 : 
>> sla
>> kmalloc-64  6457   9324 64   631 : tunables  120   608 : 
>> sla
>> 
>> # for N in `seq 1 1 1000`; do uci commit network; done
>> 
>> # egrep "dentry|kmalloc-64" /proc/slabinfo
>> dentry  6570   6570136   301 : tunables  120   608 : 
>> sla
>> kmalloc-64  7587   9324 64   631 : tunables  120   608 : 
>> sla
>> 
>> This is not critical. As you know Linux kernel loves caching. When
>> amount of free RAM goes below ~2 MiB I can see kernel freeing dentry
>> objects and it doesn't OOM.
>> 
>> But I'm still wondering if everything is OK. Is this normal kernel
>> keeps increasing pool of dentry objects as the result of "uci commit"
>> command?
>> 
>> I expected "uci command" first to bump amount of active and total
>> dentry objects. Then when uci exits I expected amount of active
>> objects to go down. Kernel could reuse inactive objects during next
>> "uci commit" call. In such scenario amount of active objects would
>> vary, but amount of total object would be more-or-less stable.
>> 
>> Can we be missing some (f)close in UCI? I checked uci_file_commit and
>> it looks alright. Or is this just how the filesystem works? I'm using
>> 3.18.21 (OpenWrt 15.05 branch) on device with serial flash (so JFFS2).
> User space programs are not required to close all their file descriptor,
> such a close happens implicitly on exit.
> I did an strace on uci commit without any delta, and I believe the
> likely cause is cached negative dentries for temporary files.
> On commit it checks a temp file before bailing out due to the lack of a
> config delta.
Yep, that was it. Fixed in r48200

- Felix
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] base-files: For sysfixtime use hwclock if RTC available

[Lars Kruse]

Hi,

short summary for the impatient readers: the following text dives into the
subtile differences between errexit (set -e) and exit status in shell scripting


Am Mon, 11 Jan 2016 05:14:18 -0500
schrieb Daniel Dickinson :

> I did one other test I hadn't thought of originally:
> 
> #!/bin/sh
> 
> set -e
> 
> /bin/false && /bin/false
> 
> echo "not killed"
> 
> displays "not killed", so there still the issue that unlike if..then 
> with set -e, && fails to exit on error condition (for the purposes of 
> set -e it's like there is an implicit || /bin/true (really the exit 
> status just gets ignored for an AND-OR list in POSIX terms)).

The dash manpage describes "-e" (errexit) as follows:
 The exit status of a command is considered to be explicitly tested if the
 command is used to control an if, elif, while, or until; or if the command is
 the left hand operand of an ``&&'' or ``||'' operator.
The bash manual explains the same - just a bit more lengty. Busybox's ash works
in the same way, as far as I noticed.

Thus the manual implies that the following two lines behave identical with
regards to errexit:

  if [ -e /somefile ]; then action; fi
  [ -e /somefile ] && action

In fact they do. If the test fails then action is not executed.
If the test succeeds then the action is executed. The exit status of action
determines the overall exit status of this line and thus may trigger errexit.

The subtile difference between the above two lines is their exit status.
The "if" variation returns the exit status of "action" (test succeeds) or zero
(test fails).
The "&&" variation returns the exit status of the last executed command. Thus a
failed test returns a non-zero exit status. But due to the definition of
errexit, only the exit status of the last item in a compound statement
may trigger an errexit event.

Thus both statements on their own will behave in the same way regarding errexit
even if their exit status may differ.

But there is a final catch: if these statements are the last ones in any
while/for/if/case block, then their exit status determines the exit status
of the whole block. Thus the surrounding while/for/if/case block may cause an
errexit.

Look at these examples:

= example A =
 for a in foo bar; do
   [ -e "$a" ] && echo "$a"
 done

= example B =
 for a in foo bar; do
   if [ -e "$a" ]; then echo "$a"; fi
 done

In example (A) you will see a failure (followed by errexit) if the file "bar"
does not exist. The state of "foo" is not relevant. This is a bit surprising.
In example (B) there will never be an error. This is probably in line with the
expectation of most users.

Thus it is advisable to add a "true" statement at the end of a while/for/if/case
block if last statement is a "||" or "&&" compound. This additional
statement does not cover any errors. It just works around the subtile
differences between "exit code" and "errexit triggering" in this specific
situation.

Lars
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] lantiq: Change the xbar register range to match the datasheet

[John Crispin]

On 11/01/2016 15:15, Martin Blumenstingl wrote:
> On Mon, Jan 11, 2016 at 2:59 PM, John Crispin  wrote:
>> 0x1F40-0x1F400FFF means that its size is 0x1000. i think you having
>> a off-by-one thinko ...
> ...and I think you are right!
> Sorry for the noise, please drop this patch.
> 

heh, i had one of those last week that cost me 4 hours ;)
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] scripts/metadata: Allow to select which profiles to build

[Eric Schultz]

Felix,

Would it be unreasonable to have overridable defaults like suggested in
metadata.pl? Convention over configuration and all that.

Eric

On Mon, Jan 11, 2016 at 7:35 AM, Felix Fietkau  wrote:

> On 2016-01-11 06:16, open...@daniel.thecshore.com wrote:
> > From: Daniel Dickinson 
> >
> > Certain platforms have large numbers of possible images, and it can be
> > desirable to build neither all images nor only a single image,
> > therefore this patch makes selecting target profiles a menu instead of a
> > single choice, which allows the user to build a specific subset of all
> > possible images for a target.
> >
> > Signed-off-by: Daniel Dickinson 
> > ---
> >  scripts/metadata.pl | 32 +---
> >  1 file changed, 29 insertions(+), 3 deletions(-)
> >
> > diff --git a/scripts/metadata.pl b/scripts/metadata.pl
> > index 48b1b7a..4487d26 100755
> > --- a/scripts/metadata.pl
> > +++ b/scripts/metadata.pl
> > @@ -275,8 +275,7 @@ EOF
> >  print < >  endchoice
> >
> > -choice
> > - prompt "Target Profile"
> > +menu "Target Profile"
> >
> >  EOF
> >
> > @@ -288,8 +287,35 @@ EOF
> >  config TARGET_$target->{conf}_$profile->{id}
> >   bool "$profile->{name}"
> >   depends on TARGET_$target->{conf}
> > +EOF
> > +
> > + if (not (($profile->{id} eq 'Default') ||
> ($profile->{id} eq 'Minimal'))) {
> > + print < > + default y if TARGET_$target->{conf}_Default
> > + default n if TARGET_$target->{conf}_Minimal
> > +EOF
> I like the idea of allowing the user to select multiple profiles.
> However, there also needs to be a clean and simple way to select a
> single profile without going through the list and deselecting everything.
> Also, I don't like hardcoded profile names in metadata.pl, a better
> approach would be to have a flag as part of a profile that indicates
> that it's not a device profile.
>
> - Felix
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
>



-- 
Eric Schultz, Community Manager, prpl Foundation
http://www.prplfoundation.org
eschu...@prplfoundation.org
cell: 920-539-0404
skype: ericschultzwi
@EricPrpl
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] scripts/metadata: Allow to select which profiles to build

[Daniel Dickinson]

On 11/01/16 08:35 AM, Felix Fietkau wrote:

Signed-off-by: Daniel Dickinson 
---
  scripts/metadata.pl | 32 +---
  1 file changed, 29 insertions(+), 3 deletions(-)

diff --git a/scripts/metadata.pl b/scripts/metadata.pl
index 48b1b7a..4487d26 100755
--- a/scripts/metadata.pl
+++ b/scripts/metadata.pl
@@ -275,8 +275,7 @@ EOF
  print <{conf}_$profile->{id}
bool "$profile->{name}"
depends on TARGET_$target->{conf}
+EOF
+
+   if (not (($profile->{id} eq 'Default') || 
($profile->{id} eq 'Minimal'))) {
+   print <{conf}_Default
+   default n if TARGET_$target->{conf}_Minimal
+EOF

I like the idea of allowing the user to select multiple profiles.
However, there also needs to be a clean and simple way to select a
single profile without going through the list and deselecting everything.


Actually, while it would need to be extended to other platforms, on 
ar71xx that is exactly what Minimal does.  In fact, assuming your on the 
first run of menuconfig (i.e. the only time defaults work, due to the 
way KConfig works; this is also a problem for ALL_KMODS and ALL (that 
de-selecting all kmods and for de-selecting all packages), if you 
deselect Default, all the items selected will become unselected.


It is not possible with KConfig to have an *existing* .config and have 
an option that causes deselection of selected items, that does not also 
force deselection without the option to override (e.g. depends on 
!MINIMAL won't work because it would force the item to off without 
option to override).


If you have some clever way to avoid this problem, I'd love to hear it, 
because I don't know how to do it in KConfig.  I don't see how to allow 
an *overridable* deselection of *all* items, unless perhaps one could 
introduce a new submenu that is a choice section (I'd have to test to 
see if that would actually work, or if duplicate symbols would be a 
problem).


Regards,

Daniel


Also, I don't like hardcoded profile names in metadata.pl, a better
approach would be to have a flag as part of a profile that indicates
that it's not a device profile.

- Felix


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel