9984 VHT

[Valo, Kalle]

Sebastian Gottschall <s.gottschall at dd-wrt.com> writes:

> 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

Thanks, this was good. I sent this forward now.

-- 
Kalle Valo