Re: [LEDE-DEV] LEDE-17.01 Final Release Notes available

2017-01-28 Thread Weedy
On 28 January 2017 at 15:56, Rich Brown  wrote:
> Hi Jaap,
>
>> On Jan 28, 2017, at 6:36 AM, Jaap Buurman  wrote:
>> Also about the following: "Improvements to the WiFi stack eliminating
>> bufferbloat on ath9k (and some ath10k) chipsets"
>>
>> Is this about the Airtime Fairness Patch? AFAIK this is only for ath9k
>> and not for ath10k? Or am I mixing things up here?
>
> I am not sure. I was hoping someone who has been following this more closely 
> would weigh in.

As far as I know the make-wifi-fast work was done in stages. Something like:
Phase 1: Reducing buffering all over the stack/drivers. Pretty sure
atk10k got some of this
Phase 2: Replace most/all txqueue stuff with fq_codel inside the
driver. I know Toke made patches for ath10k, I don't know if upstream
accepted them
Phase 3: Air time fairness stuff. Only for ath9k, and I don't know if
ath10k can ever get this since the chip firmware is basically a full
operating system and it does whatever it wants too.

NB: I'm just a user, not a dev. But I like WiFi things and try to keep informed.

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev


[LEDE-DEV] [PATCH] kmodloader: fix out-of-order module loading

2017-01-28 Thread Christian Lamparter via Lede-dev
The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---
Currently, kmodloader is trying to load all modules during
boot. This is because all the modules (and not just those
which start with a number) are set to probe.

Signed-off-by: Christian Lamparter 
---
The load_modprobe() seems to be necessary, since I've also hit
a hang with 4.9 caused by nf_nat_ipv6.ko. This is because it
calls request_module for nf_conntrack_ipv6. So the order in
the /etc/modprobe.d/ files is still important.

I have the following options enabled:

CONFIG_PACKAGE_kmod-ip6tables-extra=y
CONFIG_PACKAGE_kmod-ipt-conntrack-extra=y
CONFIG_PACKAGE_kmod-ipt-ipsec=y
CONFIG_PACKAGE_kmod-ipt-nat-extra=y
CONFIG_PACKAGE_kmod-ipt-nat6=y

I fixed this by adding nf_conntrack_ipv6 to NF_CONNTRACK6
in modules/netfilter.mk. No idea if this is also a problem
on 4.4 or not.
---
 kmodloader.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/kmodloader.c b/kmodloader.c
index 729027a..bf8c36c 100644
--- a/kmodloader.c
+++ b/kmodloader.c
@@ -933,10 +933,11 @@ static int main_loader(int argc, char **argv)
 
if (opts)
m->opts = strdup(opts);
-   m->state = PROBE;
-   if (basename(gl.gl_pathv[j])[0] - '0' <= 9)
-   load_modprobe();
 
+   if (basename(gl.gl_pathv[j])[0] - '0' <= 9) {
+   m->state = PROBE;
+   load_modprobe();
+   }
}
free(mod);
fclose(fp);
-- 
2.11.0


--- End Message ---
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev


Re: [LEDE-DEV] LEDE-17.01 Final Release Notes available

2017-01-28 Thread Rich Brown
Hi Jaap,

> On Jan 28, 2017, at 6:36 AM, Jaap Buurman  wrote:
> 
> Great job on the release notes! One minor thing that I think looks
> nicer would be the removal of "nothing specific" after "improved
> performance", since it adds no additional information. But that's just
> me.

Thanks for the kind words. I left "nothing specific" there as an attempt to 
lure people into writing something. :-) I would expect to remove that text for 
the final version.

Note to other readers: I have not been following all the LEDE enhancements 
carefully. Please do check the Release Notes to make sure that your hard work 
has been represented fairly. Check out: 
https://lede-project.org/playground/draft-release-notes

