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 [0][1][2] 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?
Thanks,
Ben
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 <gree...@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
_______________________________________________
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
