Check and set Rx MAC timestamp when firmware indicates it.
Firmware adds it in Rx beacon frame only at this moment.
Driver and mac80211 may utilize it to detect such clockdrift
or beacon collision and use the result for beacon collision
avoidance.
Signed-off-by: Peter Oh <[email protected]>
---
v2:
- fix kbuild test robot warning, left shift count >= width of type,
at __le32_to_cpu(arg.ext_info.rx_mac_timestamp_u32) << 32
v3:
- correct ext_info to start 4-byte aligned
- make struct wmi_mgmt_rx_ext_info 4-byte aligned to comply FW's intention
v4:
- fix endianness warnings, restricted __le32 degrades to integer
v5:
- use ALIGN for better read
drivers/net/wireless/ath/ath10k/wmi.c | 15 +++++++++++++++
drivers/net/wireless/ath/ath10k/wmi.h | 8 ++++++++
2 files changed, 23 insertions(+)
diff --git a/drivers/net/wireless/ath/ath10k/wmi.c b/drivers/net/wireless/ath/ath10k/wmi.c
index 1ce6742..a343e74 100644
--- a/drivers/net/wireless/ath/ath10k/wmi.c
+++ b/drivers/net/wireless/ath/ath10k/wmi.c
@@ -2167,8 +2167,10 @@ static int ath10k_wmi_op_pull_mgmt_rx_ev(struct ath10k *ar, struct sk_buff *skb,
struct wmi_mgmt_rx_event_v1 *ev_v1;
struct wmi_mgmt_rx_event_v2 *ev_v2;
struct wmi_mgmt_rx_hdr_v1 *ev_hdr;
+ struct wmi_mgmt_rx_ext_info *ext_info;
size_t pull_len;
u32 msdu_len;
+ u32 len;
if (test_bit(ATH10K_FW_FEATURE_EXT_WMI_MGMT_RX, ar->fw_features)) {
ev_v2 = (struct wmi_mgmt_rx_event_v2 *)skb->data;
@@ -2195,6 +2197,12 @@ static int ath10k_wmi_op_pull_mgmt_rx_ev(struct ath10k *ar, struct sk_buff *skb,
if (skb->len < msdu_len)
return -EPROTO;
+ if (le32_to_cpu(arg->status) & WMI_RX_STATUS_EXT_INFO) {
+ len = ALIGN(le32_to_cpu(arg->buf_len), 4);
+ ext_info = (struct wmi_mgmt_rx_ext_info *)(skb->data + len);
+ memcpy(&arg->ext_info, ext_info,
+ sizeof(struct wmi_mgmt_rx_ext_info));
+ }
/* the WMI buffer might've ended up being padded to 4 bytes due to HTC
* trailer with credit update. Trim the excess garbage.
*/
@@ -2281,6 +2289,13 @@ int ath10k_wmi_event_mgmt_rx(struct ath10k *ar, struct sk_buff *skb)
if (rx_status & WMI_RX_STATUS_ERR_MIC)
status->flag |= RX_FLAG_MMIC_ERROR;
+ if (rx_status & WMI_RX_STATUS_EXT_INFO) {
+ status->mactime =
+ __le32_to_cpu(arg.ext_info.rx_mac_timestamp_l32) |
+ (u64)__le32_to_cpu(arg.ext_info.rx_mac_timestamp_u32)
+ << 32;
+ status->flag |= RX_FLAG_MACTIME_END;
+ }
/* Hardware can Rx CCK rates on 5GHz. In that case phy_mode is set to
* MODE_11B. This means phy_mode is not a reliable source for the band
* of mgmt rx.
diff --git a/drivers/net/wireless/ath/ath10k/wmi.h b/drivers/net/wireless/ath/ath10k/wmi.h
index 4d3cbc4..f209d51 100644
--- a/drivers/net/wireless/ath/ath10k/wmi.h
+++ b/drivers/net/wireless/ath/ath10k/wmi.h
@@ -3037,11 +3037,18 @@ struct wmi_10_4_mgmt_rx_event {
u8 buf[0];
} __packed;
+struct wmi_mgmt_rx_ext_info {
+ __le32 rx_mac_timestamp_l32;
+ __le32 rx_mac_timestamp_u32;
+} __packed __aligned(4);
+
#define WMI_RX_STATUS_OK 0x00
#define WMI_RX_STATUS_ERR_CRC 0x01
#define WMI_RX_STATUS_ERR_DECRYPT 0x08
#define WMI_RX_STATUS_ERR_MIC 0x10
#define WMI_RX_STATUS_ERR_KEY_CACHE_MISS 0x20
+/* Extension data at the end of mgmt frame */
+#define WMI_RX_STATUS_EXT_INFO 0x40
#define PHY_ERROR_GEN_SPECTRAL_SCAN 0x26
#define PHY_ERROR_GEN_FALSE_RADAR_EXT 0x24
@@ -6116,6 +6123,7 @@ struct wmi_mgmt_rx_ev_arg {
__le32 phy_mode;
__le32 buf_len;
__le32 status; /* %WMI_RX_STATUS_ */
+ struct wmi_mgmt_rx_ext_info ext_info;
};
struct wmi_ch_info_ev_arg {
--
1.9.1
On 26 February 2016 at 20:03, Peter Oh <[email protected]> wrote:
> Check and set Rx MAC timestamp when firmware indicates it.
> Firmware adds it in Rx beacon frame only at this moment.
> Driver and mac80211 may utilize it to detect such clockdrift
> or beacon collision and use the result for beacon collision
> avoidance.
>
> Signed-off-by: Peter Oh <[email protected]>
> ---
[...]
> + if (rx_status & WMI_RX_STATUS_EXT_INFO) {
> + status->mactime =
> + __le32_to_cpu(arg.ext_info.rx_mac_timestamp_l32) |
> + (u64)__le32_to_cpu(arg.ext_info.rx_mac_timestamp_u32)
> + << 32;
> + status->flag |= RX_FLAG_MACTIME_END;
> + }
> /* Hardware can Rx CCK rates on 5GHz. In that case phy_mode is set to
> * MODE_11B. This means phy_mode is not a reliable source for the band
> * of mgmt rx.
> diff --git a/drivers/net/wireless/ath/ath10k/wmi.h b/drivers/net/wireless/ath/ath10k/wmi.h
> index 4d3cbc4..f209d51 100644
> --- a/drivers/net/wireless/ath/ath10k/wmi.h
> +++ b/drivers/net/wireless/ath/ath10k/wmi.h
> @@ -3037,11 +3037,18 @@ struct wmi_10_4_mgmt_rx_event {
> u8 buf[0];
> } __packed;
>
> +struct wmi_mgmt_rx_ext_info {
> + __le32 rx_mac_timestamp_l32;
> + __le32 rx_mac_timestamp_u32;
Oh.. I feel bad for noticing this so late. I think this can be
represented with a mere __le64 and then accessed via le64_to_cpu().
Michał
On 02/29/2016 10:33 AM, Michal Kazior wrote:
> On 26 February 2016 at 20:03, Peter Oh <[email protected]> wrote:
>> Check and set Rx MAC timestamp when firmware indicates it.
>> Firmware adds it in Rx beacon frame only at this moment.
>> Driver and mac80211 may utilize it to detect such clockdrift
>> or beacon collision and use the result for beacon collision
>> avoidance.
>>
>> Signed-off-by: Peter Oh <[email protected]>
>> ---
> [...]
>> + if (rx_status & WMI_RX_STATUS_EXT_INFO) {
>> + status->mactime =
>> + __le32_to_cpu(arg.ext_info.rx_mac_timestamp_l32) |
>> +
>> (u64)__le32_to_cpu(arg.ext_info.rx_mac_timestamp_u32)
>> + << 32;
>> + status->flag |= RX_FLAG_MACTIME_END;
>> + }
>> /* Hardware can Rx CCK rates on 5GHz. In that case phy_mode is set
>> to
>> * MODE_11B. This means phy_mode is not a reliable source for the
>> band
>> * of mgmt rx.
>> diff --git a/drivers/net/wireless/ath/ath10k/wmi.h
>> b/drivers/net/wireless/ath/ath10k/wmi.h
>> index 4d3cbc4..f209d51 100644
>> --- a/drivers/net/wireless/ath/ath10k/wmi.h
>> +++ b/drivers/net/wireless/ath/ath10k/wmi.h
>> @@ -3037,11 +3037,18 @@ struct wmi_10_4_mgmt_rx_event {
>> u8 buf[0];
>> } __packed;
>>
>> +struct wmi_mgmt_rx_ext_info {
>> + __le32 rx_mac_timestamp_l32;
>> + __le32 rx_mac_timestamp_u32;
> Oh.. I feel bad for noticing this so late.
review is always appreciated.
> I think this can be
> represented with a mere __le64 and then accessed via le64_to_cpu().
sent new patch based on your comment.
Thanks,
Peter