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

[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
>>> pressure your ODMs and if that doesn't work: Go with a different WIFI
>>> chip vendor that supports low memory devices, or add more RAM.
>>> From what I can tell, Qualcomm nowadays gets what they want "for free"
>>> and for the past four-five years, they certainly didn't feel pressured
>>> to add "low memory" support to ath10k.
>>
>> FWIW, OpenWrt's ath10k vendor is CT now, not QCA, so it's not much
>> relevant what do ODMs and (whatever is left from) QCA say, I guess.
> Well, not sure what you are trying to say here. But I think Ben is free
> to do what he wants as well. For example see the:
> "ath10k: add LED and GPIO controlling support for various chipsets"
> patch that OpenWrt has been carrying because neither upstream (linux-wireless)
> nor CT wants to integrate it.
> <https://github.com/openwrt/openwrt/blob/master/package/kernel/ath10k-ct/patches/201-ath10k-4.16_add-LED-and-GPIO-controlling-support-for-various-chipsets.patch>
>
> The situation with the "low memory" support wasn't much better. Because
> from what I remember, there was a discussion about this very topic between
> Ben an Hauke in the past (and you can see how it played out, since you wouldn't
> have posted this series if it was integrated back then).
> But it seems that Ben had a change of heart in this regard. I don't know the
> details or why, But it makes sense because it would enable his company to save
> some money for the systems his company sells:
>  <https://www.candelatech.com/lf_systems.php> so there is some value
> in supporting these devices, especially if someone else does all the work
> for it.

My goal is to have stable and fully featured ath10k that works well for higher powered
systems by default (our test rigs are typically powerful x86 with gigs of RAM running
Fedora or similar).

OpenWRT is all about adding patches on top of upstream projects for specific platforms, so that
would easily work with ath10k-ct too.

And, if someone wants to write a patch that either modifies ath10k-ct for OpenWRT
to work better on certain systems, then by all means, go ahead.  This should be just
as easy as doing the same thing for upstream ath10k.

If someone writes a patch that conditionally compiles for OpenWRT and/or allows
OpenWRT to configure smaller memory usage, then I will apply that to my ath10k-ct
driver (with caveat that defaults for non openwrt systems needs to remain as is).

Thanks,
Ben

-- 
Ben Greear <greearb at candelatech.com>
Candela Technologies Inc  http://www.candelatech.com

_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel