Message ID | CA+aCzhWdntL=qjstnE+YenW4bxE=D+ERKcNg+YLwOpgqBphWqg@mail.gmail.com (mailing list archive) |
---|---|
State | Not Applicable |
Headers | show |
On 27 January 2015 at 14:08, Sylvain ROGER RIEUNIER <sylvain.roger.rieunier@gmail.com> wrote: > I just made some tests with the ath10k driver in IBSS mode and I found > several problems: > > 1) TSF management can't be done correctly. You can't make GET, SET or > RESET actions, because no command is sent to the firmware. However the > WMI_RTT_TSF_CMDID command exists. I tried some changes (see patch), > but they did not produce any effect. This isn't implemented in firmware 636 as far as I know. > 2) Rate control update is not functional in the firmware. Data rate is > stuck at 25 Mbit/s between an ath10k IBSS station and an ath9k IBSS > station. However the rate control update works fine in mac80211 (I > checked it thanks to IBSS debug msg) and IE HT settings are correctly > transmitted on both side (I checked it using a third interface in > monitor mode). The ath10k_wmi_peer_assoc command does not seem to work > for reassoc state to update data rate. Janusz has done some patches related to the hw rate control issues with IBSS recently: https://github.com/kvalo/ath/commit/627d9841eaa623e34657af7af0e6293805e07888 https://github.com/kvalo/ath/commit/55884c045d31a29cf69db8332d1064a1b61dd159 > Conclusion: the firmware seems incomplete for IBSS mode operation. Is > there any planned development on the IBSS mode in the firmware? > > Note: I did my tests with the firmware-2.bin_999.999.0.636 firmware. Ben has recently added IBSS support for his 10.1 firmware fork: http://thread.gmane.org/gmane.linux.drivers.ath10k.devel/1023/focus=1026 You might be interested in giving it a try. Micha?
Dear Michal, I have already tried the CT firmware. Association between stations works better, But the rate control update is still broken. It does not work in HT mode. Sylvain 2015-01-27 14:18 GMT+01:00 Michal Kazior <michal.kazior@tieto.com>: > On 27 January 2015 at 14:08, Sylvain ROGER RIEUNIER > <sylvain.roger.rieunier@gmail.com> wrote: >> I just made some tests with the ath10k driver in IBSS mode and I found >> several problems: >> >> 1) TSF management can't be done correctly. You can't make GET, SET or >> RESET actions, because no command is sent to the firmware. However the >> WMI_RTT_TSF_CMDID command exists. I tried some changes (see patch), >> but they did not produce any effect. > > This isn't implemented in firmware 636 as far as I know. > > >> 2) Rate control update is not functional in the firmware. Data rate is >> stuck at 25 Mbit/s between an ath10k IBSS station and an ath9k IBSS >> station. However the rate control update works fine in mac80211 (I >> checked it thanks to IBSS debug msg) and IE HT settings are correctly >> transmitted on both side (I checked it using a third interface in >> monitor mode). The ath10k_wmi_peer_assoc command does not seem to work >> for reassoc state to update data rate. > > Janusz has done some patches related to the hw rate control issues > with IBSS recently: > > https://github.com/kvalo/ath/commit/627d9841eaa623e34657af7af0e6293805e07888 > https://github.com/kvalo/ath/commit/55884c045d31a29cf69db8332d1064a1b61dd159 > > >> Conclusion: the firmware seems incomplete for IBSS mode operation. Is >> there any planned development on the IBSS mode in the firmware? >> >> Note: I did my tests with the firmware-2.bin_999.999.0.636 firmware. > > Ben has recently added IBSS support for his 10.1 firmware fork: > > http://thread.gmane.org/gmane.linux.drivers.ath10k.devel/1023/focus=1026 > > You might be interested in giving it a try. > > > Micha?
On 01/27/2015 05:55 AM, Sylvain ROGER RIEUNIER wrote: > Dear Michal, > > I have already tried the CT firmware. Association between stations > works better, But the rate control update is still broken. > It does not work in HT mode. Rate-ctrl is not a problem with the firmware....some users have reported 700Mbps or so in IBSS mode with my firmware. I haven't managed to get kernel and supplicant properly patched for all this yet..but will get it done eventually (and patches should make it up stream sometime soon too I think). Thanks, Ben > > > Sylvain > > 2015-01-27 14:18 GMT+01:00 Michal Kazior <michal.kazior@tieto.com>: >> On 27 January 2015 at 14:08, Sylvain ROGER RIEUNIER >> <sylvain.roger.rieunier@gmail.com> wrote: >>> I just made some tests with the ath10k driver in IBSS mode and I found >>> several problems: >>> >>> 1) TSF management can't be done correctly. You can't make GET, SET or >>> RESET actions, because no command is sent to the firmware. However the >>> WMI_RTT_TSF_CMDID command exists. I tried some changes (see patch), >>> but they did not produce any effect. >> >> This isn't implemented in firmware 636 as far as I know. >> >> >>> 2) Rate control update is not functional in the firmware. Data rate is >>> stuck at 25 Mbit/s between an ath10k IBSS station and an ath9k IBSS >>> station. However the rate control update works fine in mac80211 (I >>> checked it thanks to IBSS debug msg) and IE HT settings are correctly >>> transmitted on both side (I checked it using a third interface in >>> monitor mode). The ath10k_wmi_peer_assoc command does not seem to work >>> for reassoc state to update data rate. >> >> Janusz has done some patches related to the hw rate control issues >> with IBSS recently: >> >> https://github.com/kvalo/ath/commit/627d9841eaa623e34657af7af0e6293805e07888 >> https://github.com/kvalo/ath/commit/55884c045d31a29cf69db8332d1064a1b61dd159 >> >> >>> Conclusion: the firmware seems incomplete for IBSS mode operation. Is >>> there any planned development on the IBSS mode in the firmware? >>> >>> Note: I did my tests with the firmware-2.bin_999.999.0.636 firmware. >> >> Ben has recently added IBSS support for his 10.1 firmware fork: >> >> http://thread.gmane.org/gmane.linux.drivers.ath10k.devel/1023/focus=1026 >> >> You might be interested in giving it a try. >> >> >> Micha? > > _______________________________________________ > ath10k mailing list > ath10k@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/ath10k >
For the rate control issue, please make sure that sta->sta.wme = true in ibss.c Refer the following: http://lists.infradead.org/pipermail/ath10k/2014-December/003982.html For CT firmware, you have mentioned that "association between stations works better". Can you elaborate that? ---- Chun-Yeow On Tue, Jan 27, 2015 at 11:49 PM, Ben Greear <greearb@candelatech.com> wrote: > > > On 01/27/2015 05:55 AM, Sylvain ROGER RIEUNIER wrote: >> >> Dear Michal, >> >> I have already tried the CT firmware. Association between stations >> works better, But the rate control update is still broken. >> It does not work in HT mode. > > > Rate-ctrl is not a problem with the firmware....some users have reported > 700Mbps or so in IBSS mode with my firmware. > > I haven't managed to get kernel and supplicant properly patched for all > this yet..but will get it done eventually (and patches should make it up > stream sometime soon too I think). > > Thanks, > Ben > > >> >> >> Sylvain >> >> 2015-01-27 14:18 GMT+01:00 Michal Kazior <michal.kazior@tieto.com>: >>> >>> On 27 January 2015 at 14:08, Sylvain ROGER RIEUNIER >>> <sylvain.roger.rieunier@gmail.com> wrote: >>>> >>>> I just made some tests with the ath10k driver in IBSS mode and I found >>>> several problems: >>>> >>>> 1) TSF management can't be done correctly. You can't make GET, SET or >>>> RESET actions, because no command is sent to the firmware. However the >>>> WMI_RTT_TSF_CMDID command exists. I tried some changes (see patch), >>>> but they did not produce any effect. >>> >>> >>> This isn't implemented in firmware 636 as far as I know. >>> >>> >>>> 2) Rate control update is not functional in the firmware. Data rate is >>>> stuck at 25 Mbit/s between an ath10k IBSS station and an ath9k IBSS >>>> station. However the rate control update works fine in mac80211 (I >>>> checked it thanks to IBSS debug msg) and IE HT settings are correctly >>>> transmitted on both side (I checked it using a third interface in >>>> monitor mode). The ath10k_wmi_peer_assoc command does not seem to work >>>> for reassoc state to update data rate. >>> >>> >>> Janusz has done some patches related to the hw rate control issues >>> with IBSS recently: >>> >>> >>> https://github.com/kvalo/ath/commit/627d9841eaa623e34657af7af0e6293805e07888 >>> >>> https://github.com/kvalo/ath/commit/55884c045d31a29cf69db8332d1064a1b61dd159 >>> >>> >>>> Conclusion: the firmware seems incomplete for IBSS mode operation. Is >>>> there any planned development on the IBSS mode in the firmware? >>>> >>>> Note: I did my tests with the firmware-2.bin_999.999.0.636 firmware. >>> >>> >>> Ben has recently added IBSS support for his 10.1 firmware fork: >>> >>> >>> http://thread.gmane.org/gmane.linux.drivers.ath10k.devel/1023/focus=1026 >>> >>> You might be interested in giving it a try. >>> >>> >>> Micha? >> >> >> _______________________________________________ >> ath10k mailing list >> ath10k@lists.infradead.org >> http://lists.infradead.org/mailman/listinfo/ath10k >> > > -- > Ben Greear <greearb@candelatech.com> > Candela Technologies Inc http://www.candelatech.com > > > _______________________________________________ > ath10k mailing list > ath10k@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/ath10k
With the main firmware, when starting 2 Ath10k stations, the stations have different BSSID. The merge is not happening correctly. This is due to a bad scan and a Bad TSF management. With CT Firmware The stations split didn't happen. Sylvain 2015-01-28 3:06 GMT+01:00 Yeoh Chun-Yeow <yeohchunyeow@gmail.com>: > For the rate control issue, please make sure that sta->sta.wme = true in ibss.c > > Refer the following: > http://lists.infradead.org/pipermail/ath10k/2014-December/003982.html > > For CT firmware, you have mentioned that "association between stations > works better". Can you elaborate that? > > ---- > Chun-Yeow > > On Tue, Jan 27, 2015 at 11:49 PM, Ben Greear <greearb@candelatech.com> wrote: >> >> >> On 01/27/2015 05:55 AM, Sylvain ROGER RIEUNIER wrote: >>> >>> Dear Michal, >>> >>> I have already tried the CT firmware. Association between stations >>> works better, But the rate control update is still broken. >>> It does not work in HT mode. >> >> >> Rate-ctrl is not a problem with the firmware....some users have reported >> 700Mbps or so in IBSS mode with my firmware. >> >> I haven't managed to get kernel and supplicant properly patched for all >> this yet..but will get it done eventually (and patches should make it up >> stream sometime soon too I think). >> >> Thanks, >> Ben >> >> >>> >>> >>> Sylvain >>> >>> 2015-01-27 14:18 GMT+01:00 Michal Kazior <michal.kazior@tieto.com>: >>>> >>>> On 27 January 2015 at 14:08, Sylvain ROGER RIEUNIER >>>> <sylvain.roger.rieunier@gmail.com> wrote: >>>>> >>>>> I just made some tests with the ath10k driver in IBSS mode and I found >>>>> several problems: >>>>> >>>>> 1) TSF management can't be done correctly. You can't make GET, SET or >>>>> RESET actions, because no command is sent to the firmware. However the >>>>> WMI_RTT_TSF_CMDID command exists. I tried some changes (see patch), >>>>> but they did not produce any effect. >>>> >>>> >>>> This isn't implemented in firmware 636 as far as I know. >>>> >>>> >>>>> 2) Rate control update is not functional in the firmware. Data rate is >>>>> stuck at 25 Mbit/s between an ath10k IBSS station and an ath9k IBSS >>>>> station. However the rate control update works fine in mac80211 (I >>>>> checked it thanks to IBSS debug msg) and IE HT settings are correctly >>>>> transmitted on both side (I checked it using a third interface in >>>>> monitor mode). The ath10k_wmi_peer_assoc command does not seem to work >>>>> for reassoc state to update data rate. >>>> >>>> >>>> Janusz has done some patches related to the hw rate control issues >>>> with IBSS recently: >>>> >>>> >>>> https://github.com/kvalo/ath/commit/627d9841eaa623e34657af7af0e6293805e07888 >>>> >>>> https://github.com/kvalo/ath/commit/55884c045d31a29cf69db8332d1064a1b61dd159 >>>> >>>> >>>>> Conclusion: the firmware seems incomplete for IBSS mode operation. Is >>>>> there any planned development on the IBSS mode in the firmware? >>>>> >>>>> Note: I did my tests with the firmware-2.bin_999.999.0.636 firmware. >>>> >>>> >>>> Ben has recently added IBSS support for his 10.1 firmware fork: >>>> >>>> >>>> http://thread.gmane.org/gmane.linux.drivers.ath10k.devel/1023/focus=1026 >>>> >>>> You might be interested in giving it a try. >>>> >>>> >>>> Micha? >>> >>> >>> _______________________________________________ >>> ath10k mailing list >>> ath10k@lists.infradead.org >>> http://lists.infradead.org/mailman/listinfo/ath10k >>> >> >> -- >> Ben Greear <greearb@candelatech.com> >> Candela Technologies Inc http://www.candelatech.com >> >> >> _______________________________________________ >> ath10k mailing list >> ath10k@lists.infradead.org >> http://lists.infradead.org/mailman/listinfo/ath10k
Hi, Sylvain Are you using the driver from https://github.com/kvalo/ath? Maybe there are patches missing. --- Chun-Yeow On Wed, Jan 28, 2015 at 4:34 PM, Sylvain ROGER RIEUNIER <sylvain.roger.rieunier@gmail.com> wrote: > With the main firmware, when starting 2 Ath10k stations, the stations > have different BSSID. The merge is not happening correctly. This is > due to a bad scan and a Bad TSF management. > With CT Firmware The stations split didn't happen. > > Sylvain > > 2015-01-28 3:06 GMT+01:00 Yeoh Chun-Yeow <yeohchunyeow@gmail.com>: >> For the rate control issue, please make sure that sta->sta.wme = true in ibss.c >> >> Refer the following: >> http://lists.infradead.org/pipermail/ath10k/2014-December/003982.html >> >> For CT firmware, you have mentioned that "association between stations >> works better". Can you elaborate that? >> >> ---- >> Chun-Yeow >> >> On Tue, Jan 27, 2015 at 11:49 PM, Ben Greear <greearb@candelatech.com> wrote: >>> >>> >>> On 01/27/2015 05:55 AM, Sylvain ROGER RIEUNIER wrote: >>>> >>>> Dear Michal, >>>> >>>> I have already tried the CT firmware. Association between stations >>>> works better, But the rate control update is still broken. >>>> It does not work in HT mode. >>> >>> >>> Rate-ctrl is not a problem with the firmware....some users have reported >>> 700Mbps or so in IBSS mode with my firmware. >>> >>> I haven't managed to get kernel and supplicant properly patched for all >>> this yet..but will get it done eventually (and patches should make it up >>> stream sometime soon too I think). >>> >>> Thanks, >>> Ben >>> >>> >>>> >>>> >>>> Sylvain >>>> >>>> 2015-01-27 14:18 GMT+01:00 Michal Kazior <michal.kazior@tieto.com>: >>>>> >>>>> On 27 January 2015 at 14:08, Sylvain ROGER RIEUNIER >>>>> <sylvain.roger.rieunier@gmail.com> wrote: >>>>>> >>>>>> I just made some tests with the ath10k driver in IBSS mode and I found >>>>>> several problems: >>>>>> >>>>>> 1) TSF management can't be done correctly. You can't make GET, SET or >>>>>> RESET actions, because no command is sent to the firmware. However the >>>>>> WMI_RTT_TSF_CMDID command exists. I tried some changes (see patch), >>>>>> but they did not produce any effect. >>>>> >>>>> >>>>> This isn't implemented in firmware 636 as far as I know. >>>>> >>>>> >>>>>> 2) Rate control update is not functional in the firmware. Data rate is >>>>>> stuck at 25 Mbit/s between an ath10k IBSS station and an ath9k IBSS >>>>>> station. However the rate control update works fine in mac80211 (I >>>>>> checked it thanks to IBSS debug msg) and IE HT settings are correctly >>>>>> transmitted on both side (I checked it using a third interface in >>>>>> monitor mode). The ath10k_wmi_peer_assoc command does not seem to work >>>>>> for reassoc state to update data rate. >>>>> >>>>> >>>>> Janusz has done some patches related to the hw rate control issues >>>>> with IBSS recently: >>>>> >>>>> >>>>> https://github.com/kvalo/ath/commit/627d9841eaa623e34657af7af0e6293805e07888 >>>>> >>>>> https://github.com/kvalo/ath/commit/55884c045d31a29cf69db8332d1064a1b61dd159 >>>>> >>>>> >>>>>> Conclusion: the firmware seems incomplete for IBSS mode operation. Is >>>>>> there any planned development on the IBSS mode in the firmware? >>>>>> >>>>>> Note: I did my tests with the firmware-2.bin_999.999.0.636 firmware. >>>>> >>>>> >>>>> Ben has recently added IBSS support for his 10.1 firmware fork: >>>>> >>>>> >>>>> http://thread.gmane.org/gmane.linux.drivers.ath10k.devel/1023/focus=1026 >>>>> >>>>> You might be interested in giving it a try. >>>>> >>>>> >>>>> Micha? >>>> >>>> >>>> _______________________________________________ >>>> ath10k mailing list >>>> ath10k@lists.infradead.org >>>> http://lists.infradead.org/mailman/listinfo/ath10k >>>> >>> >>> -- >>> Ben Greear <greearb@candelatech.com> >>> Candela Technologies Inc http://www.candelatech.com >>> >>> >>> _______________________________________________ >>> ath10k mailing list >>> ath10k@lists.infradead.org >>> http://lists.infradead.org/mailman/listinfo/ath10k
--- a/drivers/net/wireless/ath/ath10k/mac.c +++ b/drivers/net/wireless/ath/ath10k/mac.c @@ -4467,6 +4467,13 @@ static void ath10k_sta_rc_update(struct static u64 ath10k_get_tsf(struct ieee80211_hw *hw, struct ieee80211_vif *vif) { + struct ath10k *ar = hw->priv; + struct ath10k_vif *arvif = ath10k_vif_to_arvif(vif); + + mutex_lock(&ar->conf_mutex); + ath10k_wmi_get_tsf( ar, arvif->vdev_id, arvif->vif->addr); + mutex_unlock(&ar->conf_mutex); + /* * FIXME: Return 0 for time being. Need to figure out whether FW * has the API to fetch 64-bit local TSF @@ -4475,6 +4482,27 @@ static u64 ath10k_get_tsf(struct ieee802 return 0; } +static void ath10k_set_tsf(struct ieee80211_hw *hw, struct ieee80211_vif *vif, + u64 tsf) +{ + struct ath10k *ar = hw->priv; + struct ath10k_vif *arvif = ath10k_vif_to_arvif(vif); + + mutex_lock(&ar->conf_mutex); + ath10k_wmi_set_tsf( ar, arvif->vdev_id, arvif->vif->addr, tsf); + mutex_unlock(&ar->conf_mutex); +} + +static void ath10k_reset_tsf(struct ieee80211_hw *hw, struct ieee80211_vif *vif) +{ + struct ath10k *ar = hw->priv; + struct ath10k_vif *arvif = ath10k_vif_to_arvif(vif); + + mutex_lock(&ar->conf_mutex); + ath10k_wmi_reset_tsf( ar, arvif->vdev_id, arvif->vif->addr); + mutex_unlock(&ar->conf_mutex); +} + static int ath10k_ampdu_action(struct ieee80211_hw *hw, struct ieee80211_vif *vif, enum ieee80211_ampdu_mlme_action action, @@ -4535,6 +4563,8 @@ static const struct ieee80211_ops ath10k .set_bitrate_mask = ath10k_set_bitrate_mask, .sta_rc_update = ath10k_sta_rc_update, .get_tsf = ath10k_get_tsf, + .reset_tsf = ath10k_reset_tsf, + .set_tsf = ath10k_set_tsf, .ampdu_action = ath10k_ampdu_action, .get_et_sset_count = ath10k_debug_get_et_sset_count, .get_et_stats = ath10k_debug_get_et_stats, --- a/drivers/net/wireless/ath/ath10k/wmi.c +++ b/drivers/net/wireless/ath/ath10k/wmi.c @@ -1322,9 +1322,17 @@ static void ath10k_wmi_event_echo(struct static int ath10k_wmi_event_debug_mesg(struct ath10k *ar, struct sk_buff *skb) { + int i; + ath10k_dbg(ar, ATH10K_DBG_WMI, "wmi event debug mesg len %d\n", skb->len); + ath10k_dbg(ar, ATH10K_DBG_WMI, "wmi event data :"); + for (i = 4; i < skb->len; i++) { + ath10k_dbg(ar, ATH10K_DBG_WMI, " %x", skb->data[i]); + } + ath10k_dbg(ar, ATH10K_DBG_WMI, "\n"); + trace_ath10k_wmi_dbglog(ar, skb->data, skb->len); return 0; @@ -4417,3 +4425,64 @@ void ath10k_wmi_detach(struct ath10k *ar ar->wmi.num_mem_chunks = 0; } + +int ath10k_wmi_set_tsf(struct ath10k *ar, u32 vdev_id, const u8 *mac, u64 tsf) +{ + struct sk_buff *skb; + struct wmi_rtt_tsf_cmd *cmd; + + skb = ath10k_wmi_alloc_skb(ar, sizeof(*cmd)); + if (!skb) + return -ENOMEM; + + ath10k_dbg(ar, ATH10K_DBG_WMI, "wmi SET TSF %Lu\n", tsf); + cmd = (struct wmi_rtt_tsf_cmd *) skb->data; + cmd->vdev_id = __cpu_to_le32(vdev_id); + cmd->cmd = WMI_TSF_FW_SET; + cmd->tsf_u32 = cpu_to_le32(tsf >> 32); + cmd->tsf_l32 = cpu_to_le32(tsf & 0xffffffff); + + ath10k_dbg(ar, ATH10K_DBG_WMI, "wmi SET TSF %u(l) %u(u)\n", + cmd->tsf_l32, cmd->tsf_u32); + + return ath10k_wmi_cmd_send(ar, skb, + ar->wmi.cmd->rtt_tsf_cmdid); +} + +int ath10k_wmi_reset_tsf(struct ath10k *ar, u32 vdev_id, const u8 *mac) +{ + struct sk_buff *skb; + struct wmi_rtt_tsf_cmd *cmd; + + skb = ath10k_wmi_alloc_skb(ar, sizeof(*cmd)); + if (!skb) + return -ENOMEM; + + ath10k_dbg(ar, ATH10K_DBG_WMI, "wmi RESET TSF \n"); + cmd = (struct wmi_rtt_tsf_cmd *) skb->data; + cmd->vdev_id = __cpu_to_le32(vdev_id); + cmd->cmd = WMI_TSF_FW_RESET; + cmd->tsf_u32 = 0; + cmd->tsf_l32 = 0; + + return ath10k_wmi_cmd_send(ar, skb, + ar->wmi.cmd->rtt_tsf_cmdid); +} + +int ath10k_wmi_get_tsf(struct ath10k *ar, u32 vdev_id, const u8 *mac) +{ + struct sk_buff *skb; + struct wmi_rtt_measreq_cmd *cmd; + + skb = ath10k_wmi_alloc_skb(ar, sizeof(*cmd)); + if (!skb) + return -ENOMEM; + + ath10k_dbg(ar, ATH10K_DBG_WMI, "wmi GET TSF\n"); + cmd = (struct wmi_rtt_measreq_cmd *) skb->data; + cmd->vdev_id = __cpu_to_le32(vdev_id); + cmd->cmd = WMI_RTT_FW_TSF; + + return ath10k_wmi_cmd_send(ar, skb, + ar->wmi.cmd->rtt_measreq_cmdid); +} --- a/drivers/net/wireless/ath/ath10k/wmi.h +++ b/drivers/net/wireless/ath/ath10k/wmi.h @@ -4547,6 +4547,32 @@ struct wmi_dbglog_cfg_cmd { __le32 config_valid; } __packed; + +enum wmi_rtt_fw_cmd { + WMI_RTT_FW_RTT = 1, + WMI_RTT_FW_TSF = 2, +}; + +struct wmi_rtt_measreq_cmd { + __le32 vdev_id; + __le32 cmd; +// struct wmi_mac_addr macaddr; +} __packed; + +enum wmi_tsf_fw_cmd { + WMI_TSF_FW_RESET = 1, + WMI_TSF_FW_SET = 2, + WMI_TSF_FW_GET = 3, +}; + +struct wmi_rtt_tsf_cmd { + __le32 vdev_id; + __le32 cmd; + __le32 tsf_l32; + __le32 tsf_u32; +} __packed; + + #define ATH10K_RTS_MAX 2347 #define ATH10K_FRAGMT_THRESHOLD_MIN 540 #define ATH10K_FRAGMT_THRESHOLD_MAX 2346 @@ -4653,5 +4679,8 @@ int ath10k_wmi_pull_fw_stats(struct ath1 struct ath10k_fw_stats *stats); int ath10k_wmi_pdev_pktlog_enable(struct ath10k *ar, u32 ev_list); int ath10k_wmi_pdev_pktlog_disable(struct ath10k *ar); +int ath10k_wmi_set_tsf(struct ath10k *ar, u32 vdev_id, const u8 *mac, u64 tsf); +int ath10k_wmi_reset_tsf(struct ath10k *ar, u32 vdev_id, const u8 *mac); +int ath10k_wmi_get_tsf(struct ath10k *ar, u32 vdev_id, const u8 *mac); #endif /* _WMI_H_ */