Re: 9984 VHT

From: "Valo, Kalle" <kvalo@qca.qualcomm.com>
To: Sebastian Gottschall <s.gottschall@dd-wrt.com>
Cc: "ath10k@lists.infradead.org" <ath10k@lists.infradead.org>
Subject: Re: 9984 VHT
Date: Tue, 14 Feb 2017 10:30:14 +0000	[thread overview]
Message-ID: <87inodrro1.fsf@kamboji.qca.qualcomm.com> (raw)
In-Reply-To: <c894f9ae-068a-eac3-16e6-c1ada4da22b9@dd-wrt.com> (Sebastian Gottschall's message of "Fri, 10 Feb 2017 13:38:03 +0100")

(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.

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