Am 25.05.2018 um 16:52 schrieb Ben Greear:
On 05/25/2018 07:44 AM, Kalle Valo wrote:
Sebastian Gottschall <s.gottschall@xxxxxxxxxx> writes:
Am 26.04.2018 um 15:44 schrieb Ben Greear:
On 04/26/2018 02:43 AM, s.gottschall@xxxxxxxxxx wrote:
From: Sebastian Gottschall <s.gottschall@xxxxxxxxxx>
starting with firmware 10.4.3.4.x series QCA changed the handling
of the channel property band_center_freq1 and band_center_freq2 in
vht160 operation mode
likelly for backward compatiblity with vht80 only capable clients.
this patch adjusts the handling to get vht160 to work again with
official qca firmwares newer than 3.3
consider that this patch will not work with older firmwares
anymore. to avoid undefined behaviour this we disable vht160
capability for outdated firmwares
We should be able to use a feature-flag or otherwise determine if
the firmware needs the old or new
API and make the driver able to handle both.
the new firmware must be used as is and it works. the old firmware can
be detected on the missing vht cap flag.
but thats not my task. i can only use feature flags if they are
included within the qca firmwares. but they arent
the old pre 3.3 firmwares should be treated as obsolete. they are more
than 2 years old and do not announce vht160 capability
even if it works with some ignorance, but on the other side the it has
backward incompatiblies with older vht80 only clients.
this is why the new way was introduced
I was told ath10k could check for WMI_SERVICE_EXTENDED_NSS_SUPPORT flag.
Can someone test and verify that?
I do see that my firmware source based on older upstream QCA FW does
not advertise
that flag, and newer QCA firmware does, so it would appear that test
might
work.
but your sourcebase is new enough that this new handling is required.
if i remember correct this handling is required starting with 10.4-3.4
source base
if a 3.4 original firmware is not providing that flag, it cannot be used
for correct handling and yours is 3.4 based
Thanks,
Ben
