Michal Kazior <[email protected]> writes: > On 3 September 2014 17:00, Ben Greear <[email protected]> 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 _______________________________________________ ath10k mailing list [email protected] http://lists.infradead.org/mailman/listinfo/ath10k
