Re: [OpenWrt-Devel] [PATCH 2/2] ath79: add support for Fritz!Box 4020

2018-08-12 Thread John Crispin
Hi this following chunk need to be annotated and sent upstream. also using initvals might not be the best option. please also check if there is a binding doc and add this new property.     John diff --git a/target/linux/ath79/patches-4.14/005-gpio-74x164-add-initvals.patch b/target/linux/at

Re: [OpenWrt-Devel] openwrt/packages: [RFC] Proposed flattening of menuconfig menus

2018-08-12 Thread Daniel Dickinson
On 2018-08-13 01:51 AM, Eric Luehrsen wrote: > On 08/13/2018 01:29 AM, Daniel F. Dickinson wrote: >> Posting on list as I think the discussion should include as folks as >> possible in the discussion. >> >> https://github.com/openwrt/packages/issues/6745 >> >>> Especially when getting started with

[OpenWrt-Devel] openwrt/packages: [RFC] Regarding preferences re: switch to codeload

2018-08-12 Thread Daniel F. Dickinson
Posting here as this seems to me to be a project decision: From: https://github.com/openwrt/packages/issues/6748 > @neheb Has submitted a number of PR's (referenced in #6584), full list of > his/her PR's (which probably include the codeload thing for any github > pulls): https://github.com/op

Re: [OpenWrt-Devel] openwrt/packages: [RFC] Proposed flattening of menuconfig menus

2018-08-12 Thread Eric Luehrsen
On 08/13/2018 01:29 AM, Daniel F. Dickinson wrote: Posting on list as I think the discussion should include as folks as possible in the discussion. https://github.com/openwrt/packages/issues/6745 Especially when getting started with OpenWrt finding things in menuconfig is complicated by the s

[OpenWrt-Devel] openwrt/packages: [RFC] Proposed flattening of menuconfig menus

2018-08-12 Thread Daniel F. Dickinson
Posting on list as I think the discussion should include as folks as possible in the discussion. https://github.com/openwrt/packages/issues/6745 > Especially when getting started with OpenWrt finding things in menuconfig is > complicated by the second level menus that are sometimes used and some

[OpenWrt-Devel] [PATCH 2/2] ath79: add support for Fritz!Box 4020

2018-08-12 Thread David Bauer
This commit adds support for the AVM Fritz!Box 4020 WiFi-router. SoC: Qualcomm Atheros QCA9561 (Dragonfly) 750MHz RAM: Winbond W971GG6KB-25 FLASH: Macronix MX25L12835F WiFi: QCA9561 b/g/n 3x3 450Mbit/s USB: 1x USB 2.0 IN:WPS button, WiFi button OUT: Power LED green, Internet LED green

[OpenWrt-Devel] [PATCH 1/2] ath79: add QCA956x GMAC config

2018-08-12 Thread David Bauer
This commit adds the ability to configure the GMAC of the QCA956x. Signed-off-by: David Bauer --- target/linux/ath79/dts/qca956x.dtsi | 5 + .../net/ethernet/atheros/ag71xx/ag71xx_gmac.c | 13 + 2 files changed, 18 insertions(+) diff --git a/target/linux/a

Re: [OpenWrt-Devel] [PATCH] wireguard: bump to 0.0.20180809

2018-08-12 Thread Hans Dedecker
On Sun, Aug 12, 2018 at 10:32 AM Jason A. Donenfeld wrote: > > * send: switch handshake stamp to an atomic > > Rather than abusing the handshake lock, we're much better off just using > a boring atomic64 for this. It's simpler and performs better. Also, while > we're at it, we set the handshake st

Re: [OpenWrt-Devel] [PATCH 4/5] ath79: add ath9k calibration data MAC addresses patching

2018-08-12 Thread Christian Lamparter
On Saturday, August 11, 2018 10:23:16 PM CEST Mathias Kresin wrote: > 10.08.2018 23:24, Christian Lamparter: > > This patch copies over the MAC patching helper functions from lantiq's > > target/linux/lantiq/base-files/etc/hotplug.d/firmware/12-ath9k-eeprom > > file. > > > > Not all vendors bother

Re: [OpenWrt-Devel] [PATCH 2/5] ath79: port cybertan_part from ar71xx

2018-08-12 Thread Christian Lamparter
On Saturday, August 11, 2018 10:16:06 PM CEST Jonas Gorski wrote: > On 10 August 2018 at 23:24, Christian Lamparter wrote: > > The cybertan_part mtd parser is ported over from ar71xx and converted > > to integrate into the "firmware" mtd splitter. It will no longer add > > the u-boot, nvram and ar

[OpenWrt-Devel] [PATCH] wireguard: bump to 0.0.20180809

2018-08-12 Thread Jason A. Donenfeld
* send: switch handshake stamp to an atomic Rather than abusing the handshake lock, we're much better off just using a boring atomic64 for this. It's simpler and performs better. Also, while we're at it, we set the handshake stamp both before and after the calculations, in case the calculations bl