> Also about the following: "Improvements to the WiFi stack eliminating
> bufferbloat on ath9k (and some ath10k) chipsets"
> 
> Is this about the Airtime Fairness Patch? AFAIK this is only for ath9k
> and not for ath10k? Or am I mixing things up here?

I am not sure. I was hoping someone who has been following this more closely 
would weigh in.

> While're talking about 17.01 anyway when are the first RCs coming out btw? :)

jow just clarified the situation for the naming of directories and image files. 
In that note, he also said that just switched the buildbot to produce tagged 
rc1 builds, so I imagine they will come out soon.

> ___
> Lede-dev mailing list
> Lede-dev@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev


Re: [LEDE-DEV] Finding Release snapshots/URLs for the "Release"

2017-01-28 Thread Rich Brown
Hi Jo,

Thanks for all this information. I'll propagate it to the forum, since many 
people are asking.

> On Jan 28, 2017, at 9:35 AM, Jo-Philipp Wich  wrote:
> 
> Hi Rich,
> 
>> 1) When I got to downloads.lede-project.org, I see the following
>> directory structure: [...] I do NOT see any targets under the
>> /releases directory. Why?
> 
> I intentionally hid the "17.01-SNAPSHOTS" directory because it is not a
> fixed (as in non-moving) build, it merely reflects the build output of
> the current branch HEAD.
> 
>> 2) Why doesn't the /releases directory mirror the /snapshots
>> directory?
> 
> Because releases are structured slightly differently.

I understand now.

>> 3) I have discovered that the release images are available
>> /releases/17.01-SNAPSHOT/  Is this what we should document?
> 
> No, please do not document that particular directory, see below.

OK. I have a recommendation re: naming & directories. 

Perhaps we should create /releases/17.01.0-rc1/ now. Its sole contents (today) 
could be a README text file with text like this:

= /releases/17.01.0-rc1/README.txt =
2017-01-dd

There are no LEDE 17.01.0-rc1 build images at this time. 

However, we are building snapshots for testing in preparation for the 
17.01.0-rc1 build. 
Those snapshots are saved in the hidden /releases/17.01-SNAPSHOT/ directory.

Once we create the LEDE 17.01.0-rc1 build, this directory will contain its 
image files and packages.
=
 
Once the 17.01.0-rc1 files have been created, the README.txt file could be 
updated to say:

= /releases/17.01.0-rc1/README.txt =

2017-01-dd

The files in this directory are the LEDE 17.01.0-rc1 snapshots.
They are release candidates for the LEDE 17.01.0 build, and will never be 
updated.

However, we are building snapshots for testing in preparation for the 
17.01.0-rc2 build. 
Those snapshots are saved in the hidden directory /releases/17.01-SNAPSHOT/
=

>> 4) It's really confusing to talk about (and document) the release
>> candidates and the daily "trunk" builds. Currently, image file names
>> for stable build candidates contain the word "snapshot", while trunk
>> builds (in the /snapshots directory) do not:
> 
> Those images are not stable build candidates but merely release branch
> snapshots, thats why they contain the word "snapshot" and also why
> they're currently hidden from the toplevel directory.
> 
> I instructed the buildbot to produce tagged rc1 builds today, those will
> be true, fixed release candidate images which do not move.

How soon do you expect the /releases/17.01.0-rc1/ images to be available?

> Once built, those images will appear in /releases/17.01.0-rc1/ and
> remain unchanged. In addition to that, there will be a corresponding
> "v17.01.0-rc1" tag in the repository which can be used to reproduce this
> particular images.
> 
> The /releases/17.01.[0-9]* directories (once existing) which are not
> hidden are the ones that should be documented and referred to as fixed
> builds.
> 
>> 5) What is the naming scheme for the final 17.01 image URLs?
> 
> The RCs will be:
> 
> /releases/17.01.0-rc[0-9]*/targets/$target/$subtarget/lede-17.01.0-rc[0-9]*-r-XXX-$target-$subtarget-*.bin
> 
> The finals will be:
> 
> /releases/17.01.0/targets/$target/$subtarget/lede-17.01.0-r-XXX-$target-$subtarget-*.bin
> 
>> 6) When we release a new version (say, 17.06), what will those URLs
>> be?
> 
> The RCs will be:
> 
> /releases/17.06.0-rc[0-9]*/targets/$target/$subtarget/lede-17.06.0-rc[0-9]*-r-XXX-$target-$subtarget-*.bin
> 
> The finals will be:
> 
> /releases/17.06.0/targets/$target/$subtarget/lede-17.06.0-r-XXX-$target-$subtarget-*.bin

This is a good, and easily understood/described plan. Thanks!

Rich

>> We'll adjust the documentation to match the results of this
>> discussion. Thanks.
> 
> I appreciate your efforts on this, thank you :)
> 
> ~ Jo
> 
> ___
> Lede-dev mailing list
> Lede-dev@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev


Re: [LEDE-DEV] [PATCH] ar71xx: prepare jffs2 partition properly in factory.bin for BHR-4GRV2

2017-01-28 Thread Felix Fietkau
On 2017-01-28 17:08, Naoki FUKAUMI wrote:
> can someone handle this for 17.01?
Done.

- Felix


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev


Re: [LEDE-DEV] [PATCH] openvpn: add support for various new 2.4 configuration options

2017-01-28 Thread Felix Fietkau
On 2017-01-28 10:30, Magnus Kroken wrote:
> Hi
> 
> On 16.01.2017 22.56, Magnus Kroken wrote:
>> Updates to openvpn.init were included in early OpenVPN 2.4 patch
>> series, but got lost along the way and were never merged.
>>
>> Signed-off-by: Magnus Kroken 
>> ---
>>  .../network/services/openvpn/files/openvpn.init| 43 
>> ++
>>  1 file changed, 19 insertions(+), 24 deletions(-)
> 
> Is it possible to apply this to 17.01 branch as well? If not, 17.01 will 
> ship with OpenVPN 2.4.0, but several new options will be unavailable 
> when using UCI to configure OpenVPN.
Done.

- Felix


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev


Re: [LEDE-DEV] netifd: "bridge: disable IGMP snooping by default"

2017-01-28 Thread Felix Fietkau
On 2017-01-26 21:38, Linus Lüssing wrote:
> Hi Felix, thanks and I really appreciate your efforts to create a
> successful, stable and first LEDE release :). So if it's going to
> be disabled in that first LEDE release, that'd be fine by me.
> 
> Nevertheless, Jow or Felix, could you forward the tickets which
> seemed related to bridge multicast snooping to me? So I can check
> whether it should be disabled in Gluon, too. (we took some
> precautions with a robustness variable of 3 instead of 2 and way
> lower querier intervals in Gluon, but not sure what kind of issues
> were reported for LEDE)
Hi Linus,

here's a ticket that just confirms issues with the IGMP snooping patch:
https://bugs.lede-project.org/index.php?do=details_id=253#comment1477

Please follow up with the bug reporters there and let me know if you
need any help.

Thanks,

- Felix

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev


[LEDE-DEV] [PATCH] lantiq: fix unaligned access in xrx200_poll_rx()

2017-01-28 Thread Alexander Couzens
Signed-off-by: Alexander Couzens 
---
 .../lantiq/patches-4.4/0025-NET-MIPS-lantiq-adds-xrx200-net.patch | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git 
