WMI version handling

[Kalle Valo]

Michal Kazior <michal.kazior at tieto.com> writes:

> On 3 September 2014 17:00, Ben Greear <greearb at candelatech.com> wrote:
>> On 09/02/2014 11:14 PM, Kalle Valo wrote:
>>> Hi,
> [...]
>>> Also I have been thinking that using firmware feature bits (for example
>>> ATH10K_FW_FEATURE_WMI_10_2 and ATH10K_FW_FEATURE_WMI_10X) for WMI
>>> version is not the best way. I think it's easier to manage all this if
>>> we have a u32 FW IE to provide WMI version. IIRC Ben was suggesting this
>>> at some point.
>>>
>>> Example:
>>>
>>> enum ath10k_fw_wmi_version {
>>>       ATH10K_FW_WMI_VERSION_MAIN = 0,
>>>       ATH10K_FW_WMI_VERSION_10_1 = 1,
>>>       ATH10K_FW_WMI_VERSION_10_2 = 2,
>>> }
>>>
>>> And then wmi.c would set correct interface based on this version.
>>
>> I am happy with the current flags, it seems to work well enough.
>
> I'm actually okay with this but I'd actually throw out the "wmi"
> string from it and leave out just "ath10k_fw_version". I've recently
> discovered some minor HTT discrepancies between fw branches so we
> might want to use the version tag to pick HTT "backend" as well..

I'm again thinking that we should have a separate enum for the HTT
version. So that the firmware interface is defined with WMI version, HTT
version and feature flags (which define smaller changes in the
interface).

-- 
Kalle Valo