9984 VHT
Sebastian Gottschall
s.gottschall at dd-wrt.com
Thu Feb 16 08:34:50 PST 2017
Am 16.02.2017 um 17:20 schrieb Adrian Chadd:
> aiee, some clients messed up freq1/freq2 handling in this way?
as it seems. but i have no proof for this. i just readed the comment of
the hostapd patch
but what i know is that breaking the api by handling this within the
firmware itself instead of handling it in the accessible driver or
hostapd is a bad decision
>
>
>
> -adrian
>
> On 14 February 2017 at 07:21, Sebastian Gottschall
> <s.gottschall at dd-wrt.com> wrote:
>> Am 14.02.2017 um 11:30 schrieb Valo, Kalle:
>>> (you forgot to CC ath10k list, adding it back)
>>>
>>> Sebastian Gottschall <s.gottschall at dd-wrt.com> writes:
>>>
>>>> Am 10.02.2017 um 07:50 schrieb Valo, Kalle:
>>>>> Sebastian Gottschall <s.gottschall at dd-wrt.com> writes:
>>>>>
>>>>>> Am 07.02.2017 um 13:14 schrieb Valo, Kalle:
>>>>>>> Ben Greear <greearb at candelatech.com> writes:
>>>>>>>
>>>>>>>> On 02/02/2017 10:42 AM, Sebastian Gottschall wrote:
>>>>>>>>> Am 02.02.2017 um 19:24 schrieb Ben Greear:
>>>>>>>>>
>>>>>>>>>> I hacked ath10k to enable radar detection on 160Mhz bandwidths. Now
>>>>>>>>>> hostapd
>>>>>>>>>> starts.
>>>>>>>>>>
>>>>>>>>>> I can reproduce the FW failure. It is because FW 3.3-25 release
>>>>>>>>>> started asserting
>>>>>>>>>> if the freq2 was zero in VHT160 mode. It seems to use both freq1
>>>>>>>>>> and freq2, and not
>>>>>>>>>> how the driver or linux seems to normally use them.
>>>>>>>>> its even worse. starting from 3.3 it uses freq2 instead of freq1.
>>>>>>>>> but i made a patch for it. but it still wont work. vdev_start still
>>>>>>>>> fails
>>>>>>>> Well it would have been helpful from the start to have known about
>>>>>>>> this patch.
>>>>>>>>
>>>>>>>> Could you post it?
>>>>>>>>
>>>>>>>> Kalle: Since the firmware API changed, how do you want to handle
>>>>>>>> the differences here?
>>>>>>> The firmware API shouldn't change like that, but if it has I guess a
>>>>>>> firmware feature flag to enable a workaround in ath10k sounds like the
>>>>>>> easiest solution.
>>>>>> the more recent firmware have some new wmi services enabled which can
>>>>>> be used as indicator as well.
>>>>> I don't know what flag exactly you are referring to, but using a WMI
>>>>> service flag to detect this is not really reliable. They can be enabled
>>>>> or disabled between branches, or even between builds.
>>>> valid argument. but these flags should than be also introduced in
>>>> codeaurora images
>>> I'm not involved with codeaurora images so I can't help with that.
>>>
>>> But the firmware is not supposed to break the firmware interface like
>>> this. Can someone please write a detailed bug report as a reply to this
>>> mail (what version, from which location, how exactly the interface is
>>> broken) and I'll try to report the issue internally.
>> i'm not good in this. but let me try to describe whats wrong
>> all the current firmware images including your latest 3.3 based suffer from
>> this issue.
>> old behaviour with
>> https://github.com/kvalo/ath10k-firmware/raw/master/QCA9984/hw1.0/firmware-5.bin_10.4-3.2-00072
>> center freq is stored in band_center_freq1
>>
>> new behaviour with
>> https://github.com/kvalo/ath10k-firmware/raw/master/QCA9984/hw1.0/3.3/firmware-5.bin_10.4-3.3-00092
>> and all other newers including 3.4 series
>> center freq is stored in band_center_freq2. where center_freq1 must contain
>> the lower or upper side channel depending on the setting
>>
>> example for new firmware in ath10k_wmi_put_wmi_channel
>> if (arg->mode == MODE_11AC_VHT160) {
>> if (arg->freq < arg->band_center_freq1)
>> ch->band_center_freq1 =
>> __cpu_to_le32(arg->band_center_freq1 - 40);
>> else
>> ch->band_center_freq1 =
>> __cpu_to_le32(arg->band_center_freq1 + 40);
>> ch->band_center_freq2 =
>> __cpu_to_le32(arg->band_center_freq1);
>> }
>>
>> according to some code i found in hostapd this has been made to workaround a
>> issue with vht80 capable client who arent able to associate with vht160
>> networks.
>> the same workaround has been implemented in recent hostapd versions. so
>> solving this on firmware side isnt neccessary, but qca was going this way
>>
>> see also this patch which is now in mainline of hostapd
>>
>> https://github.com/kaloz/mwlwifi/blob/master/hostapd/700-interoperability-workaround-for-80%2B80-and-160-MHz-channels
>>
>> you will clearly see that it is related to the new behaviour of the qca9984
>> firmware (and likelly other vht160mhz capable chipset firmware, but i can't
>> check them without having the devices)
>>
>>
>>
>> --
>> Mit freundlichen Grüssen / Regards
>>
>> Sebastian Gottschall / CTO
>>
>> NewMedia-NET GmbH - DD-WRT
>> Firmensitz: Berliner Ring 101, 64625 Bensheim
>> Registergericht: Amtsgericht Darmstadt, HRB 25473
>> Geschäftsführer: Peter Steinhäuser, Christian Scheele
>> http://www.dd-wrt.com
>> email: s.gottschall at dd-wrt.com
>> Tel.: +496251-582650 / Fax: +496251-5826565
>>
>>
>> _______________________________________________
>> ath10k mailing list
>> ath10k at lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/ath10k
--
Mit freundlichen Grüssen / Regards
Sebastian Gottschall / CTO
NewMedia-NET GmbH - DD-WRT
Firmensitz: Berliner Ring 101, 64625 Bensheim
Registergericht: Amtsgericht Darmstadt, HRB 25473
Geschäftsführer: Peter Steinhäuser, Christian Scheele
http://www.dd-wrt.com
email: s.gottschall at dd-wrt.com
Tel.: +496251-582650 / Fax: +496251-5826565
More information about the ath10k
mailing list