Hello, On Tue, May 31, 2016 at 06:57:52PM +0000, Valo, Kalle wrote: > Mohammed Shafi Shajakhan <moham...@codeaurora.org> writes: > > >> > +void ath10k_sta_update_rx_duration(struct ath10k *ar, > >> > + struct ath10k_fw_stats *stats) > >> > +{ > >> > + struct ath10k_fw_file *fw_file = &ar->normal_mode_fw.fw_file; > >> > + > >> > + if (fw_file->wmi_op_version < ATH10K_FW_WMI_OP_VERSION_10_4) > >> > + ath10k_sta_update_stats_rx_duration(ar, &stats->peers); > >> > + else > >> > + ath10k_sta_update_extd_stats_rx_duration(ar, > >> > + > >> > &stats->peers_extd); > >> > +} > >> > >> _Ideally_ wmi_op_version should be used only in ath10k_wmi_attach() and > >> nowhere else. Isn't there any other way to detect this scenario? For > >> example, what if you store stats_id to struct ath10k_fw_stats and do > >> something like this: > >> > >> if (stats->stats_id & WMI_10_4_STAT_PEER_EXTD) > >> ath10k_sta_update_extd_stats_rx_duration(ar, > >> &stats->peers_extd); > >> else > >> ath10k_sta_update_stats_rx_duration(ar, &stats->peers); > >> > >> Would that work? > > > > [shafi] I am also thinking to re-use (ar->fw_stats_req_mask & > > WMI_10_4_STAT_PEER_EXTD) > > it might work, but will it conflict vdev stats WMI_STAT_VDEV (though its > > not currently > > supported for 10.2 ) > > Can you describe more how they conflict?
[shafi] 'WMI_STAT_VDEV' and 'WMI_10_4_STAT_PEER_EXTD' are having the same value BIT(3), though as of now we are only 'WMI_10_4_STAT_PEER_EXTD' for 10.4 > > > let me know your thoughts about this, seems extended stats was > > implemented for 10.4 wmi version so i made it explicit > > I don't like hard coding features like this based on wmi_op_version as > that might create problems managing the firmware interfaces in the > future. The simplest is if we can automatically runtime detect if > firmware uses the extended version or not. > [shafi] Sure i come up with something else to address this in v3. regards shafi -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html