a/target/linux/lantiq/patches-4.4/0025-NET-MIPS-lantiq-adds-xrx200-net.patch 
b/target/linux/lantiq/patches-4.4/0025-NET-MIPS-lantiq-adds-xrx200-net.patch
index 4e60f30302..acaadba984 100644
--- a/target/linux/lantiq/patches-4.4/0025-NET-MIPS-lantiq-adds-xrx200-net.patch
+++ b/target/linux/lantiq/patches-4.4/0025-NET-MIPS-lantiq-adds-xrx200-net.patch
@@ -1190,8 +1190,8 @@ Subject: [PATCH 25/36] NET: MIPS: lantiq: adds xrx200-net
 +  if ((desc->ctl & (LTQ_DMA_OWN | LTQ_DMA_C)) == LTQ_DMA_C) {
 +#ifdef SW_ROUTING
 +  struct sk_buff *skb = ch->skb[ch->dma.desc];
-+  u32 *special_tag = (u32*)skb->data;
-+  int port = (special_tag[1] >> SPPID_SHIFT) & SPPID_MASK;
++  u8 *special_tag = (u8*)skb->data;
++  int port = (special_tag[7] >> SPPID_SHIFT) & SPPID_MASK;
 +  xrx200_hw_receive(ch, priv->hw->port_map[port]);
 +#else
 +  xrx200_hw_receive(ch, 0);
-- 
2.11.0


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev


[LEDE-DEV] [PATCH v4 3/3] ramips: add support for Buffalo WCR-1166DS

2017-01-28 Thread FUKAUMI Naoki
Buffalo WCR-1166DS is a small wireless router with

 - MT7628AN + MT7612E
 - 64MiB DDR2 SDRAM
 - 16MiB SPI flash
 - 2T2R 11ac/a/b/g/n Wi-Fi
 - 2x 10/100M ethernet switch
 - 8x programmable LED
 - 3x button
 - UART pad on PCB (J2: 3.3V, GND, TX, RX)

factory image can be installed via stock web UI.

due to the "dual image" function in the bootloader, the second half of
the SPI flash ("firmware2" partition) cannot be used as a part of the
file system.

Signed-off-by: FUKAUMI Naoki 
---
Changes in v4:
- rebase and resolve conflict

Changes in v3:
- added

 .../linux/ramips/base-files/etc/board.d/02_network |  15 +-
 target/linux/ramips/base-files/etc/diag.sh |  11 +-
 target/linux/ramips/base-files/lib/ramips.sh   |   3 +
 .../ramips/base-files/lib/upgrade/platform.sh  |   9 +-
 target/linux/ramips/dts/WCR-1166DS.dts | 172 +
 target/linux/ramips/image/Makefile |   3 +-
 target/linux/ramips/image/mt7628.mk|  16 ++
 target/linux/ramips/mt7628/config-4.4  |   1 +
 ...r-custom-trx-magic-for-Buffalo-WCR-1166DS.patch |  30 
 9 files changed, 245 insertions(+), 15 deletions(-)
 create mode 100644 target/linux/ramips/dts/WCR-1166DS.dts
 create mode 100644 
target/linux/ramips/patches-4.4/0400-mtd-mtdsplit-add-support-for-custom-trx-magic-for-Buffalo-WCR-1166DS.patch

diff --git a/target/linux/ramips/base-files/etc/board.d/02_network 
b/target/linux/ramips/base-files/etc/board.d/02_network
index b27954f..282624f 100755
--- a/target/linux/ramips/base-files/etc/board.d/02_network
+++ b/target/linux/ramips/base-files/etc/board.d/02_network
@@ -264,6 +264,10 @@ ramips_setup_interfaces()
ucidef_add_switch "switch0" \
"1:lan" "2:lan" "3:lan" "4:lan" "0:wan" "5@eth0"
;;
+   wcr-1166ds)
+   ucidef_add_switch "switch0" \
+   "3:lan" "4:wan" "6@eth0"
+   ;;
wcr-150gn)
ucidef_add_switch "switch0" \
"0:lan" "6t@eth0"
@@ -411,6 +415,12 @@ ramips_setup_macs()
lan_mac=$(cat /sys/class/net/eth0/address)
wan_mac=$(macaddr_add "$lan_mac" 5)
;;
+   wcr-1166ds|\
+   wsr-1166)
+   local index="$(find_mtd_index "board_data")"
+   wan_mac="$(grep -m1 mac= "/dev/mtd${index}" | cut -d= -f2)"
+   lan_mac=$wan_mac
+   ;;
wcr-150gn)
wan_mac=$(mtd_get_mac_binary factory 40)
;;
@@ -428,11 +438,6 @@ ramips_setup_macs()
wlr-6000)
wan_mac=$(macaddr_add "$(mtd_get_mac_binary factory 32772)" 2)
;;
-   wsr-1166)
-   local index="$(find_mtd_index "board_data")"
-   wan_mac="$(grep -m1 mac= "/dev/mtd${index}" | cut -d= -f2)"
-   lan_mac=$wan_mac
-   ;;
*)
lan_mac=$(cat /sys/class/net/eth0/address)
wan_mac=$(macaddr_add "$lan_mac" 1)
diff --git a/target/linux/ramips/base-files/etc/diag.sh 
b/target/linux/ramips/base-files/etc/diag.sh
index 84031d1..f6bae00 100644
--- a/target/linux/ramips/base-files/etc/diag.sh
+++ b/target/linux/ramips/base-files/etc/diag.sh
@@ -220,6 +220,12 @@ get_status_led() {
zbt-wr8305rt)
status_led="$board:green:sys"
;;
+   wcr-1166ds|\
+   whr-300hp2|\
+   wsr-1166|\
+   wsr-600)
+   status_led="$board:green:power"
+   ;;
wcr-150gn|\
wl-351)
status_led="$board:amber:power"
@@ -234,11 +240,6 @@ get_status_led() {
wizfi630a)
status_led="$board::run"
;;
-   whr-300hp2|\
-   wsr-1166|\
-   wsr-600)
-   status_led="$board:green:power"
-   ;;
wrtnode2r | \
wrtnode2p | \
wrtnode)
diff --git a/target/linux/ramips/base-files/lib/ramips.sh 
b/target/linux/ramips/base-files/lib/ramips.sh
index 5ab46de..71b31f6 100755
--- a/target/linux/ramips/base-files/lib/ramips.sh
+++ b/target/linux/ramips/base-files/lib/ramips.sh
@@ -502,6 +502,9 @@ ramips_board_detect() {
*"W502U")
name="w502u"
;;
+   *"WCR-1166DS")
+   name="wcr-1166ds"
+   ;;
*"WCR-150GN")
name="wcr-150gn"
;;
diff --git a/target/linux/ramips/base-files/lib/upgrade/platform.sh 
b/target/linux/ramips/base-files/lib/upgrade/platform.sh
index 05d2759..a43d370 100755
--- a/target/linux/ramips/base-files/lib/upgrade/platform.sh
+++ b/target/linux/ramips/base-files/lib/upgrade/platform.sh
@@ -227,6 +227,11 @@ platform_check_image() {
}
return 0
;;
+   ubnt-erx)
+   nand_do_platform_check "$board" "$1"
+   return $?;
+   ;;
+   wcr-1166ds|\

