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
