[OpenWrt-Devel] [sdwalker/sdwalker.github.io] 6bb22e: This week's update

2019-12-15 Thread Stephen Walker
Branch: refs/heads/master Home: https://github.com/sdwalker/sdwalker.github.io Commit: 6bb22e3b77caeb9b283610ce8d7b1d42bb4dc1e9 https://github.com/sdwalker/sdwalker.github.io/commit/6bb22e3b77caeb9b283610ce8d7b1d42bb4dc1e9 Author: Stephen Walker Date: 2019-12-15 (Sun, 15 Dec

Re: [OpenWrt-Devel] Lantiq DTS rename

2019-12-15 Thread Adrian Schmutzler
Well, we could change it for ath79 and ramips right now, would be a simple rename without side effects. We could use just SOC as proposed. I'd prefer to decide on the name right away and then would apply the patch directly without sending it to the list, to save us from rebasing... Best

[OpenWrt-Devel] [PATCH v2] kernel: ath10k-ct: provide a build variant for small RAM devices

2019-12-15 Thread Paul Fertser
According to many bugreports [0][1][2] the default ath10k-ct kernel module is unusable on devices with just 64 MiB RAM or with 128 MiB and dual ath10k cards. The target boards boot but eventually oom-killer starts to interfere with normal operation, so the current state is effectively broken.

Re: [OpenWrt-Devel] Lantiq DTS rename

2019-12-15 Thread Daniel Golle
On Sun, Dec 15, 2019 at 05:53:42PM +0100, m...@adrianschmutzler.de wrote: > Hi, > > how would you call the SOC variable in image Makefile then? (the equivalent > to ATH_SOC and MTK_SOC...) In a way those variables should be unified into something like 'SOC'... For now, maybe 'LTQ_SOC' will do

Re: [OpenWrt-Devel] Lantiq DTS rename

2019-12-15 Thread Hauke Mehrtens
On 12/15/19 5:53 PM, m...@adrianschmutzler.de wrote: > Hi, > > how would you call the SOC variable in image Makefile then? (the equivalent > to ATH_SOC and MTK_SOC...) > > Best > > Adrian Lantiq currently has these 3: CONFIG_SOC_AMAZON_SE CONFIG_SOC_XWAY CONFIG_SOC_FALCON I would use these

Re: [OpenWrt-Devel] Lantiq DTS rename

2019-12-15 Thread mail
Hi, how would you call the SOC variable in image Makefile then? (the equivalent to ATH_SOC and MTK_SOC...) Best Adrian > -Original Message- > From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org] > On Behalf Of Hauke Mehrtens > Sent: Sonntag, 15. Dezember 2019 14:49 >

[OpenWrt-Devel] [PATCH] linux-firmware: update to 20191215

2019-12-15 Thread DENG Qingfang
Update linux-firmware to 20191215 git log --pretty=oneline --abbrev-commit 20190815..20191215 eefb5f7 inside-secure: add new "mini" firmware for the EIP197 driver dd1a12e Merge branch 'RB3-adsp-cdsp-mss-v4' of https://github.com/andersson/linux-firmware c523dcd WHENCE: Add raspberr

Re: [OpenWrt-Devel] [PATCH] kernel: ath10k-ct: provide a build variant for small RAM devices

2019-12-15 Thread Ben Greear
On 12/15/2019 05:09 AM, Christian Lamparter wrote: On Sunday, 15 December 2019 13:01:14 CET Paul Fertser wrote: Thank you for the answer Christian, On Sun, Dec 15, 2019 at 12:00:48PM +0100, Christian Lamparter wrote: I think for this to have any chance of moving forward you'll need to

Re: [OpenWrt-Devel] Lantiq DTS rename

2019-12-15 Thread Hauke Mehrtens
On 12/15/19 2:27 PM, Daniel Golle wrote: > Hi Adrian, > > On Sun, Dec 15, 2019 at 02:10:14PM +0100, m...@adrianschmutzler.de wrote: >> Hi, >> >> I consider doing a DTS rename for lantiq target similar to what it's like on >> ath79 and what I did for ramips earlier that year. >> >> However, I

Re: [OpenWrt-Devel] Lantiq DTS rename

2019-12-15 Thread Daniel Golle
Hi Adrian, On Sun, Dec 15, 2019 at 02:10:14PM +0100, m...@adrianschmutzler.de wrote: > Hi, > > I consider doing a DTS rename for lantiq target similar to what it's like on > ath79 and what I did for ramips earlier that year. > > However, I wonder whether the "soc_vendor_model.dts" scheme is

[OpenWrt-Devel] Lantiq DTS rename

2019-12-15 Thread mail
Hi, I consider doing a DTS rename for lantiq target similar to what it's like on ath79 and what I did for ramips earlier that year. However, I wonder whether the "soc_vendor_model.dts" scheme is useful there, or whether it wouldn't be better to just use "vendor_model.dts" ... Any thoughts on

Re: [OpenWrt-Devel] [PATCH] kernel: ath10k-ct: provide a build variant for small RAM devices

2019-12-15 Thread Christian Lamparter
On Sunday, 15 December 2019 13:01:14 CET Paul Fertser wrote: > Thank you for the answer Christian, > > On Sun, Dec 15, 2019 at 12:00:48PM +0100, Christian Lamparter wrote: > > I think for this to have any chance of moving forward you'll need to > > pressure your ODMs and if that doesn't work: Go

Re: [OpenWrt-Devel] [PATCH] kernel: ath10k-ct: provide a build variant for small RAM devices

2019-12-15 Thread Paul Fertser
On Sun, Dec 15, 2019 at 12:00:48PM +0100, Christian Lamparter wrote: > From what I remember Sven Eckelmann also measured the impact from the > patches on the performance and posted his results to the OpenWrt ML > (google will find them). https://github.com/freifunk-gluon/gluon/pull/1440 is what

Re: [OpenWrt-Devel] [PATCH] kernel: ath10k-ct: provide a build variant for small RAM devices

2019-12-15 Thread Paul Fertser
Thank you for the answer Christian, On Sun, Dec 15, 2019 at 12:00:48PM +0100, Christian Lamparter wrote: > I think for this to have any chance of moving forward you'll need to > pressure your ODMs and if that doesn't work: Go with a different WIFI > chip vendor that supports low memory devices,

Re: [OpenWrt-Devel] [PATCH] kernel: ath10k-ct: provide a build variant for small RAM devices

2019-12-15 Thread Christian Lamparter
On Wednesday, 11 December 2019 20:16:52 CET Paul Fertser wrote: > Hey Ben, > > On Wed, Dec 11, 2019 at 10:06:26AM -0800, Ben Greear wrote: > > On 12/11/19 6:44 AM, Paul Fertser wrote: > > > According to many bugreports [0][1][2] the default ath10k-ct kernel > ... > > And also if you want to just