[LEDE-DEV] [PATCH v4 2/3] bcm53xx: build factory images for WZR-900DHP series

2017-01-28 Thread FUKAUMI Naoki
only factory images for DHP-EU and DHP2-JP (fw ver. 2.x) are built.

this will not work for DHP-JP/AP/TW (fw ver. 1.x) because they use
different buffalo_csum() formula.

Signed-off-by: FUKAUMI Naoki 
---
Changes in v4:
- no change

Changes in v3:
- renumbered, no change

Changes in v2:
- refresh everything to make rules simple

 target/linux/bcm53xx/image/Makefile | 26 ++
 1 file changed, 26 insertions(+)

diff --git a/target/linux/bcm53xx/image/Makefile 
b/target/linux/bcm53xx/image/Makefile
index e7a628b..75d1644 100644
--- a/target/linux/bcm53xx/image/Makefile
+++ b/target/linux/bcm53xx/image/Makefile
@@ -38,6 +38,17 @@ define Build/bcm53xx-tplink-safeloader
rm $@.trx
 endef
 
+define Build/buffalo-wzr-header
+   $(eval product=$(word 1,$(1)))
+   $(eval region=$(word 2,$(1)))
+   ( \
+   echo 
$(product)_$(BUFFALO_TAG_VERSION)_$(BUFFALO_TAG_MINOR)_$(region)_$(BUFFALO_TAG_PLATFORM);
 \
+   echo filelen=$$(stat -c%s $@); \
+   cat $@ \
+   ) > $@.new
+   mv $@.new $@
+endef
+
 define Build/trx-serial
