WMI version handling

[Kalle Valo]

Ben Greear <greearb at candelatech.com> writes:

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

Yeah, there's no problem at the moment. But if we start adding more
interfaces handling them through feature flags will become more
difficult. That's why I think adding a separate enum will be better in
the long run.

> I'd leave policy out of the IEs as much as possible, as normal users
> cannot modify it, and certainly it would be a problem if you wanted
> different policy with different NICs in same system. IEs should
> describe the minimum needed for the ath10k to enforce policy as best
> as it can.

The firmware IEs are not about policy. They are about advertising the
capabilities of the firmware image so that ath10k can know how to
configure the firmare.

> We have to assume that users tweaking station and peer count can deal
> with fw crashes until they get the settings right.

No way. In no circumstances ath10k should configure firmware out of
bounds. If we do that, it's a bug in ath10k.

-- 
Kalle Valo