From: Kalle Valo <kvalo@codeaurora.org>
To: Sebastian Gottschall <s.gottschall@dd-wrt.com>
Cc: Ben Greear <greearb@candelatech.com>,
linux-wireless@vger.kernel.org, ath10k@lists.infradead.org
Subject: Re: [PATCH v1] ath10k: fix band_center_freq handling for VHT160 in recent firmwares
Date: Fri, 25 May 2018 17:44:34 +0300 [thread overview]
Message-ID: <87wovr94ml.fsf@kamboji.qca.qualcomm.com> (raw)
In-Reply-To: <da5c7c56-9a41-99f0-28be-3a2c8e9fabbf@dd-wrt.com> (Sebastian Gottschall's message of "Thu, 26 Apr 2018 17:12:11 +0200")
Sebastian Gottschall <s.gottschall@dd-wrt.com> writes:
> Am 26.04.2018 um 15:44 schrieb Ben Greear:
>>
>>
>> On 04/26/2018 02:43 AM, s.gottschall@dd-wrt.com wrote:
>>> From: Sebastian Gottschall <s.gottschall@dd-wrt.com>
>>>
>>> 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?
--
Kalle Valo
_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k
next prev parent reply other threads:[~2018-05-25 14:44 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-04-26 9:43 [PATCH v1] ath10k: fix band_center_freq handling for VHT160 in recent firmwares s.gottschall
2018-04-26 13:44 ` Ben Greear
2018-04-26 15:12 ` Sebastian Gottschall
2018-05-25 14:44 ` Kalle Valo [this message]
2018-05-25 14:52 ` Ben Greear
2018-05-27 22:25 ` Sebastian Gottschall
2018-05-28 14:43 ` Ben Greear
2018-05-28 17:54 ` Sebastian Gottschall
2018-05-28 21:08 ` Ben Greear
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87wovr94ml.fsf@kamboji.qca.qualcomm.com \
--to=kvalo@codeaurora.org \
--cc=ath10k@lists.infradead.org \
--cc=greearb@candelatech.com \
--cc=linux-wireless@vger.kernel.org \
--cc=s.gottschall@dd-wrt.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox