[OpenWrt-Devel] [PATCH] kernel: ath10k-ct: provide a build variant for small RAM devices
greearb at candelatech.com
Wed Dec 11 14:24:19 EST 2019
On 12/11/19 11:16 AM, 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  the default ath10k-ct kernel
>> And also if you want to just have the makefile pass a -DBUILD_ATH10K_SMALL or something
>> like that and #ifdef code in the ath10k-ct driver, then I'd apply that patch to ath10k-ct
>> so that you don't need the patches.
> I am offering my patch to the OpenWrt maintainers as kind of a
> stop-gap measure to get ath10k-ct working for the release (or in any
> way they think is appropriate). Another approach they can choose is to
> select the upstream ath10k for those devices. Otherwise some
> previously supported boards will require manual intervention to get
> WiFi working after an upgrade.
> Regarding your fwcfg idea, I am not sure it will work as it seems the
> PCI initialisation is happening before fwcfg is parsed and applied.
> Adding a Kconfig option is another possibility.
> But what do you think about an additional module parameter, wouldn't
> it be the cleanest solution in the long run?
If fwcfg will not work, and maybe it just will not due to the reasons you
suggest, then I'm fine with adding a module parameter to ath10k-ct.
You may want to conditionally compile the default value of that module parameter
so that on the small platforms the user does not actually have to set the module
param if they want the default (small) values?
> BTW, according to the git logs the patches were initially added by
> Christian Lamparter, so I hope he can clarify the situation a
> bit. Probably there were some performance tests executed back than to
> measure the impact.
Ben Greear <greearb at candelatech.com>
Candela Technologies Inc http://www.candelatech.com
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
More information about the openwrt-devel