* [PATCH 1/2] ath10k: add per peer htt tx stats support for 10.4
From: akolli @ 2016-10-18 9:29 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless, akolli, Anilkumar Kolli
In-Reply-To: <1476782982-10683-1-git-send-email-akolli@qti.qualcomm.com>
From: Anilkumar Kolli <akolli@qti.qualcomm.com>
Per peer tx stats are part of 'HTT_10_4_T2H_MSG_TYPE_PEER_STATS'
event, Firmware sends one HTT event for every four PPDUs.
HTT payload has success pkts/bytes, failed pkts/bytes, retry
pkts/bytes and rate info per ppdu.
Peer stats are enabled through 'WMI_SERVICE_PEER_STATS',
which are nowadays enabled by default.
Parse peer stats and update the tx rate information per STA.
tx rate, Peer stats are tested on QCA4019 with Firmware version
10.4-3.2.1-00028.
Signed-off-by: Anilkumar Kolli <akolli@qti.qualcomm.com>
---
v2:
* address Kalle's comments
* fix compilation warnings
drivers/net/wireless/ath/ath10k/core.h | 17 ++++
drivers/net/wireless/ath/ath10k/htt.c | 2 +
drivers/net/wireless/ath/ath10k/htt.h | 25 ++++++
drivers/net/wireless/ath/ath10k/htt_rx.c | 125 ++++++++++++++++++++++++++++++
drivers/net/wireless/ath/ath10k/wmi.h | 10 ++-
5 files changed, 178 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/ath10k/core.h b/drivers/net/wireless/ath/ath10k/core.h
index dda49af1eb74..fc3d3bded265 100644
--- a/drivers/net/wireless/ath/ath10k/core.h
+++ b/drivers/net/wireless/ath/ath10k/core.h
@@ -337,6 +337,7 @@ struct ath10k_sta {
u32 nss;
u32 smps;
u16 peer_id;
+ struct rate_info txrate;
struct work_struct update_wk;
@@ -694,6 +695,21 @@ struct ath10k_fw_components {
struct ath10k_fw_file fw_file;
};
+struct ath10k_per_peer_tx_stats {
+ u32 succ_bytes;
+ u32 retry_bytes;
+ u32 failed_bytes;
+ u8 ratecode;
+ u8 flags;
+ u16 peer_id;
+ u16 succ_pkts;
+ u16 retry_pkts;
+ u16 failed_pkts;
+ u16 duration;
+ u32 reserved1;
+ u32 reserved2;
+};
+
struct ath10k {
struct ath_common ath_common;
struct ieee80211_hw *hw;
@@ -906,6 +922,7 @@ struct ath10k {
struct ath10k_thermal thermal;
struct ath10k_wow wow;
+ struct ath10k_per_peer_tx_stats peer_tx_stats;
/* NAPI */
struct net_device napi_dev;
diff --git a/drivers/net/wireless/ath/ath10k/htt.c b/drivers/net/wireless/ath/ath10k/htt.c
index 130cd9502021..cd160b16db1e 100644
--- a/drivers/net/wireless/ath/ath10k/htt.c
+++ b/drivers/net/wireless/ath/ath10k/htt.c
@@ -137,6 +137,8 @@ static const enum htt_t2h_msg_type htt_10_4_t2h_msg_types[] = {
HTT_T2H_MSG_TYPE_STATS_NOUPLOAD,
[HTT_10_4_T2H_MSG_TYPE_TX_MODE_SWITCH_IND] =
HTT_T2H_MSG_TYPE_TX_MODE_SWITCH_IND,
+ [HTT_10_4_T2H_MSG_TYPE_PEER_STATS] =
+ HTT_T2H_MSG_TYPE_PEER_STATS,
};
int ath10k_htt_connect(struct ath10k_htt *htt)
diff --git a/drivers/net/wireless/ath/ath10k/htt.h b/drivers/net/wireless/ath/ath10k/htt.h
index 0d2ed09f202b..164eb3a10566 100644
--- a/drivers/net/wireless/ath/ath10k/htt.h
+++ b/drivers/net/wireless/ath/ath10k/htt.h
@@ -419,6 +419,7 @@ enum htt_10_4_t2h_msg_type {
HTT_10_4_T2H_MSG_TYPE_STATS_NOUPLOAD = 0x18,
/* 0x19 to 0x2f are reserved */
HTT_10_4_T2H_MSG_TYPE_TX_MODE_SWITCH_IND = 0x30,
+ HTT_10_4_T2H_MSG_TYPE_PEER_STATS = 0x31,
/* keep this last */
HTT_10_4_T2H_NUM_MSGS
};
@@ -453,6 +454,7 @@ enum htt_t2h_msg_type {
HTT_T2H_MSG_TYPE_TX_FETCH_IND,
HTT_T2H_MSG_TYPE_TX_FETCH_CONFIRM,
HTT_T2H_MSG_TYPE_TX_MODE_SWITCH_IND,
+ HTT_T2H_MSG_TYPE_PEER_STATS,
/* keep this last */
HTT_T2H_NUM_MSGS
};
@@ -1470,6 +1472,28 @@ struct htt_channel_change {
__le32 phymode;
} __packed;
+struct htt_per_peer_tx_stats_ind {
+ __le32 succ_bytes;
+ __le32 retry_bytes;
+ __le32 failed_bytes;
+ u8 ratecode;
+ u8 flags;
+ __le16 peer_id;
+ __le16 succ_pkts;
+ __le16 retry_pkts;
+ __le16 failed_pkts;
+ __le16 tx_duration;
+ __le32 reserved1;
+ __le32 reserved2;
+} __packed;
+
+struct htt_peer_tx_stats {
+ u8 num_ppdu;
+ u8 ppdu_len;
+ u8 version;
+ u8 payload[0];
+} __packed;
+
union htt_rx_pn_t {
/* WEP: 24-bit PN */
u32 pn24;
@@ -1521,6 +1545,7 @@ struct htt_resp {
struct htt_tx_fetch_confirm tx_fetch_confirm;
struct htt_tx_mode_switch_ind tx_mode_switch_ind;
struct htt_channel_change chan_change;
+ struct htt_peer_tx_stats peer_tx_stats;
};
} __packed;
diff --git a/drivers/net/wireless/ath/ath10k/htt_rx.c b/drivers/net/wireless/ath/ath10k/htt_rx.c
index 0b4c1562420f..ef28b358cf5e 100644
--- a/drivers/net/wireless/ath/ath10k/htt_rx.c
+++ b/drivers/net/wireless/ath/ath10k/htt_rx.c
@@ -2194,6 +2194,128 @@ void ath10k_htt_htc_t2h_msg_handler(struct ath10k *ar, struct sk_buff *skb)
dev_kfree_skb_any(skb);
}
+static inline bool is_valid_legacy_rate(u8 rate)
+{
+ static const u8 legacy_rates[] = {1, 2, 5, 11, 6, 9, 12,
+ 18, 24, 36, 48, 54};
+ int i;
+
+ for (i = 0; i < ARRAY_SIZE(legacy_rates); i++) {
+ if (rate == legacy_rates[i])
+ return true;
+ }
+
+ return false;
+}
+
+static void
+ath10k_update_per_peer_tx_stats(struct ath10k *ar,
+ struct ieee80211_sta *sta,
+ struct ath10k_per_peer_tx_stats *peer_stats)
+{
+ struct ath10k_sta *arsta = (struct ath10k_sta *)sta->drv_priv;
+ u8 rate = 0, sgi;
+ struct rate_info txrate;
+
+ lockdep_assert_held(&ar->data_lock);
+
+ txrate.flags = ATH10K_HW_PREAMBLE(peer_stats->ratecode);
+ txrate.bw = ATH10K_HW_BW(peer_stats->flags);
+ txrate.nss = ATH10K_HW_NSS(peer_stats->ratecode);
+ txrate.mcs = ATH10K_HW_MCS_RATE(peer_stats->ratecode);
+ sgi = ATH10K_HW_GI(peer_stats->flags);
+
+ if (((txrate.flags == WMI_RATE_PREAMBLE_HT) ||
+ (txrate.flags == WMI_RATE_PREAMBLE_VHT)) && txrate.mcs > 9) {
+ ath10k_warn(ar, "Invalid mcs %hhd peer stats", txrate.mcs);
+ return;
+ }
+
+ if (txrate.flags == WMI_RATE_PREAMBLE_CCK ||
+ txrate.flags == WMI_RATE_PREAMBLE_OFDM) {
+ rate = ATH10K_HW_LEGACY_RATE(peer_stats->ratecode);
+
+ if (!is_valid_legacy_rate(rate)) {
+ ath10k_warn(ar, "Invalid legacy rate %hhd peer stats",
+ rate);
+ return;
+ }
+
+ /* This is hacky, FW sends CCK rate 5.5Mbps as 6 */
+ rate *= 10;
+ if (rate == 60 && txrate.flags == WMI_RATE_PREAMBLE_CCK)
+ rate = rate - 5;
+ arsta->txrate.legacy = rate * 10;
+ } else if (txrate.flags == WMI_RATE_PREAMBLE_HT) {
+ arsta->txrate.flags = RATE_INFO_FLAGS_MCS;
+ arsta->txrate.mcs = txrate.mcs;
+ } else {
+ arsta->txrate.flags = RATE_INFO_FLAGS_VHT_MCS;
+ arsta->txrate.mcs = txrate.mcs;
+ }
+
+ if (sgi)
+ arsta->txrate.flags |= RATE_INFO_FLAGS_SHORT_GI;
+
+ arsta->txrate.nss = txrate.nss;
+ arsta->txrate.bw = txrate.bw + RATE_INFO_BW_20;
+}
+
+static void ath10k_htt_fetch_peer_stats(struct ath10k *ar,
+ struct sk_buff *skb)
+{
+ struct htt_resp *resp = (struct htt_resp *)skb->data;
+ struct ath10k_per_peer_tx_stats *p_tx_stats = &ar->peer_tx_stats;
+ struct htt_per_peer_tx_stats_ind *tx_stats;
+ struct ieee80211_sta *sta;
+ struct ath10k_peer *peer;
+ int peer_id, i;
+ u8 ppdu_len, num_ppdu;
+
+ num_ppdu = resp->peer_tx_stats.num_ppdu;
+ ppdu_len = resp->peer_tx_stats.ppdu_len * sizeof(__le32);
+
+ if (skb->len < sizeof(struct htt_resp_hdr) + num_ppdu * ppdu_len) {
+ ath10k_warn(ar, "Invalid peer stats buf length %d\n", skb->len);
+ return;
+ }
+
+ tx_stats = (struct htt_per_peer_tx_stats_ind *)
+ (resp->peer_tx_stats.payload);
+ peer_id = tx_stats->peer_id;
+
+ rcu_read_lock();
+ spin_lock_bh(&ar->data_lock);
+ peer = ath10k_peer_find_by_id(ar, peer_id);
+ if (!peer) {
+ ath10k_warn(ar, "Invalid peer id %d peer stats buffer\n",
+ peer_id);
+ goto out;
+ }
+
+ sta = peer->sta;
+ for (i = 0; i < num_ppdu; i++) {
+ tx_stats = (struct htt_per_peer_tx_stats_ind *)
+ (resp->peer_tx_stats.payload + i * ppdu_len);
+
+ p_tx_stats->succ_bytes = __le32_to_cpu(tx_stats->succ_bytes);
+ p_tx_stats->retry_bytes = __le32_to_cpu(tx_stats->retry_bytes);
+ p_tx_stats->failed_bytes =
+ __le32_to_cpu(tx_stats->failed_bytes);
+ p_tx_stats->ratecode = tx_stats->ratecode;
+ p_tx_stats->flags = tx_stats->flags;
+ p_tx_stats->succ_pkts = __le16_to_cpu(tx_stats->succ_pkts);
+ p_tx_stats->retry_pkts = __le16_to_cpu(tx_stats->retry_pkts);
+ p_tx_stats->failed_pkts = __le16_to_cpu(tx_stats->failed_pkts);
+
+ ath10k_update_per_peer_tx_stats(ar, sta, p_tx_stats);
+ }
+
+out:
+ spin_unlock_bh(&ar->data_lock);
+ rcu_read_unlock();
+}
+
bool ath10k_htt_t2h_msg_handler(struct ath10k *ar, struct sk_buff *skb)
{
struct ath10k_htt *htt = &ar->htt;
@@ -2354,6 +2476,9 @@ bool ath10k_htt_t2h_msg_handler(struct ath10k *ar, struct sk_buff *skb)
case HTT_T2H_MSG_TYPE_TX_MODE_SWITCH_IND:
ath10k_htt_rx_tx_mode_switch_ind(ar, skb);
break;
+ case HTT_T2H_MSG_TYPE_PEER_STATS:
+ ath10k_htt_fetch_peer_stats(ar, skb);
+ break;
case HTT_T2H_MSG_TYPE_EN_STATS:
default:
ath10k_warn(ar, "htt event (%d) not handled\n",
diff --git a/drivers/net/wireless/ath/ath10k/wmi.h b/drivers/net/wireless/ath/ath10k/wmi.h
index 1b243c899bef..e108d49998c3 100644
--- a/drivers/net/wireless/ath/ath10k/wmi.h
+++ b/drivers/net/wireless/ath/ath10k/wmi.h
@@ -4603,9 +4603,17 @@ enum wmi_rate_preamble {
#define ATH10K_HW_NSS(rate) (1 + (((rate) >> 4) & 0x3))
#define ATH10K_HW_PREAMBLE(rate) (((rate) >> 6) & 0x3)
-#define ATH10K_HW_RATECODE(rate, nss, preamble) \
+#define ATH10K_HW_MCS_RATE(rate) ((rate) & 0xf)
+#define ATH10K_HW_LEGACY_RATE(rate) ((rate) & 0x3f)
+#define ATH10K_HW_BW(flags) (((flags) >> 3) & 0x3)
+#define ATH10K_HW_GI(flags) (((flags) >> 5) & 0x1)
+#define ATH10K_HW_RATECODE(rate, nss, preamble) \
(((preamble) << 6) | ((nss) << 4) | (rate))
+#define VHT_MCS_NUM 10
+#define VHT_BW_NUM 4
+#define VHT_NSS_NUM 4
+
/* Value to disable fixed rate setting */
#define WMI_FIXED_RATE_NONE (0xff)
--
1.7.9.5
^ permalink raw reply related
* [PATCHv2 0/2] ath10k: add support for tx bitrate
From: akolli @ 2016-10-18 9:31 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless, akolli
From: Anilkumar Kolli <akolli@codeaurora.org>
This patch series adds support for tx bitrate using
.sta_statistics callback.
tx bitrate tested on QCA4019 using iw.
Anilkumar Kolli (2):
ath10k: add per peer htt tx stats support for 10.4
ath10k: add support for per sta tx bitrate
drivers/net/wireless/ath/ath10k/core.h | 17 ++++
drivers/net/wireless/ath/ath10k/debugfs_sta.c | 13 +++
drivers/net/wireless/ath/ath10k/htt.c | 2 +
drivers/net/wireless/ath/ath10k/htt.h | 25 +++++
drivers/net/wireless/ath/ath10k/htt_rx.c | 125 +++++++++++++++++++++++++
drivers/net/wireless/ath/ath10k/wmi.h | 10 +-
6 files changed, 191 insertions(+), 1 deletion(-)
--
1.7.9.5
^ permalink raw reply
* [PATCHv2 1/2] ath10k: add per peer htt tx stats support for 10.4
From: akolli @ 2016-10-18 9:31 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless, akolli, Anilkumar Kolli
In-Reply-To: <1476783085-10724-1-git-send-email-akolli@qti.qualcomm.com>
From: Anilkumar Kolli <akolli@qti.qualcomm.com>
Per peer tx stats are part of 'HTT_10_4_T2H_MSG_TYPE_PEER_STATS'
event, Firmware sends one HTT event for every four PPDUs.
HTT payload has success pkts/bytes, failed pkts/bytes, retry
pkts/bytes and rate info per ppdu.
Peer stats are enabled through 'WMI_SERVICE_PEER_STATS',
which are nowadays enabled by default.
Parse peer stats and update the tx rate information per STA.
tx rate, Peer stats are tested on QCA4019 with Firmware version
10.4-3.2.1-00028.
Signed-off-by: Anilkumar Kolli <akolli@qti.qualcomm.com>
---
v2:
* address Kalle's comments
* fix compilation warnings
drivers/net/wireless/ath/ath10k/core.h | 17 ++++
drivers/net/wireless/ath/ath10k/htt.c | 2 +
drivers/net/wireless/ath/ath10k/htt.h | 25 ++++++
drivers/net/wireless/ath/ath10k/htt_rx.c | 125 ++++++++++++++++++++++++++++++
drivers/net/wireless/ath/ath10k/wmi.h | 10 ++-
5 files changed, 178 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/ath10k/core.h b/drivers/net/wireless/ath/ath10k/core.h
index dda49af1eb74..fc3d3bded265 100644
--- a/drivers/net/wireless/ath/ath10k/core.h
+++ b/drivers/net/wireless/ath/ath10k/core.h
@@ -337,6 +337,7 @@ struct ath10k_sta {
u32 nss;
u32 smps;
u16 peer_id;
+ struct rate_info txrate;
struct work_struct update_wk;
@@ -694,6 +695,21 @@ struct ath10k_fw_components {
struct ath10k_fw_file fw_file;
};
+struct ath10k_per_peer_tx_stats {
+ u32 succ_bytes;
+ u32 retry_bytes;
+ u32 failed_bytes;
+ u8 ratecode;
+ u8 flags;
+ u16 peer_id;
+ u16 succ_pkts;
+ u16 retry_pkts;
+ u16 failed_pkts;
+ u16 duration;
+ u32 reserved1;
+ u32 reserved2;
+};
+
struct ath10k {
struct ath_common ath_common;
struct ieee80211_hw *hw;
@@ -906,6 +922,7 @@ struct ath10k {
struct ath10k_thermal thermal;
struct ath10k_wow wow;
+ struct ath10k_per_peer_tx_stats peer_tx_stats;
/* NAPI */
struct net_device napi_dev;
diff --git a/drivers/net/wireless/ath/ath10k/htt.c b/drivers/net/wireless/ath/ath10k/htt.c
index 130cd9502021..cd160b16db1e 100644
--- a/drivers/net/wireless/ath/ath10k/htt.c
+++ b/drivers/net/wireless/ath/ath10k/htt.c
@@ -137,6 +137,8 @@ static const enum htt_t2h_msg_type htt_10_4_t2h_msg_types[] = {
HTT_T2H_MSG_TYPE_STATS_NOUPLOAD,
[HTT_10_4_T2H_MSG_TYPE_TX_MODE_SWITCH_IND] =
HTT_T2H_MSG_TYPE_TX_MODE_SWITCH_IND,
+ [HTT_10_4_T2H_MSG_TYPE_PEER_STATS] =
+ HTT_T2H_MSG_TYPE_PEER_STATS,
};
int ath10k_htt_connect(struct ath10k_htt *htt)
diff --git a/drivers/net/wireless/ath/ath10k/htt.h b/drivers/net/wireless/ath/ath10k/htt.h
index 0d2ed09f202b..164eb3a10566 100644
--- a/drivers/net/wireless/ath/ath10k/htt.h
+++ b/drivers/net/wireless/ath/ath10k/htt.h
@@ -419,6 +419,7 @@ enum htt_10_4_t2h_msg_type {
HTT_10_4_T2H_MSG_TYPE_STATS_NOUPLOAD = 0x18,
/* 0x19 to 0x2f are reserved */
HTT_10_4_T2H_MSG_TYPE_TX_MODE_SWITCH_IND = 0x30,
+ HTT_10_4_T2H_MSG_TYPE_PEER_STATS = 0x31,
/* keep this last */
HTT_10_4_T2H_NUM_MSGS
};
@@ -453,6 +454,7 @@ enum htt_t2h_msg_type {
HTT_T2H_MSG_TYPE_TX_FETCH_IND,
HTT_T2H_MSG_TYPE_TX_FETCH_CONFIRM,
HTT_T2H_MSG_TYPE_TX_MODE_SWITCH_IND,
+ HTT_T2H_MSG_TYPE_PEER_STATS,
/* keep this last */
HTT_T2H_NUM_MSGS
};
@@ -1470,6 +1472,28 @@ struct htt_channel_change {
__le32 phymode;
} __packed;
+struct htt_per_peer_tx_stats_ind {
+ __le32 succ_bytes;
+ __le32 retry_bytes;
+ __le32 failed_bytes;
+ u8 ratecode;
+ u8 flags;
+ __le16 peer_id;
+ __le16 succ_pkts;
+ __le16 retry_pkts;
+ __le16 failed_pkts;
+ __le16 tx_duration;
+ __le32 reserved1;
+ __le32 reserved2;
+} __packed;
+
+struct htt_peer_tx_stats {
+ u8 num_ppdu;
+ u8 ppdu_len;
+ u8 version;
+ u8 payload[0];
+} __packed;
+
union htt_rx_pn_t {
/* WEP: 24-bit PN */
u32 pn24;
@@ -1521,6 +1545,7 @@ struct htt_resp {
struct htt_tx_fetch_confirm tx_fetch_confirm;
struct htt_tx_mode_switch_ind tx_mode_switch_ind;
struct htt_channel_change chan_change;
+ struct htt_peer_tx_stats peer_tx_stats;
};
} __packed;
diff --git a/drivers/net/wireless/ath/ath10k/htt_rx.c b/drivers/net/wireless/ath/ath10k/htt_rx.c
index 0b4c1562420f..ef28b358cf5e 100644
--- a/drivers/net/wireless/ath/ath10k/htt_rx.c
+++ b/drivers/net/wireless/ath/ath10k/htt_rx.c
@@ -2194,6 +2194,128 @@ void ath10k_htt_htc_t2h_msg_handler(struct ath10k *ar, struct sk_buff *skb)
dev_kfree_skb_any(skb);
}
+static inline bool is_valid_legacy_rate(u8 rate)
+{
+ static const u8 legacy_rates[] = {1, 2, 5, 11, 6, 9, 12,
+ 18, 24, 36, 48, 54};
+ int i;
+
+ for (i = 0; i < ARRAY_SIZE(legacy_rates); i++) {
+ if (rate == legacy_rates[i])
+ return true;
+ }
+
+ return false;
+}
+
+static void
+ath10k_update_per_peer_tx_stats(struct ath10k *ar,
+ struct ieee80211_sta *sta,
+ struct ath10k_per_peer_tx_stats *peer_stats)
+{
+ struct ath10k_sta *arsta = (struct ath10k_sta *)sta->drv_priv;
+ u8 rate = 0, sgi;
+ struct rate_info txrate;
+
+ lockdep_assert_held(&ar->data_lock);
+
+ txrate.flags = ATH10K_HW_PREAMBLE(peer_stats->ratecode);
+ txrate.bw = ATH10K_HW_BW(peer_stats->flags);
+ txrate.nss = ATH10K_HW_NSS(peer_stats->ratecode);
+ txrate.mcs = ATH10K_HW_MCS_RATE(peer_stats->ratecode);
+ sgi = ATH10K_HW_GI(peer_stats->flags);
+
+ if (((txrate.flags == WMI_RATE_PREAMBLE_HT) ||
+ (txrate.flags == WMI_RATE_PREAMBLE_VHT)) && txrate.mcs > 9) {
+ ath10k_warn(ar, "Invalid mcs %hhd peer stats", txrate.mcs);
+ return;
+ }
+
+ if (txrate.flags == WMI_RATE_PREAMBLE_CCK ||
+ txrate.flags == WMI_RATE_PREAMBLE_OFDM) {
+ rate = ATH10K_HW_LEGACY_RATE(peer_stats->ratecode);
+
+ if (!is_valid_legacy_rate(rate)) {
+ ath10k_warn(ar, "Invalid legacy rate %hhd peer stats",
+ rate);
+ return;
+ }
+
+ /* This is hacky, FW sends CCK rate 5.5Mbps as 6 */
+ rate *= 10;
+ if (rate == 60 && txrate.flags == WMI_RATE_PREAMBLE_CCK)
+ rate = rate - 5;
+ arsta->txrate.legacy = rate * 10;
+ } else if (txrate.flags == WMI_RATE_PREAMBLE_HT) {
+ arsta->txrate.flags = RATE_INFO_FLAGS_MCS;
+ arsta->txrate.mcs = txrate.mcs;
+ } else {
+ arsta->txrate.flags = RATE_INFO_FLAGS_VHT_MCS;
+ arsta->txrate.mcs = txrate.mcs;
+ }
+
+ if (sgi)
+ arsta->txrate.flags |= RATE_INFO_FLAGS_SHORT_GI;
+
+ arsta->txrate.nss = txrate.nss;
+ arsta->txrate.bw = txrate.bw + RATE_INFO_BW_20;
+}
+
+static void ath10k_htt_fetch_peer_stats(struct ath10k *ar,
+ struct sk_buff *skb)
+{
+ struct htt_resp *resp = (struct htt_resp *)skb->data;
+ struct ath10k_per_peer_tx_stats *p_tx_stats = &ar->peer_tx_stats;
+ struct htt_per_peer_tx_stats_ind *tx_stats;
+ struct ieee80211_sta *sta;
+ struct ath10k_peer *peer;
+ int peer_id, i;
+ u8 ppdu_len, num_ppdu;
+
+ num_ppdu = resp->peer_tx_stats.num_ppdu;
+ ppdu_len = resp->peer_tx_stats.ppdu_len * sizeof(__le32);
+
+ if (skb->len < sizeof(struct htt_resp_hdr) + num_ppdu * ppdu_len) {
+ ath10k_warn(ar, "Invalid peer stats buf length %d\n", skb->len);
+ return;
+ }
+
+ tx_stats = (struct htt_per_peer_tx_stats_ind *)
+ (resp->peer_tx_stats.payload);
+ peer_id = tx_stats->peer_id;
+
+ rcu_read_lock();
+ spin_lock_bh(&ar->data_lock);
+ peer = ath10k_peer_find_by_id(ar, peer_id);
+ if (!peer) {
+ ath10k_warn(ar, "Invalid peer id %d peer stats buffer\n",
+ peer_id);
+ goto out;
+ }
+
+ sta = peer->sta;
+ for (i = 0; i < num_ppdu; i++) {
+ tx_stats = (struct htt_per_peer_tx_stats_ind *)
+ (resp->peer_tx_stats.payload + i * ppdu_len);
+
+ p_tx_stats->succ_bytes = __le32_to_cpu(tx_stats->succ_bytes);
+ p_tx_stats->retry_bytes = __le32_to_cpu(tx_stats->retry_bytes);
+ p_tx_stats->failed_bytes =
+ __le32_to_cpu(tx_stats->failed_bytes);
+ p_tx_stats->ratecode = tx_stats->ratecode;
+ p_tx_stats->flags = tx_stats->flags;
+ p_tx_stats->succ_pkts = __le16_to_cpu(tx_stats->succ_pkts);
+ p_tx_stats->retry_pkts = __le16_to_cpu(tx_stats->retry_pkts);
+ p_tx_stats->failed_pkts = __le16_to_cpu(tx_stats->failed_pkts);
+
+ ath10k_update_per_peer_tx_stats(ar, sta, p_tx_stats);
+ }
+
+out:
+ spin_unlock_bh(&ar->data_lock);
+ rcu_read_unlock();
+}
+
bool ath10k_htt_t2h_msg_handler(struct ath10k *ar, struct sk_buff *skb)
{
struct ath10k_htt *htt = &ar->htt;
@@ -2354,6 +2476,9 @@ bool ath10k_htt_t2h_msg_handler(struct ath10k *ar, struct sk_buff *skb)
case HTT_T2H_MSG_TYPE_TX_MODE_SWITCH_IND:
ath10k_htt_rx_tx_mode_switch_ind(ar, skb);
break;
+ case HTT_T2H_MSG_TYPE_PEER_STATS:
+ ath10k_htt_fetch_peer_stats(ar, skb);
+ break;
case HTT_T2H_MSG_TYPE_EN_STATS:
default:
ath10k_warn(ar, "htt event (%d) not handled\n",
diff --git a/drivers/net/wireless/ath/ath10k/wmi.h b/drivers/net/wireless/ath/ath10k/wmi.h
index 1b243c899bef..e108d49998c3 100644
--- a/drivers/net/wireless/ath/ath10k/wmi.h
+++ b/drivers/net/wireless/ath/ath10k/wmi.h
@@ -4603,9 +4603,17 @@ enum wmi_rate_preamble {
#define ATH10K_HW_NSS(rate) (1 + (((rate) >> 4) & 0x3))
#define ATH10K_HW_PREAMBLE(rate) (((rate) >> 6) & 0x3)
-#define ATH10K_HW_RATECODE(rate, nss, preamble) \
+#define ATH10K_HW_MCS_RATE(rate) ((rate) & 0xf)
+#define ATH10K_HW_LEGACY_RATE(rate) ((rate) & 0x3f)
+#define ATH10K_HW_BW(flags) (((flags) >> 3) & 0x3)
+#define ATH10K_HW_GI(flags) (((flags) >> 5) & 0x1)
+#define ATH10K_HW_RATECODE(rate, nss, preamble) \
(((preamble) << 6) | ((nss) << 4) | (rate))
+#define VHT_MCS_NUM 10
+#define VHT_BW_NUM 4
+#define VHT_NSS_NUM 4
+
/* Value to disable fixed rate setting */
#define WMI_FIXED_RATE_NONE (0xff)
--
1.7.9.5
^ permalink raw reply related
* [PATCHv2 2/2] ath10k: add support for per sta tx bitrate
From: akolli @ 2016-10-18 9:31 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless, akolli, Anilkumar Kolli
In-Reply-To: <1476783085-10724-1-git-send-email-akolli@qti.qualcomm.com>
From: Anilkumar Kolli <akolli@qti.qualcomm.com>
Per STA tx bitrate info is filled from peer stats.
Export per sta txrate info to cfg80211/nl80211
Signed-off-by: Anilkumar Kolli <akolli@qti.qualcomm.com>
---
v2:
* addressed kalle's comments
drivers/net/wireless/ath/ath10k/debugfs_sta.c | 13 +++++++++++++
1 file changed, 13 insertions(+)
diff --git a/drivers/net/wireless/ath/ath10k/debugfs_sta.c b/drivers/net/wireless/ath/ath10k/debugfs_sta.c
index 9955fea0802a..fce6f8137d33 100644
--- a/drivers/net/wireless/ath/ath10k/debugfs_sta.c
+++ b/drivers/net/wireless/ath/ath10k/debugfs_sta.c
@@ -77,6 +77,19 @@ void ath10k_sta_statistics(struct ieee80211_hw *hw, struct ieee80211_vif *vif,
sinfo->rx_duration = arsta->rx_duration;
sinfo->filled |= 1ULL << NL80211_STA_INFO_RX_DURATION;
+
+ if (!arsta->txrate.legacy && !arsta->txrate.nss)
+ return;
+
+ if (arsta->txrate.legacy) {
+ sinfo->txrate.legacy = arsta->txrate.legacy;
+ } else {
+ sinfo->txrate.mcs = arsta->txrate.mcs;
+ sinfo->txrate.nss = arsta->txrate.nss;
+ sinfo->txrate.bw = arsta->txrate.bw;
+ }
+ sinfo->txrate.flags = arsta->txrate.flags;
+ sinfo->filled |= 1ULL << NL80211_STA_INFO_TX_BITRATE;
}
static ssize_t ath10k_dbg_sta_read_aggr_mode(struct file *file,
--
1.7.9.5
^ permalink raw reply related
* sequence diagrams in rst documentation
From: Johannes Berg @ 2016-10-18 11:43 UTC (permalink / raw)
To: Jonathan Corbet; +Cc: linux-wireless, linux-doc
In-Reply-To: <1476194038.4118.11.camel@sipsolutions.net>
On Tue, 2016-10-11 at 15:53 +0200, Johannes Berg wrote:
> >
> >
> > Related question: I have some sequence diagrams, and just found the
> > seqdiag sphinx plugin. How should we manage adding extensions? Or
> > would you prefer not to add any at all?
>
> Example here:
> https://johannes.sipsolutions.net/files/80211/mac80211.html#connection-flow
Coming back to this - sadly, it appears that this software (blockdiag,
seqdiag) is completely unmaintained, with open pull requests dating
back to 2012 and the last commit dating back to 2015-08-22.
I'd want/need feature improvements in it too, but if I can't feed those
back to upstream (since it appears dead), there's little point.
Perhaps we can ship plugins for this as part of the kernel sources?
Shouldn't be too difficult to reimplement something like this, after
all.
johannes
^ permalink raw reply
* Re: sequence diagrams in rst documentation
From: Markus Heiser @ 2016-10-18 13:51 UTC (permalink / raw)
To: Johannes Berg; +Cc: Jonathan Corbet, linux-wireless, linux-doc
In-Reply-To: <1476791021.6425.25.camel@sipsolutions.net>
Am 18.10.2016 um 13:43 schrieb Johannes Berg <johannes@sipsolutions.net>:
> On Tue, 2016-10-11 at 15:53 +0200, Johannes Berg wrote:
>>>
>>>
>>> Related question: I have some sequence diagrams, and just found the
>>> seqdiag sphinx plugin. How should we manage adding extensions? Or
>>> would you prefer not to add any at all?
>>
>> Example here:
>> https://johannes.sipsolutions.net/files/80211/mac80211.html#connection-flow
>
> Coming back to this - sadly, it appears that this software (blockdiag,
> seqdiag) is completely unmaintained, with open pull requests dating
> back to 2012 and the last commit dating back to 2015-08-22.
>
> I'd want/need feature improvements in it too, but if I can't feed those
> back to upstream (since it appears dead), there's little point.
>
> Perhaps we can ship plugins for this as part of the kernel sources?
> Shouldn't be too difficult to reimplement something like this, after
> all.
Here are my thoughts ...
Every extension which is not a part of the sphinx distro brings new
external dependencies and the development of such extensions is IMO
far of kernel development's scope.
ATM, there are not many use cases for diagram generators, so why not
be KISS and creating diagrams with the favorite tool only adding the
resulting (e.g.) PNG to the Kernel's source?
Before we add new dependencies / complexity, we should get rid
of the DocBook build.
-- Markus --
> johannes
> --
> To unsubscribe from this list: send the line "unsubscribe linux-doc" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [RFC PATCH 0/2] mac80211: aes_ccm: cache AEAD request allocations per CPU
From: Ard Biesheuvel @ 2016-10-18 14:08 UTC (permalink / raw)
To: linux-wireless, johannes, netdev; +Cc: herbert, j, luto, Ard Biesheuvel
This RFC implements per CPU caching of AEAD request structures, which allows
us to get rid of the per-packet kzalloc/kzfree calls we were forced to
introduce to deal with SG API violations, both in the mac80211 and in the
core crypto API code.
Since mac80211 only executes the AEAD transforms in softirq context, only one
AEAD request can be in flight at the same time on any given CPU, and so, instead
of free the request, we can stash its address in a per CPU variable, and reuse
it for the next packet.
This RFC only addressess CCMP, but GCM and GMAC could be fixed in the same way
(and CMAC did not suffer from the API violation issue in the first place)
Ard Biesheuvel (2):
mac80211: aes_ccm: prepare key struct for storing context data
mac80211: aes_ccm: cache AEAD request structures per CPU
net/mac80211/aes_ccm.c | 80 +++++++++++++-------
net/mac80211/aes_ccm.h | 16 ++--
net/mac80211/key.c | 16 ++--
net/mac80211/key.h | 3 +-
net/mac80211/wpa.c | 4 +-
5 files changed, 71 insertions(+), 48 deletions(-)
--
2.7.4
^ permalink raw reply
* [RFC PATCH 1/2] mac80211: aes_ccm: prepare key struct for storing context data
From: Ard Biesheuvel @ 2016-10-18 14:08 UTC (permalink / raw)
To: linux-wireless, johannes, netdev; +Cc: herbert, j, luto, Ard Biesheuvel
In-Reply-To: <1476799713-16188-1-git-send-email-ard.biesheuvel@linaro.org>
As a prepatory change to allow per CPU caching of request structures,
refactor the key allocation routine so we can access per key data
beyond the core AEAD transform easily.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
---
net/mac80211/aes_ccm.c | 35 +++++++++++---------
net/mac80211/aes_ccm.h | 16 ++++-----
net/mac80211/key.c | 16 ++++-----
net/mac80211/key.h | 2 +-
net/mac80211/wpa.c | 4 +--
5 files changed, 37 insertions(+), 36 deletions(-)
diff --git a/net/mac80211/aes_ccm.c b/net/mac80211/aes_ccm.c
index a4e0d59a40dd..58e0338a2c34 100644
--- a/net/mac80211/aes_ccm.c
+++ b/net/mac80211/aes_ccm.c
@@ -10,6 +10,7 @@
*/
#include <linux/kernel.h>
+#include <linux/percpu.h>
#include <linux/types.h>
#include <linux/err.h>
#include <crypto/aead.h>
@@ -18,13 +19,13 @@
#include "key.h"
#include "aes_ccm.h"
-int ieee80211_aes_ccm_encrypt(struct crypto_aead *tfm, u8 *b_0, u8 *aad,
- u8 *data, size_t data_len, u8 *mic,
+int ieee80211_aes_ccm_encrypt(struct ieee80211_ccmp_aead *ccmp, u8 *b_0,
+ u8 *aad, u8 *data, size_t data_len, u8 *mic,
size_t mic_len)
{
struct scatterlist sg[3];
struct aead_request *aead_req;
- int reqsize = sizeof(*aead_req) + crypto_aead_reqsize(tfm);
+ int reqsize = sizeof(*aead_req) + crypto_aead_reqsize(ccmp->tfm);
u8 *__aad;
aead_req = kzalloc(reqsize + CCM_AAD_LEN, GFP_ATOMIC);
@@ -39,7 +40,7 @@ int ieee80211_aes_ccm_encrypt(struct crypto_aead *tfm, u8 *b_0, u8 *aad,
sg_set_buf(&sg[1], data, data_len);
sg_set_buf(&sg[2], mic, mic_len);
- aead_request_set_tfm(aead_req, tfm);
+ aead_request_set_tfm(aead_req, ccmp->tfm);
aead_request_set_crypt(aead_req, sg, sg, data_len, b_0);
aead_request_set_ad(aead_req, sg[0].length);
@@ -49,13 +50,13 @@ int ieee80211_aes_ccm_encrypt(struct crypto_aead *tfm, u8 *b_0, u8 *aad,
return 0;
}
-int ieee80211_aes_ccm_decrypt(struct crypto_aead *tfm, u8 *b_0, u8 *aad,
- u8 *data, size_t data_len, u8 *mic,
+int ieee80211_aes_ccm_decrypt(struct ieee80211_ccmp_aead *ccmp, u8 *b_0,
+ u8 *aad, u8 *data, size_t data_len, u8 *mic,
size_t mic_len)
{
struct scatterlist sg[3];
struct aead_request *aead_req;
- int reqsize = sizeof(*aead_req) + crypto_aead_reqsize(tfm);
+ int reqsize = sizeof(*aead_req) + crypto_aead_reqsize(ccmp->tfm);
u8 *__aad;
int err;
@@ -74,7 +75,7 @@ int ieee80211_aes_ccm_decrypt(struct crypto_aead *tfm, u8 *b_0, u8 *aad,
sg_set_buf(&sg[1], data, data_len);
sg_set_buf(&sg[2], mic, mic_len);
- aead_request_set_tfm(aead_req, tfm);
+ aead_request_set_tfm(aead_req, ccmp->tfm);
aead_request_set_crypt(aead_req, sg, sg, data_len + mic_len, b_0);
aead_request_set_ad(aead_req, sg[0].length);
@@ -84,16 +85,17 @@ int ieee80211_aes_ccm_decrypt(struct crypto_aead *tfm, u8 *b_0, u8 *aad,
return err;
}
-struct crypto_aead *ieee80211_aes_key_setup_encrypt(const u8 key[],
- size_t key_len,
- size_t mic_len)
+int ieee80211_aes_key_setup_encrypt(struct ieee80211_ccmp_aead *ccmp,
+ const u8 key[],
+ size_t key_len,
+ size_t mic_len)
{
struct crypto_aead *tfm;
int err;
tfm = crypto_alloc_aead("ccm(aes)", 0, CRYPTO_ALG_ASYNC);
if (IS_ERR(tfm))
- return tfm;
+ return PTR_ERR(tfm);
err = crypto_aead_setkey(tfm, key, key_len);
if (err)
@@ -102,14 +104,15 @@ struct crypto_aead *ieee80211_aes_key_setup_encrypt(const u8 key[],
if (err)
goto free_aead;
- return tfm;
+ ccmp->tfm = tfm;
+ return 0;
free_aead:
crypto_free_aead(tfm);
- return ERR_PTR(err);
+ return err;
}
-void ieee80211_aes_key_free(struct crypto_aead *tfm)
+void ieee80211_aes_key_free(struct ieee80211_ccmp_aead *ccmp)
{
- crypto_free_aead(tfm);
+ crypto_free_aead(ccmp->tfm);
}
diff --git a/net/mac80211/aes_ccm.h b/net/mac80211/aes_ccm.h
index fcd3254c5cf0..82e91c6ec41f 100644
--- a/net/mac80211/aes_ccm.h
+++ b/net/mac80211/aes_ccm.h
@@ -14,15 +14,15 @@
#define CCM_AAD_LEN 32
-struct crypto_aead *ieee80211_aes_key_setup_encrypt(const u8 key[],
- size_t key_len,
- size_t mic_len);
-int ieee80211_aes_ccm_encrypt(struct crypto_aead *tfm, u8 *b_0, u8 *aad,
- u8 *data, size_t data_len, u8 *mic,
+int ieee80211_aes_key_setup_encrypt(struct ieee80211_ccmp_aead *ccmp,
+ const u8 key[], size_t key_len,
+ size_t mic_len);
+int ieee80211_aes_ccm_encrypt(struct ieee80211_ccmp_aead *ccmp, u8 *b_0,
+ u8 *aad, u8 *data, size_t data_len, u8 *mic,
size_t mic_len);
-int ieee80211_aes_ccm_decrypt(struct crypto_aead *tfm, u8 *b_0, u8 *aad,
- u8 *data, size_t data_len, u8 *mic,
+int ieee80211_aes_ccm_decrypt(struct ieee80211_ccmp_aead *ccmp, u8 *b_0,
+ u8 *aad, u8 *data, size_t data_len, u8 *mic,
size_t mic_len);
-void ieee80211_aes_key_free(struct crypto_aead *tfm);
+void ieee80211_aes_key_free(struct ieee80211_ccmp_aead *ccmp);
#endif /* AES_CCM_H */
diff --git a/net/mac80211/key.c b/net/mac80211/key.c
index edd6f2945f69..6d1a066e3c4e 100644
--- a/net/mac80211/key.c
+++ b/net/mac80211/key.c
@@ -431,10 +431,9 @@ ieee80211_key_alloc(u32 cipher, int idx, size_t key_len,
* Initialize AES key state here as an optimization so that
* it does not need to be initialized for every packet.
*/
- key->u.ccmp.tfm = ieee80211_aes_key_setup_encrypt(
- key_data, key_len, IEEE80211_CCMP_MIC_LEN);
- if (IS_ERR(key->u.ccmp.tfm)) {
- err = PTR_ERR(key->u.ccmp.tfm);
+ err = ieee80211_aes_key_setup_encrypt(&key->u.ccmp, key_data,
+ key_len, IEEE80211_CCMP_MIC_LEN);
+ if (err) {
kfree(key);
return ERR_PTR(err);
}
@@ -449,10 +448,9 @@ ieee80211_key_alloc(u32 cipher, int idx, size_t key_len,
/* Initialize AES key state here as an optimization so that
* it does not need to be initialized for every packet.
*/
- key->u.ccmp.tfm = ieee80211_aes_key_setup_encrypt(
- key_data, key_len, IEEE80211_CCMP_256_MIC_LEN);
- if (IS_ERR(key->u.ccmp.tfm)) {
- err = PTR_ERR(key->u.ccmp.tfm);
+ err = ieee80211_aes_key_setup_encrypt(&key->u.ccmp, key_data,
+ key_len, IEEE80211_CCMP_256_MIC_LEN);
+ if (err) {
kfree(key);
return ERR_PTR(err);
}
@@ -545,7 +543,7 @@ static void ieee80211_key_free_common(struct ieee80211_key *key)
switch (key->conf.cipher) {
case WLAN_CIPHER_SUITE_CCMP:
case WLAN_CIPHER_SUITE_CCMP_256:
- ieee80211_aes_key_free(key->u.ccmp.tfm);
+ ieee80211_aes_key_free(&key->u.ccmp);
break;
case WLAN_CIPHER_SUITE_AES_CMAC:
case WLAN_CIPHER_SUITE_BIP_CMAC_256:
diff --git a/net/mac80211/key.h b/net/mac80211/key.h
index 4aa20cef0859..1ec7a737ab79 100644
--- a/net/mac80211/key.h
+++ b/net/mac80211/key.h
@@ -80,7 +80,7 @@ struct ieee80211_key {
/* number of mic failures */
u32 mic_failures;
} tkip;
- struct {
+ struct ieee80211_ccmp_aead {
/*
* Last received packet number. The first
* IEEE80211_NUM_TIDS counters are used with Data
diff --git a/net/mac80211/wpa.c b/net/mac80211/wpa.c
index 14b28998c571..694af013494f 100644
--- a/net/mac80211/wpa.c
+++ b/net/mac80211/wpa.c
@@ -461,7 +461,7 @@ static int ccmp_encrypt_skb(struct ieee80211_tx_data *tx, struct sk_buff *skb,
pos += IEEE80211_CCMP_HDR_LEN;
ccmp_special_blocks(skb, pn, b_0, aad);
- return ieee80211_aes_ccm_encrypt(key->u.ccmp.tfm, b_0, aad, pos, len,
+ return ieee80211_aes_ccm_encrypt(&key->u.ccmp, b_0, aad, pos, len,
skb_put(skb, mic_len), mic_len);
}
@@ -538,7 +538,7 @@ ieee80211_crypto_ccmp_decrypt(struct ieee80211_rx_data *rx,
ccmp_special_blocks(skb, pn, b_0, aad);
if (ieee80211_aes_ccm_decrypt(
- key->u.ccmp.tfm, b_0, aad,
+ &key->u.ccmp, b_0, aad,
skb->data + hdrlen + IEEE80211_CCMP_HDR_LEN,
data_len,
skb->data + skb->len - mic_len, mic_len))
--
2.7.4
^ permalink raw reply related
* [RFC PATCH 2/2] mac80211: aes_ccm: cache AEAD request structures per CPU
From: Ard Biesheuvel @ 2016-10-18 14:08 UTC (permalink / raw)
To: linux-wireless, johannes, netdev; +Cc: herbert, j, luto, Ard Biesheuvel
In-Reply-To: <1476799713-16188-1-git-send-email-ard.biesheuvel@linaro.org>
Now that we can no longer invoke AEAD transforms with the aead_request
structure allocated on the stack, we perform a kmalloc/kfree for every
packet, which is expensive.
Since the CCMP routines execute in softirq context, we know there can
never be more than one request in flight on each CPU, and so we can
simply keep a cached aead_request structure per CPU, and deallocate all
of them when deallocating the AEAD transform.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
---
net/mac80211/aes_ccm.c | 49 ++++++++++++++------
net/mac80211/key.h | 1 +
2 files changed, 36 insertions(+), 14 deletions(-)
diff --git a/net/mac80211/aes_ccm.c b/net/mac80211/aes_ccm.c
index 58e0338a2c34..2cb5ee4868ea 100644
--- a/net/mac80211/aes_ccm.c
+++ b/net/mac80211/aes_ccm.c
@@ -28,9 +28,14 @@ int ieee80211_aes_ccm_encrypt(struct ieee80211_ccmp_aead *ccmp, u8 *b_0,
int reqsize = sizeof(*aead_req) + crypto_aead_reqsize(ccmp->tfm);
u8 *__aad;
- aead_req = kzalloc(reqsize + CCM_AAD_LEN, GFP_ATOMIC);
- if (!aead_req)
- return -ENOMEM;
+ aead_req = *this_cpu_ptr(ccmp->reqs);
+ if (!aead_req) {
+ aead_req = kzalloc(reqsize + CCM_AAD_LEN, GFP_ATOMIC);
+ if (!aead_req)
+ return -ENOMEM;
+ *this_cpu_ptr(ccmp->reqs) = aead_req;
+ aead_request_set_tfm(aead_req, ccmp->tfm);
+ }
__aad = (u8 *)aead_req + reqsize;
memcpy(__aad, aad, CCM_AAD_LEN);
@@ -40,12 +45,10 @@ int ieee80211_aes_ccm_encrypt(struct ieee80211_ccmp_aead *ccmp, u8 *b_0,
sg_set_buf(&sg[1], data, data_len);
sg_set_buf(&sg[2], mic, mic_len);
- aead_request_set_tfm(aead_req, ccmp->tfm);
aead_request_set_crypt(aead_req, sg, sg, data_len, b_0);
aead_request_set_ad(aead_req, sg[0].length);
crypto_aead_encrypt(aead_req);
- kzfree(aead_req);
return 0;
}
@@ -58,14 +61,18 @@ int ieee80211_aes_ccm_decrypt(struct ieee80211_ccmp_aead *ccmp, u8 *b_0,
struct aead_request *aead_req;
int reqsize = sizeof(*aead_req) + crypto_aead_reqsize(ccmp->tfm);
u8 *__aad;
- int err;
if (data_len == 0)
return -EINVAL;
- aead_req = kzalloc(reqsize + CCM_AAD_LEN, GFP_ATOMIC);
- if (!aead_req)
- return -ENOMEM;
+ aead_req = *this_cpu_ptr(ccmp->reqs);
+ if (!aead_req) {
+ aead_req = kzalloc(reqsize + CCM_AAD_LEN, GFP_ATOMIC);
+ if (!aead_req)
+ return -ENOMEM;
+ *this_cpu_ptr(ccmp->reqs) = aead_req;
+ aead_request_set_tfm(aead_req, ccmp->tfm);
+ }
__aad = (u8 *)aead_req + reqsize;
memcpy(__aad, aad, CCM_AAD_LEN);
@@ -75,14 +82,10 @@ int ieee80211_aes_ccm_decrypt(struct ieee80211_ccmp_aead *ccmp, u8 *b_0,
sg_set_buf(&sg[1], data, data_len);
sg_set_buf(&sg[2], mic, mic_len);
- aead_request_set_tfm(aead_req, ccmp->tfm);
aead_request_set_crypt(aead_req, sg, sg, data_len + mic_len, b_0);
aead_request_set_ad(aead_req, sg[0].length);
- err = crypto_aead_decrypt(aead_req);
- kzfree(aead_req);
-
- return err;
+ return crypto_aead_decrypt(aead_req);
}
int ieee80211_aes_key_setup_encrypt(struct ieee80211_ccmp_aead *ccmp,
@@ -91,6 +94,7 @@ int ieee80211_aes_key_setup_encrypt(struct ieee80211_ccmp_aead *ccmp,
size_t mic_len)
{
struct crypto_aead *tfm;
+ struct aead_request **r;
int err;
tfm = crypto_alloc_aead("ccm(aes)", 0, CRYPTO_ALG_ASYNC);
@@ -104,6 +108,14 @@ int ieee80211_aes_key_setup_encrypt(struct ieee80211_ccmp_aead *ccmp,
if (err)
goto free_aead;
+ /* allow a struct aead_request to be cached per cpu */
+ r = alloc_percpu(struct aead_request *);
+ if (!r) {
+ err = -ENOMEM;
+ goto free_aead;
+ }
+
+ ccmp->reqs = r;
ccmp->tfm = tfm;
return 0;
@@ -114,5 +126,14 @@ int ieee80211_aes_key_setup_encrypt(struct ieee80211_ccmp_aead *ccmp,
void ieee80211_aes_key_free(struct ieee80211_ccmp_aead *ccmp)
{
+ struct aead_request *req;
+ int cpu;
+
+ for_each_possible_cpu(cpu) {
+ req = *per_cpu_ptr(ccmp->reqs, cpu);
+ if (req)
+ kzfree(req);
+ }
+ free_percpu(ccmp->reqs);
crypto_free_aead(ccmp->tfm);
}
diff --git a/net/mac80211/key.h b/net/mac80211/key.h
index 1ec7a737ab79..f99ec46dc08f 100644
--- a/net/mac80211/key.h
+++ b/net/mac80211/key.h
@@ -89,6 +89,7 @@ struct ieee80211_key {
*/
u8 rx_pn[IEEE80211_NUM_TIDS + 1][IEEE80211_CCMP_PN_LEN];
struct crypto_aead *tfm;
+ struct aead_request * __percpu *reqs;
u32 replays; /* dot11RSNAStatsCCMPReplays */
} ccmp;
struct {
--
2.7.4
^ permalink raw reply related
* Re: sequence diagrams in rst documentation
From: Johannes Berg @ 2016-10-18 14:12 UTC (permalink / raw)
To: Markus Heiser; +Cc: Jonathan Corbet, linux-wireless, linux-doc
In-Reply-To: <B9AC83F3-AA14-414B-B538-81436620E432@darmarit.de>
On Tue, 2016-10-18 at 15:51 +0200, Markus Heiser wrote:
> Here are my thoughts ...
>
> Every extension which is not a part of the sphinx distro brings new
> external dependencies
I agree.
> and the development of such extensions is IMO
> far of kernel development's scope.
Arguably, having good documentation *is* in the scope of kernel
development.
Also, it could be argued that shipping a module in the kernel sources
would be more reliable than having to require it being externally
installed, like the GCC plugins perhaps.
> ATM, there are not many use cases for diagram generators, so why not
> be KISS and creating diagrams with the favorite tool only adding the
> resulting (e.g.) PNG to the Kernel's source?
*Only* adding the PNG would be awful, I'd have to keep track of the
corresponding source elsewhere, and perhaps couldn't even GPL it
because then I couldn't distribute the PNG without corresponding
source...
Adding the source text would really be the only practical choice, but
doing so makes it easy to mismatch things, and also very easy to use
proprietary services for it that may go away at any time, etc.
> Before we add new dependencies / complexity, we should get rid
> of the DocBook build.
That argument is ... completely bogus, politely said.
I'm not going to (be able to) do anything about all the docbooks that
exist, and have in fact converted the one docbook that I know anything
about. Holding back the development of documentation in one subsystem
because another subsystem hasn't converted is a garbage argument.
johannes
^ permalink raw reply
* Re: [RFC PATCH 2/2] mac80211: aes_ccm: cache AEAD request structures per CPU
From: Johannes Berg @ 2016-10-18 14:16 UTC (permalink / raw)
To: Ard Biesheuvel, linux-wireless, netdev; +Cc: herbert, j, luto
In-Reply-To: <1476799713-16188-3-git-send-email-ard.biesheuvel@linaro.org>
On Tue, 2016-10-18 at 15:08 +0100, Ard Biesheuvel wrote:
>
> + aead_req = *this_cpu_ptr(ccmp->reqs);
> + if (!aead_req) {
> + aead_req = kzalloc(reqsize + CCM_AAD_LEN, GFP_ATOMIC);
> + if (!aead_req)
> + return -ENOMEM;
> + *this_cpu_ptr(ccmp->reqs) = aead_req;
> + aead_request_set_tfm(aead_req, ccmp->tfm);
> + }
Hmm. Is it really worth having a per-CPU variable for each possible
key? You could have a large number of those (typically three when
you're a client on an AP, and 1 + 1 for each client when you're the
AP).
Would it be so bad to have to set the TFM every time (if that's even
possible), and just have a single per-CPU cache?
johannes
^ permalink raw reply
* Re: [RFC PATCH 2/2] mac80211: aes_ccm: cache AEAD request structures per CPU
From: Ard Biesheuvel @ 2016-10-18 14:18 UTC (permalink / raw)
To: Johannes Berg
Cc: <linux-wireless@vger.kernel.org>,
<netdev@vger.kernel.org>, Herbert Xu, Jouni Malinen,
Andy Lutomirski
In-Reply-To: <1476800194.6425.35.camel@sipsolutions.net>
On 18 October 2016 at 15:16, Johannes Berg <johannes@sipsolutions.net> wrote:
> On Tue, 2016-10-18 at 15:08 +0100, Ard Biesheuvel wrote:
>>
>> + aead_req = *this_cpu_ptr(ccmp->reqs);
>> + if (!aead_req) {
>> + aead_req = kzalloc(reqsize + CCM_AAD_LEN, GFP_ATOMIC);
>> + if (!aead_req)
>> + return -ENOMEM;
>> + *this_cpu_ptr(ccmp->reqs) = aead_req;
>> + aead_request_set_tfm(aead_req, ccmp->tfm);
>> + }
>
> Hmm. Is it really worth having a per-CPU variable for each possible
> key? You could have a large number of those (typically three when
> you're a client on an AP, and 1 + 1 for each client when you're the
> AP).
>
> Would it be so bad to have to set the TFM every time (if that's even
> possible), and just have a single per-CPU cache?
>
That would be preferred, yes. The only snag here is that
crypto_alloc_aead() is not guaranteed to return the same algo every
time, which means the request size is not guaranteed to be the same
either. This is a rare corner case, of course, but it needs to be
dealt with regardless
^ permalink raw reply
* Re: [RFC PATCH 2/2] mac80211: aes_ccm: cache AEAD request structures per CPU
From: Johannes Berg @ 2016-10-18 14:24 UTC (permalink / raw)
To: Ard Biesheuvel
Cc: <linux-wireless@vger.kernel.org>,
<netdev@vger.kernel.org>, Herbert Xu, Jouni Malinen,
Andy Lutomirski
In-Reply-To: <CAKv+Gu8aE4AfewHeMDf2RQfJtSsrp6Fb1A_ygFsqEwpyP6hDjQ@mail.gmail.com>
On Tue, 2016-10-18 at 15:18 +0100, Ard Biesheuvel wrote:
>
> > Hmm. Is it really worth having a per-CPU variable for each possible
> > key? You could have a large number of those (typically three when
> > you're a client on an AP, and 1 + 1 for each client when you're the
> > AP).
2 + 1 for each client, actually, since you have 2 GTKs present in the
"steady state"; not a big difference though.
> > Would it be so bad to have to set the TFM every time (if that's
> > even possible), and just have a single per-CPU cache?
> That would be preferred, yes. The only snag here is that
> crypto_alloc_aead() is not guaranteed to return the same algo every
> time, which means the request size is not guaranteed to be the same
> either. This is a rare corner case, of course, but it needs to be
> dealt with regardless
Ah, good point. Well I guess you could allocate a bigger one it if it's
too small, but then we'd have to recalculate the size all the time
(which we already did anyway, but saving something else would be good).
Then we'd be close to just having a per-CPU memory block cache though.
johannes
^ permalink raw reply
* Re: pull-request: mac80211 2016-10-18
From: David Miller @ 2016-10-18 14:26 UTC (permalink / raw)
To: johannes; +Cc: netdev, linux-wireless
In-Reply-To: <1476774058-9279-1-git-send-email-johannes@sipsolutions.net>
From: Johannes Berg <johannes@sipsolutions.net>
Date: Tue, 18 Oct 2016 09:00:57 +0200
> As I mention in the tag message, the most urgent fix here is for
> the VMAP_STACK vs. software crypto usage. I ended up applying Ard's
> fix that dynamically allocates everything in one go, perhaps we'll
> find a better solution in the future, but in the meantime this will
> get things working again (rather than crashing or getting BUG_ON),
> and normally it's a rarely used code path since hardware crypto is
> used for almost all devices.
>
> Please pull, or let me know if there's any problem.
Pulled, thanks Johannes.
^ permalink raw reply
* Re: [RFC PATCH 2/2] mac80211: aes_ccm: cache AEAD request structures per CPU
From: Ard Biesheuvel @ 2016-10-18 14:30 UTC (permalink / raw)
To: Johannes Berg
Cc: <linux-wireless@vger.kernel.org>,
<netdev@vger.kernel.org>, Herbert Xu, Jouni Malinen,
Andy Lutomirski
In-Reply-To: <1476800647.6425.38.camel@sipsolutions.net>
On 18 October 2016 at 15:24, Johannes Berg <johannes@sipsolutions.net> wrote:
> On Tue, 2016-10-18 at 15:18 +0100, Ard Biesheuvel wrote:
>>
>> > Hmm. Is it really worth having a per-CPU variable for each possible
>> > key? You could have a large number of those (typically three when
>> > you're a client on an AP, and 1 + 1 for each client when you're the
>> > AP).
>
> 2 + 1 for each client, actually, since you have 2 GTKs present in the
> "steady state"; not a big difference though.
>
>> > Would it be so bad to have to set the TFM every time (if that's
>> > even possible), and just have a single per-CPU cache?
>
>> That would be preferred, yes. The only snag here is that
>> crypto_alloc_aead() is not guaranteed to return the same algo every
>> time, which means the request size is not guaranteed to be the same
>> either. This is a rare corner case, of course, but it needs to be
>> dealt with regardless
>
> Ah, good point. Well I guess you could allocate a bigger one it if it's
> too small, but then we'd have to recalculate the size all the time
> (which we already did anyway, but saving something else would be good).
> Then we'd be close to just having a per-CPU memory block cache though.
>
Well, ideally we'd allocate the ccm(aes) crypto_alg a single time and
'spawn' the transforms for each key. This is how the crypto API
implements templates internally, but I don't think this functionality
is publicly accessible. Herbert?
^ permalink raw reply
* Re: sequence diagrams in rst documentation
From: Jani Nikula @ 2016-10-18 14:52 UTC (permalink / raw)
To: Johannes Berg, Markus Heiser; +Cc: Jonathan Corbet, linux-wireless, linux-doc
In-Reply-To: <1476799968.6425.33.camel@sipsolutions.net>
On Tue, 18 Oct 2016, Johannes Berg <johannes@sipsolutions.net> wrote:
> On Tue, 2016-10-18 at 15:51 +0200, Markus Heiser wrote:
>> Here are my thoughts ...
>>
>> Every extension which is not a part of the sphinx distro brings new
>> external dependencies
>
> I agree.
>
>> and the development of such extensions is IMO
>> far of kernel development's scope.
>
> Arguably, having good documentation *is* in the scope of kernel
> development.
>
> Also, it could be argued that shipping a module in the kernel sources
> would be more reliable than having to require it being externally
> installed, like the GCC plugins perhaps.
This could probably be argued either way...
My view has been all along that we should prefer to use existing
extensions written and maintained by others. Perhaps we (the kind of
royal "we" of which I'm personally really not part of) could take on
maintainership of some extensions in the interest of improving kernel
documentation, but I think the goal should be that the extensions are
maintained outside of the kernel tree, that the extensions are generally
usable, and have a chance of attracting attention and contributions from
outside of the kernel community. (Note that this doesn't preclude us
from shipping the extensions in the kernel tree, as long as it's updated
from the upstream, not forked.)
(This is one part of me being unhappy about making it easy to run
arbitrary scripts to produce documentation; those will never be generic,
and we'll never be able to offload their maintenance outside of the
kernel. We should not think that we have some really special needs in
the kernel.)
>> ATM, there are not many use cases for diagram generators, so why not
>> be KISS and creating diagrams with the favorite tool only adding the
>> resulting (e.g.) PNG to the Kernel's source?
>
> *Only* adding the PNG would be awful, I'd have to keep track of the
> corresponding source elsewhere, and perhaps couldn't even GPL it
> because then I couldn't distribute the PNG without corresponding
> source...
>
> Adding the source text would really be the only practical choice, but
> doing so makes it easy to mismatch things, and also very easy to use
> proprietary services for it that may go away at any time, etc.
Agreed. And there are other problems with attaching binaries (although
I'd say we should fix them too) [1].
BR,
Jani.
[1] http://lkml.kernel.org/r/02a78907-933d-3f61-572e-28154b16b9e5@redhat.com
--
Jani Nikula, Intel Open Source Technology Center
^ permalink raw reply
* Re: [PATCH v8 1/3] Documentation: dt: net: add ath9k wireless device binding
From: Rob Herring @ 2016-10-18 15:31 UTC (permalink / raw)
To: Martin Blumenstingl
Cc: ath9k-devel, devicetree, linux-wireless, ath9k-devel, mcgrof,
mark.rutland, kvalo, chunkeey, arend.vanspriel, julian.calaby,
bjorn, linux, nbd
In-Reply-To: <20161016205907.19927-2-martin.blumenstingl@googlemail.com>
On Sun, Oct 16, 2016 at 10:59:05PM +0200, Martin Blumenstingl wrote:
> Add documentation how devicetree can be used to configure ath9k based
> devices.
>
> Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
> ---
> .../devicetree/bindings/net/wireless/qca,ath9k.txt | 48 ++++++++++++++++++++++
> 1 file changed, 48 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/net/wireless/qca,ath9k.txt
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Intel 7260 not working on 4.4.24 / armv7
From: Oliver Zemann @ 2016-10-18 16:22 UTC (permalink / raw)
To: linux-wireless
In-Reply-To: <80788796-5768-1650-dcef-59ccfbe7be6f@gmail.com>
Because of the problems with the ath10 card, i bought an intel 7260
(mpcie) wifi card. Unfortunately it is also not working.
I get tons of those messages:
[ 175.777030] usb 1-1: new full-speed USB device number 2 using orion-ehci
[ 175.933953] usb 1-1: New USB device found, idVendor=8087, idProduct=07dc
[ 175.940681] usb 1-1: New USB device strings: Mfr=0, Product=0,
SerialNumber=0
[ 175.966954] Bluetooth: hci0: read Intel version: 3707100180012d0d00
[ 175.973313] Bluetooth: hci0: Intel Bluetooth firmware file:
intel/ibt-hw-37.7.10-fw-1.80.1.2d.d.bseq
[ 176.183954] Bluetooth: hci0: Intel Bluetooth firmware patch completed
and activated
[ 176.749831] usb 1-1: USB disconnect, device number 2
[ 177.076993] usb 1-1: new full-speed USB device number 3 using orion-ehci
[ 177.233953] usb 1-1: New USB device found, idVendor=8087, idProduct=07dc
[ 177.240682] usb 1-1: New USB device strings: Mfr=0, Product=0,
SerialNumber=0
[ 177.266957] Bluetooth: hci0: read Intel version: 3707100180012d0d00
[ 177.273316] Bluetooth: hci0: Intel Bluetooth firmware file:
intel/ibt-hw-37.7.10-fw-1.80.1.2d.d.bseq
[ 177.482955] Bluetooth: hci0: Intel Bluetooth firmware patch completed
and activated
[ 178.046910] usb 1-1: USB disconnect, device number 3
[ 178.376958] usb 1-1: new full-speed USB device number 4 using orion-ehci
[ 178.533954] usb 1-1: New USB device found, idVendor=8087, idProduct=07dc
[ 178.540682] usb 1-1: New USB device strings: Mfr=0, Product=0,
SerialNumber=0
[ 178.566973] Bluetooth: hci0: read Intel version: 3707100180012d0d00
[ 178.573315] Bluetooth: hci0: Intel Bluetooth firmware file:
intel/ibt-hw-37.7.10-fw-1.80.1.2d.d.bseq
[ 178.782953] Bluetooth: hci0: Intel Bluetooth firmware patch completed
and activated
[ 179.356044] usb 1-1: USB disconnect, device number 4
[ 179.686915] usb 1-1: new full-speed USB device number 5 using orion-ehci
[ 179.842952] usb 1-1: New USB device found, idVendor=8087, idProduct=07dc
[ 179.849680] usb 1-1: New USB device strings: Mfr=0, Product=0,
SerialNumber=0
[ 179.878956] Bluetooth: hci0: read Intel version: 3707100180012d0d00
[ 179.885298] Bluetooth: hci0: Intel Bluetooth firmware file:
intel/ibt-hw-37.7.10-fw-1.80.1.2d.d.bseq
[ 180.094953] Bluetooth: hci0: Intel Bluetooth firmware patch completed
and activated
[ 180.650673] usb 1-1: USB disconnect, device number 5
[ 180.976877] usb 1-1: new full-speed USB device number 6 using orion-ehci
[ 181.132954] usb 1-1: New USB device found, idVendor=8087, idProduct=07dc
[ 181.139682] usb 1-1: New USB device strings: Mfr=0, Product=0,
SerialNumber=0
[ 181.165957] Bluetooth: hci0: read Intel version: 3707100180012d0d00
[ 181.172311] Bluetooth: hci0: Intel Bluetooth firmware file:
intel/ibt-hw-37.7.10-fw-1.80.1.2d.d.bseq
[ 181.381955] Bluetooth: hci0: Intel Bluetooth firmware patch completed
and activated
[ 181.950509] usb 1-1: USB disconnect, device number 6
[ 182.276841] usb 1-1: new full-speed USB device number 7 using orion-ehci
[ 182.432953] usb 1-1: New USB device found, idVendor=8087, idProduct=07dc
[ 182.439681] usb 1-1: New USB device strings: Mfr=0, Product=0,
SerialNumber=0
[ 182.465956] Bluetooth: hci0: read Intel version: 3707100180012d0d00
[ 182.472309] Bluetooth: hci0: Intel Bluetooth firmware file:
intel/ibt-hw-37.7.10-fw-1.80.1.2d.d.bseq
[ 182.681956] Bluetooth: hci0: Intel Bluetooth firmware patch completed
and activated
[ 183.247916] usb 1-1: USB disconnect, device number 7
[ 183.576809] usb 1-1: new full-speed USB device number 8 using orion-ehci
[ 183.732954] usb 1-1: New USB device found, idVendor=8087, idProduct=07dc
[ 183.739682] usb 1-1: New USB device strings: Mfr=0, Product=0,
SerialNumber=0
[ 183.765954] Bluetooth: hci0: read Intel version: 3707100180012d0d00
[ 183.772307] Bluetooth: hci0: Intel Bluetooth firmware file:
intel/ibt-hw-37.7.10-fw-1.80.1.2d.d.bseq
[ 183.982955] Bluetooth: hci0: Intel Bluetooth firmware patch completed
and activated
[ 184.552876] usb 1-1: USB disconnect, device number 8
[ 184.886772] usb 1-1: new full-speed USB device number 9 using orion-ehci
[ 185.042953] usb 1-1: New USB device found, idVendor=8087, idProduct=07dc
[ 185.049681] usb 1-1: New USB device strings: Mfr=0, Product=0,
SerialNumber=0
[ 185.073955] Bluetooth: hci0: read Intel version: 3707100180012d0d00
[ 185.080318] Bluetooth: hci0: Intel Bluetooth firmware file:
intel/ibt-hw-37.7.10-fw-1.80.1.2d.d.bseq
[ 185.291956] Bluetooth: hci0: Intel Bluetooth firmware patch completed
and activated
[ 185.854882] usb 1-1: USB disconnect, device number 9
[ 186.186739] usb 1-1: new full-speed USB device number 10 using orion-ehci
[ 186.342953] usb 1-1: New USB device found, idVendor=8087, idProduct=07dc
[ 186.349680] usb 1-1: New USB device strings: Mfr=0, Product=0,
SerialNumber=0
[ 186.373956] Bluetooth: hci0: read Intel version: 3707100180012d0d00
[ 186.380311] Bluetooth: hci0: Intel Bluetooth firmware file:
intel/ibt-hw-37.7.10-fw-1.80.1.2d.d.bseq
[ 186.589954] Bluetooth: hci0: Intel Bluetooth firmware patch completed
and activated
[ 187.160396] usb 1-1: USB disconnect, device number 10
[ 187.486706] usb 1-1: new full-speed USB device number 11 using orion-ehci
[ 187.642954] usb 1-1: New USB device found, idVendor=8087, idProduct=07dc
[ 187.649682] usb 1-1: New USB device strings: Mfr=0, Product=0,
SerialNumber=0
[ 187.675955] Bluetooth: hci0: read Intel version: 3707100180012d0d00
[ 187.682314] Bluetooth: hci0: Intel Bluetooth firmware file:
intel/ibt-hw-37.7.10-fw-1.80.1.2d.d.bseq
[ 187.892955] Bluetooth: hci0: Intel Bluetooth firmware patch completed
and activated
[ 188.464325] usb 1-1: USB disconnect, device number 11
[ 188.796675] usb 1-1: new full-speed USB device number 12 using orion-ehci
[ 188.952953] usb 1-1: New USB device found, idVendor=8087, idProduct=07dc
[ 188.959681] usb 1-1: New USB device strings: Mfr=0, Product=0,
SerialNumber=0
[ 188.985954] Bluetooth: hci0: read Intel version: 3707100180012d0d00
[ 188.992344] Bluetooth: hci0: Intel Bluetooth firmware file:
intel/ibt-hw-37.7.10-fw-1.80.1.2d.d.bseq
[ 189.202955] Bluetooth: hci0: Intel Bluetooth firmware patch completed
and activated
[ 189.770861] usb 1-1: USB disconnect, device number 12
[ 190.106645] usb 1-1: new full-speed USB device number 13 using orion-ehci
[ 190.262953] usb 1-1: New USB device found, idVendor=8087, idProduct=07dc
[ 190.269682] usb 1-1: New USB device strings: Mfr=0, Product=0,
SerialNumber=0
[ 190.296958] Bluetooth: hci0: read Intel version: 3707100180012d0d00
[ 190.303299] Bluetooth: hci0: Intel Bluetooth firmware file:
intel/ibt-hw-37.7.10-fw-1.80.1.2d.d.bseq
[ 190.512954] Bluetooth: hci0: Intel Bluetooth firmware patch completed
and activated
[ 191.076700] usb 1-1: USB disconnect, device number 13
some information about the card:
Bus 001 Device 011: ID 8087:07dc Intel Corp.
Couldn't open device, some information will be missing
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 224 Wireless
bDeviceSubClass 1 Radio Frequency
bDeviceProtocol 1 Bluetooth
bMaxPacketSize0 64
idVendor 0x8087 Intel Corp.
idProduct 0x07dc
bcdDevice 0.01
iManufacturer 0
iProduct 0
iSerial 0
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 177
bNumInterfaces 2
bConfigurationValue 1
iConfiguration 0
bmAttributes 0xe0
Self Powered
Remote Wakeup
MaxPower 100mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 3
bInterfaceClass 224 Wireless
bInterfaceSubClass 1 Radio Frequency
bInterfaceProtocol 1 Bluetooth
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 1
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x02 EP 2 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 1
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x82 EP 2 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 1
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 224 Wireless
bInterfaceSubClass 1 Radio Frequency
bInterfaceProtocol 1 Bluetooth
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x03 EP 3 OUT
bmAttributes 1
Transfer Type Isochronous
Synch Type None
Usage Type Data
wMaxPacketSize 0x0000 1x 0 bytes
bInterval 1
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x83 EP 3 IN
bmAttributes 1
Transfer Type Isochronous
Synch Type None
Usage Type Data
wMaxPacketSize 0x0000 1x 0 bytes
bInterval 1
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 1
bNumEndpoints 2
bInterfaceClass 224 Wireless
bInterfaceSubClass 1 Radio Frequency
bInterfaceProtocol 1 Bluetooth
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x03 EP 3 OUT
bmAttributes 1
Transfer Type Isochronous
Synch Type None
Usage Type Data
wMaxPacketSize 0x0009 1x 9 bytes
bInterval 1
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x83 EP 3 IN
bmAttributes 1
Transfer Type Isochronous
Synch Type None
Usage Type Data
wMaxPacketSize 0x0009 1x 9 bytes
bInterval 1
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 2
bNumEndpoints 2
bInterfaceClass 224 Wireless
bInterfaceSubClass 1 Radio Frequency
bInterfaceProtocol 1 Bluetooth
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x03 EP 3 OUT
bmAttributes 1
Transfer Type Isochronous
Synch Type None
Usage Type Data
wMaxPacketSize 0x0011 1x 17 bytes
bInterval 1
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x83 EP 3 IN
bmAttributes 1
Transfer Type Isochronous
Synch Type None
Usage Type Data
wMaxPacketSize 0x0011 1x 17 bytes
bInterval 1
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 3
bNumEndpoints 2
bInterfaceClass 224 Wireless
bInterfaceSubClass 1 Radio Frequency
bInterfaceProtocol 1 Bluetooth
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x03 EP 3 OUT
bmAttributes 1
Transfer Type Isochronous
Synch Type None
Usage Type Data
wMaxPacketSize 0x0019 1x 25 bytes
bInterval 1
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x83 EP 3 IN
bmAttributes 1
Transfer Type Isochronous
Synch Type None
Usage Type Data
wMaxPacketSize 0x0019 1x 25 bytes
bInterval 1
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 4
bNumEndpoints 2
bInterfaceClass 224 Wireless
bInterfaceSubClass 1 Radio Frequency
bInterfaceProtocol 1 Bluetooth
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x03 EP 3 OUT
bmAttributes 1
Transfer Type Isochronous
Synch Type None
Usage Type Data
wMaxPacketSize 0x0021 1x 33 bytes
bInterval 1
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x83 EP 3 IN
bmAttributes 1
Transfer Type Isochronous
Synch Type None
Usage Type Data
wMaxPacketSize 0x0021 1x 33 bytes
bInterval 1
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 5
bNumEndpoints 2
bInterfaceClass 224 Wireless
bInterfaceSubClass 1 Radio Frequency
bInterfaceProtocol 1 Bluetooth
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x03 EP 3 OUT
bmAttributes 1
Transfer Type Isochronous
Synch Type None
Usage Type Data
wMaxPacketSize 0x0031 1x 49 bytes
bInterval 1
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x83 EP 3 IN
bmAttributes 1
Transfer Type Isochronous
Synch Type None
Usage Type Data
wMaxPacketSize 0x0031 1x 49 bytes
bInterval 1
[root@alarm log]# uname -a
Linux alarm 4.4.24-2-ARCH #1 SMP Fri Oct 14 01:04:22 MDT 2016 armv7l
GNU/Linux
What's confusing me is that this device is connected through pcie, not
usb. When i use lspci i get:
[root@alarm log]# lspci
00:02.0 PCI bridge: Marvell Technology Group Ltd. Device 6828 (rev 04)
00:03.0 PCI bridge: Marvell Technology Group Ltd. Device 6828 (rev 04)
02:00.0 Network controller: Qualcomm Atheros QCA986x/988x 802.11ac
Wireless Network Adapter (rev ff)
So the other card is seen as pci device, but the intel is not. I am
really lost now.
^ permalink raw reply
* Re: Intel 7260 not working on 4.4.24 / armv7
From: Johannes Berg @ 2016-10-18 19:06 UTC (permalink / raw)
To: Oliver Zemann, linux-wireless
In-Reply-To: <fa098763-cdf6-03f8-6d75-0fa9dfb270e4@gmail.com>
On Tue, 2016-10-18 at 18:22 +0200, Oliver Zemann wrote:
> Because of the problems with the ath10 card, i bought an intel 7260
> (mpcie) wifi card. Unfortunately it is also not working.
> I get tons of those messages:
>
> [ 175.777030] usb 1-1: new full-speed USB device number 2 using
> orion-ehci
> [ 175.933953] usb 1-1: New USB device found, idVendor=8087,
> idProduct=07dc
> [ 175.940681] usb 1-1: New USB device strings: Mfr=0, Product=0,
> SerialNumber=0
> [ 175.966954] Bluetooth: hci0: read Intel version:
> 3707100180012d0d00
> [ 175.973313] Bluetooth: hci0: Intel Bluetooth firmware file:
> intel/ibt-hw-37.7.10-fw-1.80.1.2d.d.bseq
> [ 176.183954] Bluetooth: hci0: Intel Bluetooth firmware patch
> completed
> and activated
> [ 176.749831] usb 1-1: USB disconnect, device number 2
This is odd. However, it's entirely related to the NICs *Bluetooth*
function, which lives on USB.
> What's confusing me is that this device is connected through pcie,
> not usb. When i use lspci i get:
> [root@alarm log]# lspci
> 00:02.0 PCI bridge: Marvell Technology Group Ltd. Device 6828 (rev
> 04)
> 00:03.0 PCI bridge: Marvell Technology Group Ltd. Device 6828 (rev
> 04)
> 02:00.0 Network controller: Qualcomm Atheros QCA986x/988x 802.11ac
> Wireless Network Adapter (rev ff)
>
> So the other card is seen as pci device, but the intel is not. I am
> really lost now.
The NICs *WiFi* function should be a PCIe device, but the USB
connect/disconnect cycles suggest that there's something wrong with the
electrical connection, which presumably causes the PCIe part of the
device to never appear on the bus.
johannes
^ permalink raw reply
* Re: Intel 7260 not working on 4.4.24 / armv7
From: Johannes Berg @ 2016-10-18 19:09 UTC (permalink / raw)
To: Oliver Zemann, linux-wireless
In-Reply-To: <1476817578.6425.40.camel@sipsolutions.net>
On Tue, 2016-10-18 at 21:06 +0200, Johannes Berg wrote:
>
> The NICs *WiFi* function should be a PCIe device, but the USB
> connect/disconnect cycles suggest that there's something wrong with
> the
> electrical connection, which presumably causes the PCIe part of the
> device to never appear on the bus.
>
Also, FWIW, I had our later NIC (8260) running on an ARMv7 (a
Hummingboard Pro i2ex or so), in both little (default) and big endian
modes. I haven't tried the 7260 but conceivably could.
johannes
^ permalink raw reply
* Re: sequence diagrams in rst documentation
From: Johannes Berg @ 2016-10-18 19:20 UTC (permalink / raw)
To: Jani Nikula, Markus Heiser; +Cc: Jonathan Corbet, linux-wireless, linux-doc
In-Reply-To: <87eg3dvhdi.fsf@intel.com>
> This could probably be argued either way...
Yeah, I guess it could :)
> My view has been all along that we should prefer to use existing
> extensions written and maintained by others. Perhaps we (the kind of
> royal "we" of which I'm personally really not part of) could take on
> maintainership of some extensions in the interest of improving kernel
> documentation, but I think the goal should be that the extensions are
> maintained outside of the kernel tree, that the extensions are
> generally usable, and have a chance of attracting attention and
> contributions from outside of the kernel community. (Note that this
> doesn't preclude us from shipping the extensions in the kernel tree,
> as long as it's updated from the upstream, not forked.)
Right. I tend to agree, though in the particular case I'm looking at
we'd probably have to fork outside the kernel, forming a new upstream,
and then ship that version (or perhaps rewrite it, forming a new
upstream, and then ship that - doesn't matter all that much)
> (This is one part of me being unhappy about making it easy to run
> arbitrary scripts to produce documentation; those will never be
> generic, and we'll never be able to offload their maintenance outside
> of the kernel. We should not think that we have some really special
> needs in the kernel.)
I agree that we don't necessarily have any special needs (*), but in
cases like this (**) it does seem more practical to just ship the
plugin with the kernel. Whether or not a separate "upstream" is formed
for it could be a secondary question, although it does seem better to
do so.
(*) although not wanting to ship binary files *is* kinda special :)
(**) where the upstream is essentially dead (for all I can tell) and
severely limited to the point where a rewrite will be a better choice.
Anyway, I'll have to see if we (Intel Linux WiFi team) actually want to
do things this way. Using the existing blockdiag/seqdiag is practical
since it all exists already. OTOH, a simpler and better-looking
solution would also be nice, so if we do go this way I'll investigate
more what we can do around this.
johannes
^ permalink raw reply
* Re: Intel 7260 not working on 4.4.24 / armv7
From: Emmanuel Grumbach @ 2016-10-18 19:30 UTC (permalink / raw)
To: Oliver Zemann; +Cc: linux-wireless
In-Reply-To: <fa098763-cdf6-03f8-6d75-0fa9dfb270e4@gmail.com>
On Tue, Oct 18, 2016 at 7:22 PM, Oliver Zemann <oliver.zemann@gmail.com> wrote:
> Because of the problems with the ath10 card, i bought an intel 7260 (mpcie)
> wifi card. Unfortunately it is also not working.
> I get tons of those messages:
>
> [ 175.777030] usb 1-1: new full-speed USB device number 2 using orion-ehci
> [ 175.933953] usb 1-1: New USB device found, idVendor=8087, idProduct=07dc
> [ 175.940681] usb 1-1: New USB device strings: Mfr=0, Product=0,
> SerialNumber=0
> [ 175.966954] Bluetooth: hci0: read Intel version: 3707100180012d0d00
> [ 175.973313] Bluetooth: hci0: Intel Bluetooth firmware file:
> intel/ibt-hw-37.7.10-fw-1.80.1.2d.d.bseq
> [ 176.183954] Bluetooth: hci0: Intel Bluetooth firmware patch completed and
> activated
> [ 176.749831] usb 1-1: USB disconnect, device number 2
> [ 177.076993] usb 1-1: new full-speed USB device number 3 using orion-ehci
> [ 177.233953] usb 1-1: New USB device found, idVendor=8087, idProduct=07dc
> [ 177.240682] usb 1-1: New USB device strings: Mfr=0, Product=0,
> SerialNumber=0
> [ 177.266957] Bluetooth: hci0: read Intel version: 3707100180012d0d00
> [ 177.273316] Bluetooth: hci0: Intel Bluetooth firmware file:
> intel/ibt-hw-37.7.10-fw-1.80.1.2d.d.bseq
> [ 177.482955] Bluetooth: hci0: Intel Bluetooth firmware patch completed and
> activated
> [ 178.046910] usb 1-1: USB disconnect, device number 3
> [ 178.376958] usb 1-1: new full-speed USB device number 4 using orion-ehci
> [ 178.533954] usb 1-1: New USB device found, idVendor=8087, idProduct=07dc
> [ 178.540682] usb 1-1: New USB device strings: Mfr=0, Product=0,
> SerialNumber=0
Hmm... bad connectors? USB seems to think that the device keeps disconnecting.
But that's the BT part.
> some information about the card:
> Bus 001 Device 011: ID 8087:07dc Intel Corp.
> Couldn't open device, some information will be missing
> Device Descriptor:
> bLength 18
> bDescriptorType 1
> bcdUSB 2.00
> bDeviceClass 224 Wireless
> bDeviceSubClass 1 Radio Frequency
> bDeviceProtocol 1 Bluetooth
> bMaxPacketSize0 64
> idVendor 0x8087 Intel Corp.
> idProduct 0x07dc
> bcdDevice 0.01
> iManufacturer 0
> iProduct 0
> iSerial 0
> bNumConfigurations 1
> Configuration Descriptor:
> bLength 9
> bDescriptorType 2
> wTotalLength 177
> bNumInterfaces 2
> bConfigurationValue 1
> iConfiguration 0
> bmAttributes 0xe0
> Self Powered
> Remote Wakeup
> MaxPower 100mA
> Interface Descriptor:
> bLength 9
> bDescriptorType 4
> bInterfaceNumber 0
> bAlternateSetting 0
> bNumEndpoints 3
> bInterfaceClass 224 Wireless
> bInterfaceSubClass 1 Radio Frequency
> bInterfaceProtocol 1 Bluetooth
> iInterface 0
> Endpoint Descriptor:
> bLength 7
> bDescriptorType 5
> bEndpointAddress 0x81 EP 1 IN
> bmAttributes 3
> Transfer Type Interrupt
> Synch Type None
> Usage Type Data
> wMaxPacketSize 0x0040 1x 64 bytes
> bInterval 1
> Endpoint Descriptor:
> bLength 7
> bDescriptorType 5
> bEndpointAddress 0x02 EP 2 OUT
> bmAttributes 2
> Transfer Type Bulk
> Synch Type None
> Usage Type Data
> wMaxPacketSize 0x0040 1x 64 bytes
> bInterval 1
> Endpoint Descriptor:
> bLength 7
> bDescriptorType 5
> bEndpointAddress 0x82 EP 2 IN
> bmAttributes 2
> Transfer Type Bulk
> Synch Type None
> Usage Type Data
> wMaxPacketSize 0x0040 1x 64 bytes
> bInterval 1
> Interface Descriptor:
> bLength 9
> bDescriptorType 4
> bInterfaceNumber 1
> bAlternateSetting 0
> bNumEndpoints 2
> bInterfaceClass 224 Wireless
> bInterfaceSubClass 1 Radio Frequency
> bInterfaceProtocol 1 Bluetooth
> iInterface 0
> Endpoint Descriptor:
> bLength 7
> bDescriptorType 5
> bEndpointAddress 0x03 EP 3 OUT
> bmAttributes 1
> Transfer Type Isochronous
> Synch Type None
> Usage Type Data
> wMaxPacketSize 0x0000 1x 0 bytes
> bInterval 1
> Endpoint Descriptor:
> bLength 7
> bDescriptorType 5
> bEndpointAddress 0x83 EP 3 IN
> bmAttributes 1
> Transfer Type Isochronous
> Synch Type None
> Usage Type Data
> wMaxPacketSize 0x0000 1x 0 bytes
> bInterval 1
> Interface Descriptor:
> bLength 9
> bDescriptorType 4
> bInterfaceNumber 1
> bAlternateSetting 1
> bNumEndpoints 2
> bInterfaceClass 224 Wireless
> bInterfaceSubClass 1 Radio Frequency
> bInterfaceProtocol 1 Bluetooth
> iInterface 0
> Endpoint Descriptor:
> bLength 7
> bDescriptorType 5
> bEndpointAddress 0x03 EP 3 OUT
> bmAttributes 1
> Transfer Type Isochronous
> Synch Type None
> Usage Type Data
> wMaxPacketSize 0x0009 1x 9 bytes
> bInterval 1
> Endpoint Descriptor:
> bLength 7
> bDescriptorType 5
> bEndpointAddress 0x83 EP 3 IN
> bmAttributes 1
> Transfer Type Isochronous
> Synch Type None
> Usage Type Data
> wMaxPacketSize 0x0009 1x 9 bytes
> bInterval 1
> Interface Descriptor:
> bLength 9
> bDescriptorType 4
> bInterfaceNumber 1
> bAlternateSetting 2
> bNumEndpoints 2
> bInterfaceClass 224 Wireless
> bInterfaceSubClass 1 Radio Frequency
> bInterfaceProtocol 1 Bluetooth
> iInterface 0
> Endpoint Descriptor:
> bLength 7
> bDescriptorType 5
> bEndpointAddress 0x03 EP 3 OUT
> bmAttributes 1
> Transfer Type Isochronous
> Synch Type None
> Usage Type Data
> wMaxPacketSize 0x0011 1x 17 bytes
> bInterval 1
> Endpoint Descriptor:
> bLength 7
> bDescriptorType 5
> bEndpointAddress 0x83 EP 3 IN
> bmAttributes 1
> Transfer Type Isochronous
> Synch Type None
> Usage Type Data
> wMaxPacketSize 0x0011 1x 17 bytes
> bInterval 1
> Interface Descriptor:
> bLength 9
> bDescriptorType 4
> bInterfaceNumber 1
> bAlternateSetting 3
> bNumEndpoints 2
> bInterfaceClass 224 Wireless
> bInterfaceSubClass 1 Radio Frequency
> bInterfaceProtocol 1 Bluetooth
> iInterface 0
> Endpoint Descriptor:
> bLength 7
> bDescriptorType 5
> bEndpointAddress 0x03 EP 3 OUT
> bmAttributes 1
> Transfer Type Isochronous
> Synch Type None
> Usage Type Data
> wMaxPacketSize 0x0019 1x 25 bytes
> bInterval 1
> Endpoint Descriptor:
> bLength 7
> bDescriptorType 5
> bEndpointAddress 0x83 EP 3 IN
> bmAttributes 1
> Transfer Type Isochronous
> Synch Type None
> Usage Type Data
> wMaxPacketSize 0x0019 1x 25 bytes
> bInterval 1
> Interface Descriptor:
> bLength 9
> bDescriptorType 4
> bInterfaceNumber 1
> bAlternateSetting 4
> bNumEndpoints 2
> bInterfaceClass 224 Wireless
> bInterfaceSubClass 1 Radio Frequency
> bInterfaceProtocol 1 Bluetooth
> iInterface 0
> Endpoint Descriptor:
> bLength 7
> bDescriptorType 5
> bEndpointAddress 0x03 EP 3 OUT
> bmAttributes 1
> Transfer Type Isochronous
> Synch Type None
> Usage Type Data
> wMaxPacketSize 0x0021 1x 33 bytes
> bInterval 1
> Endpoint Descriptor:
> bLength 7
> bDescriptorType 5
> bEndpointAddress 0x83 EP 3 IN
> bmAttributes 1
> Transfer Type Isochronous
> Synch Type None
> Usage Type Data
> wMaxPacketSize 0x0021 1x 33 bytes
> bInterval 1
> Interface Descriptor:
> bLength 9
> bDescriptorType 4
> bInterfaceNumber 1
> bAlternateSetting 5
> bNumEndpoints 2
> bInterfaceClass 224 Wireless
> bInterfaceSubClass 1 Radio Frequency
> bInterfaceProtocol 1 Bluetooth
> iInterface 0
> Endpoint Descriptor:
> bLength 7
> bDescriptorType 5
> bEndpointAddress 0x03 EP 3 OUT
> bmAttributes 1
> Transfer Type Isochronous
> Synch Type None
> Usage Type Data
> wMaxPacketSize 0x0031 1x 49 bytes
> bInterval 1
> Endpoint Descriptor:
> bLength 7
> bDescriptorType 5
> bEndpointAddress 0x83 EP 3 IN
> bmAttributes 1
> Transfer Type Isochronous
> Synch Type None
> Usage Type Data
> wMaxPacketSize 0x0031 1x 49 bytes
> bInterval 1
>
>
> [root@alarm log]# uname -a
> Linux alarm 4.4.24-2-ARCH #1 SMP Fri Oct 14 01:04:22 MDT 2016 armv7l
> GNU/Linux
>
> What's confusing me is that this device is connected through pcie, not usb.
> When i use lspci i get:
> [root@alarm log]# lspci
> 00:02.0 PCI bridge: Marvell Technology Group Ltd. Device 6828 (rev 04)
> 00:03.0 PCI bridge: Marvell Technology Group Ltd. Device 6828 (rev 04)
> 02:00.0 Network controller: Qualcomm Atheros QCA986x/988x 802.11ac Wireless
> Network Adapter (rev ff)
>
> So the other card is seen as pci device, but the intel is not. I am really
> lost now.
So is the NIC :) It is lost. If it doesn't appear in the enumeration,
it seems you have a bad platform issue. the arm thing in your uname -a
hints me that you can't really talk your OEM, right?
^ permalink raw reply
* Re: Intel 7260 not working on 4.4.24 / armv7
From: Oliver Zemann @ 2016-10-18 19:31 UTC (permalink / raw)
Cc: linux-wireless
In-Reply-To: <CANUX_P1CaQZwc-=L4U9n+n5kfXW7H3-L05EDeXFYVvh2fddO8A@mail.gmail.com>
I tried 2 of those wifi cards. Both behaved the same. Also on another
clearfog pro. So i guess this is not a hardware fault. Also, the compex
WLE600 works (unfortunately the WLE900 does not).
Am 18.10.2016 um 21:30 schrieb Emmanuel Grumbach:
> On Tue, Oct 18, 2016 at 7:22 PM, Oliver Zemann <oliver.zemann@gmail.com> wrote:
>> Because of the problems with the ath10 card, i bought an intel 7260 (mpcie)
>> wifi card. Unfortunately it is also not working.
>> I get tons of those messages:
>>
>> [ 175.777030] usb 1-1: new full-speed USB device number 2 using orion-ehci
>> [ 175.933953] usb 1-1: New USB device found, idVendor=8087, idProduct=07dc
>> [ 175.940681] usb 1-1: New USB device strings: Mfr=0, Product=0,
>> SerialNumber=0
>> [ 175.966954] Bluetooth: hci0: read Intel version: 3707100180012d0d00
>> [ 175.973313] Bluetooth: hci0: Intel Bluetooth firmware file:
>> intel/ibt-hw-37.7.10-fw-1.80.1.2d.d.bseq
>> [ 176.183954] Bluetooth: hci0: Intel Bluetooth firmware patch completed and
>> activated
>> [ 176.749831] usb 1-1: USB disconnect, device number 2
>> [ 177.076993] usb 1-1: new full-speed USB device number 3 using orion-ehci
>> [ 177.233953] usb 1-1: New USB device found, idVendor=8087, idProduct=07dc
>> [ 177.240682] usb 1-1: New USB device strings: Mfr=0, Product=0,
>> SerialNumber=0
>> [ 177.266957] Bluetooth: hci0: read Intel version: 3707100180012d0d00
>> [ 177.273316] Bluetooth: hci0: Intel Bluetooth firmware file:
>> intel/ibt-hw-37.7.10-fw-1.80.1.2d.d.bseq
>> [ 177.482955] Bluetooth: hci0: Intel Bluetooth firmware patch completed and
>> activated
>> [ 178.046910] usb 1-1: USB disconnect, device number 3
>> [ 178.376958] usb 1-1: new full-speed USB device number 4 using orion-ehci
>> [ 178.533954] usb 1-1: New USB device found, idVendor=8087, idProduct=07dc
>> [ 178.540682] usb 1-1: New USB device strings: Mfr=0, Product=0,
>> SerialNumber=0
> Hmm... bad connectors? USB seems to think that the device keeps disconnecting.
> But that's the BT part.
>
>> some information about the card:
>> Bus 001 Device 011: ID 8087:07dc Intel Corp.
>> Couldn't open device, some information will be missing
>> Device Descriptor:
>> bLength 18
>> bDescriptorType 1
>> bcdUSB 2.00
>> bDeviceClass 224 Wireless
>> bDeviceSubClass 1 Radio Frequency
>> bDeviceProtocol 1 Bluetooth
>> bMaxPacketSize0 64
>> idVendor 0x8087 Intel Corp.
>> idProduct 0x07dc
>> bcdDevice 0.01
>> iManufacturer 0
>> iProduct 0
>> iSerial 0
>> bNumConfigurations 1
>> Configuration Descriptor:
>> bLength 9
>> bDescriptorType 2
>> wTotalLength 177
>> bNumInterfaces 2
>> bConfigurationValue 1
>> iConfiguration 0
>> bmAttributes 0xe0
>> Self Powered
>> Remote Wakeup
>> MaxPower 100mA
>> Interface Descriptor:
>> bLength 9
>> bDescriptorType 4
>> bInterfaceNumber 0
>> bAlternateSetting 0
>> bNumEndpoints 3
>> bInterfaceClass 224 Wireless
>> bInterfaceSubClass 1 Radio Frequency
>> bInterfaceProtocol 1 Bluetooth
>> iInterface 0
>> Endpoint Descriptor:
>> bLength 7
>> bDescriptorType 5
>> bEndpointAddress 0x81 EP 1 IN
>> bmAttributes 3
>> Transfer Type Interrupt
>> Synch Type None
>> Usage Type Data
>> wMaxPacketSize 0x0040 1x 64 bytes
>> bInterval 1
>> Endpoint Descriptor:
>> bLength 7
>> bDescriptorType 5
>> bEndpointAddress 0x02 EP 2 OUT
>> bmAttributes 2
>> Transfer Type Bulk
>> Synch Type None
>> Usage Type Data
>> wMaxPacketSize 0x0040 1x 64 bytes
>> bInterval 1
>> Endpoint Descriptor:
>> bLength 7
>> bDescriptorType 5
>> bEndpointAddress 0x82 EP 2 IN
>> bmAttributes 2
>> Transfer Type Bulk
>> Synch Type None
>> Usage Type Data
>> wMaxPacketSize 0x0040 1x 64 bytes
>> bInterval 1
>> Interface Descriptor:
>> bLength 9
>> bDescriptorType 4
>> bInterfaceNumber 1
>> bAlternateSetting 0
>> bNumEndpoints 2
>> bInterfaceClass 224 Wireless
>> bInterfaceSubClass 1 Radio Frequency
>> bInterfaceProtocol 1 Bluetooth
>> iInterface 0
>> Endpoint Descriptor:
>> bLength 7
>> bDescriptorType 5
>> bEndpointAddress 0x03 EP 3 OUT
>> bmAttributes 1
>> Transfer Type Isochronous
>> Synch Type None
>> Usage Type Data
>> wMaxPacketSize 0x0000 1x 0 bytes
>> bInterval 1
>> Endpoint Descriptor:
>> bLength 7
>> bDescriptorType 5
>> bEndpointAddress 0x83 EP 3 IN
>> bmAttributes 1
>> Transfer Type Isochronous
>> Synch Type None
>> Usage Type Data
>> wMaxPacketSize 0x0000 1x 0 bytes
>> bInterval 1
>> Interface Descriptor:
>> bLength 9
>> bDescriptorType 4
>> bInterfaceNumber 1
>> bAlternateSetting 1
>> bNumEndpoints 2
>> bInterfaceClass 224 Wireless
>> bInterfaceSubClass 1 Radio Frequency
>> bInterfaceProtocol 1 Bluetooth
>> iInterface 0
>> Endpoint Descriptor:
>> bLength 7
>> bDescriptorType 5
>> bEndpointAddress 0x03 EP 3 OUT
>> bmAttributes 1
>> Transfer Type Isochronous
>> Synch Type None
>> Usage Type Data
>> wMaxPacketSize 0x0009 1x 9 bytes
>> bInterval 1
>> Endpoint Descriptor:
>> bLength 7
>> bDescriptorType 5
>> bEndpointAddress 0x83 EP 3 IN
>> bmAttributes 1
>> Transfer Type Isochronous
>> Synch Type None
>> Usage Type Data
>> wMaxPacketSize 0x0009 1x 9 bytes
>> bInterval 1
>> Interface Descriptor:
>> bLength 9
>> bDescriptorType 4
>> bInterfaceNumber 1
>> bAlternateSetting 2
>> bNumEndpoints 2
>> bInterfaceClass 224 Wireless
>> bInterfaceSubClass 1 Radio Frequency
>> bInterfaceProtocol 1 Bluetooth
>> iInterface 0
>> Endpoint Descriptor:
>> bLength 7
>> bDescriptorType 5
>> bEndpointAddress 0x03 EP 3 OUT
>> bmAttributes 1
>> Transfer Type Isochronous
>> Synch Type None
>> Usage Type Data
>> wMaxPacketSize 0x0011 1x 17 bytes
>> bInterval 1
>> Endpoint Descriptor:
>> bLength 7
>> bDescriptorType 5
>> bEndpointAddress 0x83 EP 3 IN
>> bmAttributes 1
>> Transfer Type Isochronous
>> Synch Type None
>> Usage Type Data
>> wMaxPacketSize 0x0011 1x 17 bytes
>> bInterval 1
>> Interface Descriptor:
>> bLength 9
>> bDescriptorType 4
>> bInterfaceNumber 1
>> bAlternateSetting 3
>> bNumEndpoints 2
>> bInterfaceClass 224 Wireless
>> bInterfaceSubClass 1 Radio Frequency
>> bInterfaceProtocol 1 Bluetooth
>> iInterface 0
>> Endpoint Descriptor:
>> bLength 7
>> bDescriptorType 5
>> bEndpointAddress 0x03 EP 3 OUT
>> bmAttributes 1
>> Transfer Type Isochronous
>> Synch Type None
>> Usage Type Data
>> wMaxPacketSize 0x0019 1x 25 bytes
>> bInterval 1
>> Endpoint Descriptor:
>> bLength 7
>> bDescriptorType 5
>> bEndpointAddress 0x83 EP 3 IN
>> bmAttributes 1
>> Transfer Type Isochronous
>> Synch Type None
>> Usage Type Data
>> wMaxPacketSize 0x0019 1x 25 bytes
>> bInterval 1
>> Interface Descriptor:
>> bLength 9
>> bDescriptorType 4
>> bInterfaceNumber 1
>> bAlternateSetting 4
>> bNumEndpoints 2
>> bInterfaceClass 224 Wireless
>> bInterfaceSubClass 1 Radio Frequency
>> bInterfaceProtocol 1 Bluetooth
>> iInterface 0
>> Endpoint Descriptor:
>> bLength 7
>> bDescriptorType 5
>> bEndpointAddress 0x03 EP 3 OUT
>> bmAttributes 1
>> Transfer Type Isochronous
>> Synch Type None
>> Usage Type Data
>> wMaxPacketSize 0x0021 1x 33 bytes
>> bInterval 1
>> Endpoint Descriptor:
>> bLength 7
>> bDescriptorType 5
>> bEndpointAddress 0x83 EP 3 IN
>> bmAttributes 1
>> Transfer Type Isochronous
>> Synch Type None
>> Usage Type Data
>> wMaxPacketSize 0x0021 1x 33 bytes
>> bInterval 1
>> Interface Descriptor:
>> bLength 9
>> bDescriptorType 4
>> bInterfaceNumber 1
>> bAlternateSetting 5
>> bNumEndpoints 2
>> bInterfaceClass 224 Wireless
>> bInterfaceSubClass 1 Radio Frequency
>> bInterfaceProtocol 1 Bluetooth
>> iInterface 0
>> Endpoint Descriptor:
>> bLength 7
>> bDescriptorType 5
>> bEndpointAddress 0x03 EP 3 OUT
>> bmAttributes 1
>> Transfer Type Isochronous
>> Synch Type None
>> Usage Type Data
>> wMaxPacketSize 0x0031 1x 49 bytes
>> bInterval 1
>> Endpoint Descriptor:
>> bLength 7
>> bDescriptorType 5
>> bEndpointAddress 0x83 EP 3 IN
>> bmAttributes 1
>> Transfer Type Isochronous
>> Synch Type None
>> Usage Type Data
>> wMaxPacketSize 0x0031 1x 49 bytes
>> bInterval 1
>>
>>
>> [root@alarm log]# uname -a
>> Linux alarm 4.4.24-2-ARCH #1 SMP Fri Oct 14 01:04:22 MDT 2016 armv7l
>> GNU/Linux
>>
>> What's confusing me is that this device is connected through pcie, not usb.
>> When i use lspci i get:
>> [root@alarm log]# lspci
>> 00:02.0 PCI bridge: Marvell Technology Group Ltd. Device 6828 (rev 04)
>> 00:03.0 PCI bridge: Marvell Technology Group Ltd. Device 6828 (rev 04)
>> 02:00.0 Network controller: Qualcomm Atheros QCA986x/988x 802.11ac Wireless
>> Network Adapter (rev ff)
>>
>> So the other card is seen as pci device, but the intel is not. I am really
>> lost now.
> So is the NIC :) It is lost. If it doesn't appear in the enumeration,
> it seems you have a bad platform issue. the arm thing in your uname -a
> hints me that you can't really talk your OEM, right?
^ permalink raw reply
* Re: Intel 7260 not working on 4.4.24 / armv7
From: Oliver Zemann @ 2016-10-18 19:44 UTC (permalink / raw)
To: linux-wireless
In-Reply-To: <1476817578.6425.40.camel@sipsolutions.net>
Is there some way to disable the bluetooth functionality?
Am 18.10.2016 um 21:06 schrieb Johannes Berg:
> On Tue, 2016-10-18 at 18:22 +0200, Oliver Zemann wrote:
>> Because of the problems with the ath10 card, i bought an intel 7260
>> (mpcie) wifi card. Unfortunately it is also not working.
>> I get tons of those messages:
>>
>> [ 175.777030] usb 1-1: new full-speed USB device number 2 using
>> orion-ehci
>> [ 175.933953] usb 1-1: New USB device found, idVendor=8087,
>> idProduct=07dc
>> [ 175.940681] usb 1-1: New USB device strings: Mfr=0, Product=0,
>> SerialNumber=0
>> [ 175.966954] Bluetooth: hci0: read Intel version:
>> 3707100180012d0d00
>> [ 175.973313] Bluetooth: hci0: Intel Bluetooth firmware file:
>> intel/ibt-hw-37.7.10-fw-1.80.1.2d.d.bseq
>> [ 176.183954] Bluetooth: hci0: Intel Bluetooth firmware patch
>> completed
>> and activated
>> [ 176.749831] usb 1-1: USB disconnect, device number 2
> This is odd. However, it's entirely related to the NICs *Bluetooth*
> function, which lives on USB.
>
>> What's confusing me is that this device is connected through pcie,
>> not usb. When i use lspci i get:
>> [root@alarm log]# lspci
>> 00:02.0 PCI bridge: Marvell Technology Group Ltd. Device 6828 (rev
>> 04)
>> 00:03.0 PCI bridge: Marvell Technology Group Ltd. Device 6828 (rev
>> 04)
>> 02:00.0 Network controller: Qualcomm Atheros QCA986x/988x 802.11ac
>> Wireless Network Adapter (rev ff)
>>
>> So the other card is seen as pci device, but the intel is not. I am
>> really lost now.
> The NICs *WiFi* function should be a PCIe device, but the USB
> connect/disconnect cycles suggest that there's something wrong with the
> electrical connection, which presumably causes the PCIe part of the
> device to never appear on the bus.
>
> johannes
^ permalink raw reply
* Re: Intel 7260 not working on 4.4.24 / armv7
From: Johannes Berg @ 2016-10-18 19:56 UTC (permalink / raw)
To: Oliver Zemann, linux-wireless
In-Reply-To: <1dce4f5d-b905-9f26-17f3-d8b1ae0d1b13@gmail.com>
On Tue, 2016-10-18 at 21:44 +0200, Oliver Zemann wrote:
> Is there some way to disable the bluetooth functionality?
>
Not that I know of. It's kinda pointless though since you then wouldn't
have any functionality anyway?
I don't have the board you mentioned to Emmanuel, but I can try the
7260 on the Hummingboard.
I do know that, for example, on my old G5 powermac the newer Intel NICs
cause the system to be unable boot, so there sometimes are PCIe bus
incompatibilities.
johannes
(please quote properly)
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox