Re: 9984 VHT

[Adrian Chadd <adrian@freebsd.org>]

aiee, some clients messed up freq1/freq2 handling in this way?



-adrian

On 14 February 2017 at 07:21, Sebastian Gottschall
<s.gottschall@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@dd-wrt.com> writes:
>>
>>> Am 10.02.2017 um 07:50 schrieb Valo, Kalle:
>>>>
>>>> Sebastian Gottschall <s.gottschall@dd-wrt.com> writes:
>>>>
>>>>> Am 07.02.2017 um 13:14 schrieb Valo, Kalle:
>>>>>>
>>>>>> Ben Greear <greearb@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@dd-wrt.com
> Tel.: +496251-582650 / Fax: +496251-5826565
>
>
> _______________________________________________
> ath10k mailing list
> ath10k@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/ath10k

_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k