$(STAGING_DIR_HOST)/bin/trx \
-o $@.new \
@@ -85,6 +96,7 @@ define Build/seama-nand
 endef
 
 DEVICE_VARS += PRODUCTID SIGNATURE NETGEAR_BOARD_ID NETGEAR_REGION TPLINK_BOARD
+DEVICE_VARS += BUFFALO_TAG_PLATFORM BUFFALO_TAG_VERSION BUFFALO_TAG_MINOR
 
 BRCMFMAC_43602A1 := kmod-brcmfmac brcmfmac-firmware-43602a1-pcie
 BRCMFMAC_4366B1 := kmod-brcmfmac brcmfmac-firmware-4366b1-pcie
@@ -149,6 +161,20 @@ endef
 TARGET_DEVICES += buffalo-wzr-600dhp2
 
 define Device/buffalo-wzr-900dhp
+  BUFFALO_TAG_PLATFORM := bcm
+  BUFFALO_TAG_VERSION := 9.99
+  BUFFALO_TAG_MINOR := 9.99
+  IMAGES += factory-DHP-EU.bin factory-DHP2-JP.bin
+  IMAGE/factory-DHP-EU.bin := \
+   append-ubi | trx-nand | buffalo-wzr-header WZR-900DHP EU | \
+   buffalo-enc WZR-900DHP $$(BUFFALO_TAG_VERSION) | \
+   buffalo-tag-dhp WZR-900DHP EU mlang20 | buffalo-enc-tag | \
+   buffalo-dhp-image
+  IMAGE/factory-DHP2-JP.bin := \
+   append-ubi | trx-nand | buffalo-wzr-header WZR-900DHP2 JP | \
+   buffalo-enc WZR-900DHP2 $$(BUFFALO_TAG_VERSION) | \
+   buffalo-tag-dhp WZR-900DHP2 JP jp | buffalo-enc-tag | \
+   buffalo-dhp-image
   DEVICE_TITLE := Buffalo WZR-900DHP
   DEVICE_PACKAGES := kmod-b43 $(USB3_PACKAGES)
 endef
-- 
2.7.4


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev


[LEDE-DEV] [PATCH] mxs: remove stale references to obsolete kernel module packages

2017-01-28 Thread Michael Heimpold
Commit 29443e2 (mxs: remove modules.mk, select drivers in the kernel config)
missed to remove these references, so cleanup it now.

Signed-off-by: Michael Heimpold 
---
 target/linux/mxs/Makefile   | 2 --
 target/linux/mxs/profiles/01-duckbill.mk| 3 +--
 target/linux/mxs/profiles/02-olinuxino-maxi.mk  | 6 ++
 target/linux/mxs/profiles/03-olinuxino-micro.mk | 5 +
 4 files changed, 4 insertions(+), 12 deletions(-)

diff --git a/target/linux/mxs/Makefile b/target/linux/mxs/Makefile
index ede5d6c..447c333 100644
--- a/target/linux/mxs/Makefile
+++ b/target/linux/mxs/Makefile
@@ -22,6 +22,4 @@ endef
 
 include $(INCLUDE_DIR)/target.mk
 
-DEFAULT_PACKAGES += kmod-wdt-stmp3xxx
-
 $(eval $(call BuildTarget))
diff --git a/target/linux/mxs/profiles/01-duckbill.mk 
b/target/linux/mxs/profiles/01-duckbill.mk
index 6b1dc18..cab379a 100644
--- a/target/linux/mxs/profiles/01-duckbill.mk
+++ b/target/linux/mxs/profiles/01-duckbill.mk
@@ -10,8 +10,7 @@ define Profile/duckbill
   FEATURES+=usbgadget
   PACKAGES+= \
-dnsmasq -firewall -ppp -ip6tables -iptables -6relayd -mtd 
uboot-envtools \
-   kmod-leds-gpio kmod-ledtrig-timer kmod-usb-mxs-phy -kmod-ipt-nathelper \
-   kmod-i2c-mxs kmod-spi-mxs uboot-mxs-duckbill
+   kmod-leds-gpio kmod-ledtrig-timer -kmod-ipt-nathelper uboot-mxs-duckbill
 endef
 
 define Profile/duckbill/Description
diff --git a/target/linux/mxs/profiles/02-olinuxino-maxi.mk 
b/target/linux/mxs/profiles/02-olinuxino-maxi.mk
index 7885d1f..59d0376 100644
--- a/target/linux/mxs/profiles/02-olinuxino-maxi.mk
+++ b/target/linux/mxs/profiles/02-olinuxino-maxi.mk
@@ -8,10 +8,8 @@
 define Profile/olinuxino-maxi
   NAME:=Olimex OLinuXino Maxi/Mini boards
   PACKAGES += imx-bootlets uboot-mxs-mx23_olinuxino \
- kmod-usb-mxs-phy kmod-usb-net kmod-usb-net-smsc95xx \
- kmod-gpio-mcp23s08 kmod-leds-gpio kmod-ledtrig-heartbeat 
kmod-rtc-stmp3xxx \
- kmod-sound-core kmod-sound-soc-mxs kmod-iio-mxs-lradc 
kmod-crypto-hw-dcp \
- kmod-i2c-mxs kmod-spi-mxs
+ kmod-usb-net kmod-usb-net-smsc95xx kmod-gpio-mcp23s08 \
+ kmod-leds-gpio kmod-ledtrig-heartbeat kmod-sound-core
 endef
 
 define Profile/olinuxino-maxi/Description
diff --git a/target/linux/mxs/profiles/03-olinuxino-micro.mk 
b/target/linux/mxs/profiles/03-olinuxino-micro.mk
index 356a877..535f6b5 100644
--- a/target/linux/mxs/profiles/03-olinuxino-micro.mk
+++ b/target/linux/mxs/profiles/03-olinuxino-micro.mk
@@ -8,10 +8,7 @@
 define Profile/olinuxino-micro
   NAME:=Olimex OLinuXino Micro/Nano boards
   PACKAGES += imx-bootlets uboot-mxs-mx23_olinuxino \
- kmod-usb-mxs-phy kmod-gpio-mcp23s08 kmod-leds-gpio \
- kmod-ledtrig-heartbeat kmod-rtc-stmp3xxx \
- kmod-iio-mxs-lradc kmod-crypto-hw-dcp \
- kmod-i2c-mxs kmod-spi-mxs
+ kmod-gpio-mcp23s08 kmod-leds-gpio kmod-ledtrig-heartbeat
 endef
 
 define Profile/olinuxino-micro/Description
-- 
2.7.4


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev


Re: [LEDE-DEV] LEDE-17.01 Final Release Notes available

2017-01-28 Thread Jaap Buurman
Great job on the release notes! One minor thing that I think looks
nicer would be the removal of "nothing specific" after "improved
performance", since it adds no additional information. But that's just
me.

Also about the following: "Improvements to the WiFi stack eliminating
bufferbloat on ath9k (and some ath10k) chipsets"

Is this about the Airtime Fairness Patch? AFAIK this is only for ath9k
and not for ath10k? Or am I mixing things up here?

While're talking about 17.01 anyway when are the first RCs coming out btw? :)

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev