pull-request: mac80211 2016-10-18
Hi Dave, 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. Thanks, johannes The following changes since commit 6b25e21fa6f26d0f0d45f161d169029411c84286: Merge tag 'drm-for-v4.9' of git://people.freedesktop.org/~airlied/linux (2016-10-11 18:12:22 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211.git tags/mac80211-for-davem-2016-10-18 for you to fetch changes up to f4a067f9ffca603b45f7e82ddd2ba50e5904cea3: mac80211: move struct aead_req off the stack (2016-10-17 16:14:04 +0200) This is relatively small, mostly to get the SG/crypto from stack removal fix that crashes things when VMAP stack is used in conjunction with software crypto. Aside from that, we have: * a fix for AP_VLAN usage with the nl80211 frame command * two fixes (and two preparation patches) for A-MSDU, one to discard group-addressed (multicast) and unexpected 4-address A-MSDUs, the other to validate A-MSDU inner MAC addresses properly to prevent controlled port bypass Ard Biesheuvel (1): mac80211: move struct aead_req off the stack Johannes Berg (4): mac80211: discard multicast and 4-addr A-MSDUs cfg80211: let ieee80211_amsdu_to_8023s() take only header-less SKB cfg80211: add ability to check DA/SA in A-MSDU decapsulation mac80211: validate DA/SA during A-MSDU decapsulation Michael Braun (1): mac80211: fix CMD_FRAME for AP_VLAN .../net/wireless/marvell/mwifiex/11n_rxreorder.c | 2 +- include/net/cfg80211.h | 32 ++ net/mac80211/aes_ccm.c | 46 --- net/mac80211/aes_ccm.h | 8 ++-- net/mac80211/aes_gcm.c | 43 +++--- net/mac80211/aes_gcm.h | 6 ++- net/mac80211/aes_gmac.c| 26 +-- net/mac80211/aes_gmac.h| 4 ++ net/mac80211/offchannel.c | 2 +- net/mac80211/rx.c | 51 +- net/mac80211/wpa.c | 22 -- net/wireless/util.c| 34 +++ 12 files changed, 175 insertions(+), 101 deletions(-)
[PATCH] wireless: deprecate WDS and disable by default
From: Johannes Berg The old WDS 4-addr frame support is very limited, e.g. * no encryption is possible on such links * it cannot support rate/HT/VHT negotiation * management APIs are very restricted These make the WDS legacy mode useless in practice. All of these are resolved by the 4-addr AP/client support, so there's also no reason to improve WDS in the future. Therefore, add a Kconfig option to disable legacy WDS. This gives people an "emergency valve" while they migrate to the better-supported 4-addr AP/client option; we plan to remove it (and the associated cfg80211/mac80211 code, which is the ultimate goal) in the future. Signed-off-by: Johannes Berg --- drivers/net/wireless/Kconfig | 13 + drivers/net/wireless/ath/ath9k/init.c | 6 ++ drivers/net/wireless/broadcom/b43/main.c | 2 ++ drivers/net/wireless/broadcom/b43legacy/main.c | 2 ++ drivers/net/wireless/ralink/rt2x00/rt2x00dev.c | 6 -- net/wireless/core.c| 10 ++ 6 files changed, 37 insertions(+), 2 deletions(-) diff --git a/drivers/net/wireless/Kconfig b/drivers/net/wireless/Kconfig index 8c8edaf1bba6..fa9c4fa9477e 100644 --- a/drivers/net/wireless/Kconfig +++ b/drivers/net/wireless/Kconfig @@ -17,6 +17,19 @@ menuconfig WLAN if WLAN +config WIRELESS_WDS + bool "mac80211-based legacy WDS support" + help + This option enables the deprecated WDS support, the newer + mac80211-based 4-addr AP/client support supersedes it with + a much better feature set (HT, VHT, ...) + + We plan to remove this option and code, so if you find + that you have to enable it, please let us know on the + linux-wireless@vger.kernel.org mailing list, so we can + help you migrate to 4-addr AP/client (or, if it's really + necessary, give up on our plan of removing it). + source "drivers/net/wireless/admtek/Kconfig" source "drivers/net/wireless/ath/Kconfig" source "drivers/net/wireless/atmel/Kconfig" diff --git a/drivers/net/wireless/ath/ath9k/init.c b/drivers/net/wireless/ath/ath9k/init.c index cfa3fe82ade3..368d9b313823 100644 --- a/drivers/net/wireless/ath/ath9k/init.c +++ b/drivers/net/wireless/ath/ath9k/init.c @@ -734,9 +734,11 @@ static const struct ieee80211_iface_limit if_limits[] = { BIT(NL80211_IFTYPE_P2P_GO) }, }; +#ifdef CONFIG_WIRELESS_WDS static const struct ieee80211_iface_limit wds_limits[] = { { .max = 2048, .types = BIT(NL80211_IFTYPE_WDS) }, }; +#endif #ifdef CONFIG_ATH9K_CHANNEL_CONTEXT @@ -774,6 +776,7 @@ static const struct ieee80211_iface_combination if_comb[] = { BIT(NL80211_CHAN_WIDTH_40), #endif }, +#ifdef CONFIG_WIRELESS_WDS { .limits = wds_limits, .n_limits = ARRAY_SIZE(wds_limits), @@ -781,6 +784,7 @@ static const struct ieee80211_iface_combination if_comb[] = { .num_different_channels = 1, .beacon_int_infra_match = true, }, +#endif }; #ifdef CONFIG_ATH9K_CHANNEL_CONTEXT @@ -851,7 +855,9 @@ static void ath9k_set_hw_capab(struct ath_softc *sc, struct ieee80211_hw *hw) BIT(NL80211_IFTYPE_STATION) | BIT(NL80211_IFTYPE_ADHOC) | BIT(NL80211_IFTYPE_MESH_POINT) | +#ifdef CONFIG_WIRELESS_WDS BIT(NL80211_IFTYPE_WDS) | +#endif BIT(NL80211_IFTYPE_OCB); if (ath9k_is_chanctx_enabled()) diff --git a/drivers/net/wireless/broadcom/b43/main.c b/drivers/net/wireless/broadcom/b43/main.c index 6e5d9095b195..52f3541ecbcf 100644 --- a/drivers/net/wireless/broadcom/b43/main.c +++ b/drivers/net/wireless/broadcom/b43/main.c @@ -5591,7 +5591,9 @@ static struct b43_wl *b43_wireless_init(struct b43_bus_dev *dev) BIT(NL80211_IFTYPE_AP) | BIT(NL80211_IFTYPE_MESH_POINT) | BIT(NL80211_IFTYPE_STATION) | +#ifdef CONFIG_WIRELESS_WDS BIT(NL80211_IFTYPE_WDS) | +#endif BIT(NL80211_IFTYPE_ADHOC); hw->wiphy->flags |= WIPHY_FLAG_IBSS_RSN; diff --git a/drivers/net/wireless/broadcom/b43legacy/main.c b/drivers/net/wireless/broadcom/b43legacy/main.c index 83770d2ea057..e97ab2b91663 100644 --- a/drivers/net/wireless/broadcom/b43legacy/main.c +++ b/drivers/net/wireless/broadcom/b43legacy/main.c @@ -3838,7 +3838,9 @@ static int b43legacy_wireless_init(struct ssb_device *dev) hw->wiphy->interface_modes = BIT(NL80211_IFTYPE_AP) | BIT(NL80211_IFTYPE_STATION) | +#ifdef CONFIG_WIRELESS_WDS BIT(NL80211_IFTYPE_WDS) | +#endif BIT(NL80211_IFTYPE_ADHOC); hw->queues = 1; /* FIXME: hardware has more queues */ hw->max_rates = 2; diff --git a/drivers/net/wireless/ralink/rt2x00/rt2x00dev.c b/drivers/net/wireless/ralink/rt2x
[NOT FOR MERGE] ath9k: work around key cache corruption
From: Antonio Quartulli This patch was crafted long time ago to work around a key cache corruption problem on ath9k chipsets. The workaround consists in periodically triggering a worker that uploads all the keys to the HW cache. The worker is triggered also when the vif detects 21 undecryptable packets. This patch is based on top compat-wireless-2015-10-26. I was asked to release this code to the public and, since it is GPL, I am now doing it. Signed-off-by: Antonio Quartulli --- drivers/net/wireless/ath/ath.h | 11 +++ drivers/net/wireless/ath/ath9k/ath9k.h | 7 ++ drivers/net/wireless/ath/ath9k/init.c | 1 + drivers/net/wireless/ath/ath9k/main.c | 21 + drivers/net/wireless/ath/ath9k/recv.c | 25 ++ drivers/net/wireless/ath/key.c | 149 + include/net/mac80211.h | 4 + net/mac80211/key.c | 22 ++--- net/mac80211/key.h | 1 + net/mac80211/sta_info.c| 13 +++ 10 files changed, 243 insertions(+), 11 deletions(-) diff --git a/drivers/net/wireless/ath/ath.h b/drivers/net/wireless/ath/ath.h index 91eeca5..85377bc 100644 --- a/drivers/net/wireless/ath/ath.h +++ b/drivers/net/wireless/ath/ath.h @@ -187,6 +187,13 @@ struct ath_common { int last_rssi; struct ieee80211_supported_band sbands[IEEE80211_NUM_BANDS]; + + struct { + struct mutex mtx; + atomic_t running; + void (*refresh_cb)(struct ieee80211_sta *sta); + struct work_struct refresh_work; + } key_cache; }; static inline const struct ath_ps_ops *ath_ps_ops(struct ath_common *common) @@ -201,10 +208,14 @@ bool ath_is_mybeacon(struct ath_common *common, struct ieee80211_hdr *hdr); void ath_hw_setbssidmask(struct ath_common *common); void ath_key_delete(struct ath_common *common, struct ieee80211_key_conf *key); +void ath_keys_config(struct ath_common *common); int ath_key_config(struct ath_common *common, struct ieee80211_vif *vif, struct ieee80211_sta *sta, struct ieee80211_key_conf *key); +void ath_key_refresher_init(struct ath_common *common, + void (*cb)(struct ieee80211_sta *sta)); +void ath_key_refresher_start(struct ath_common *common); bool ath_hw_keyreset(struct ath_common *common, u16 entry); void ath_hw_cycle_counters_update(struct ath_common *common); int32_t ath_hw_get_listen_time(struct ath_common *common); diff --git a/drivers/net/wireless/ath/ath9k/ath9k.h b/drivers/net/wireless/ath/ath9k/ath9k.h index 0aab323..3930962 100644 --- a/drivers/net/wireless/ath/ath9k/ath9k.h +++ b/drivers/net/wireless/ath/ath9k/ath9k.h @@ -23,6 +23,8 @@ #include #include #include +#include +#include #include "common.h" #include "debug.h" @@ -38,6 +40,8 @@ extern int ath9k_led_blink; extern bool is_ath9k_unloaded; extern int ath9k_use_chanctx; +#define ATH_RX_DEC_MAX_ERR 20 + /*/ /* Descriptor Management */ /*/ @@ -266,6 +270,8 @@ struct ath_node { #endif u8 key_idx[4]; + atomic_t decrypt_errors; + u32 ackto; struct list_head list; }; @@ -584,6 +590,7 @@ void ath9k_release_buffered_frames(struct ieee80211_hw *hw, u16 tids, int nframes, enum ieee80211_frame_release_type reason, bool more_data); +void ath9k_refresh_iter(struct ieee80211_sta *sta); // /* VIFs */ diff --git a/drivers/net/wireless/ath/ath9k/init.c b/drivers/net/wireless/ath/ath9k/init.c index 1b57d12..adec135 100644 --- a/drivers/net/wireless/ath/ath9k/init.c +++ b/drivers/net/wireless/ath/ath9k/init.c @@ -612,6 +612,7 @@ static int ath9k_init_softc(u16 devid, struct ath_softc *sc, common->bt_ant_diversity = 1; spin_lock_init(&common->cc_lock); + ath_key_refresher_init(common, ath9k_refresh_iter); spin_lock_init(&sc->sc_serial_rw); spin_lock_init(&sc->sc_pm_lock); spin_lock_init(&sc->chan_lock); diff --git a/drivers/net/wireless/ath/ath9k/main.c b/drivers/net/wireless/ath/ath9k/main.c index 56520ac..8ddb0e0 100644 --- a/drivers/net/wireless/ath/ath9k/main.c +++ b/drivers/net/wireless/ath/ath9k/main.c @@ -16,6 +16,7 @@ #include #include +#include #include "ath9k.h" #include "btcoex.h" @@ -1690,6 +1691,9 @@ static int ath9k_set_key(struct ieee80211_hw *hw, if (sta) an = (struct ath_node *)sta->drv_priv; + if (sta) + an = (struct ath_node *)sta->drv_priv; + switch (cmd) { case SET_KEY: if (sta) @@ -1717,6 +1721,14 @@ static int ath9k_set_key(struct ieee80211_hw *hw, } WARN_ON(i == ARRAY_SIZE(an->key_idx)); } + /* QCA
[PATCHv2 0/2] ath10k: add support for tx bitrate
From: Anilkumar Kolli 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
[PATCHv2 0/2] ath10k: add support for tx bitrate
From: Anilkumar Kolli 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
[PATCH 1/2] ath10k: add per peer htt tx stats support for 10.4
From: Anilkumar Kolli 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 --- 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_
[PATCHv2 2/2] ath10k: add support for per sta tx bitrate
From: Anilkumar Kolli Per STA tx bitrate info is filled from peer stats. Export per sta txrate info to cfg80211/nl80211 Signed-off-by: Anilkumar Kolli --- 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
[PATCHv2 0/2] ath10k: add support for tx bitrate
From: Anilkumar Kolli 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
[PATCHv2 1/2] ath10k: add per peer htt tx stats support for 10.4
From: Anilkumar Kolli 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 --- 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_
sequence diagrams in rst documentation
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
Re: sequence diagrams in rst documentation
Am 18.10.2016 um 13:43 schrieb Johannes Berg : > 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 majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: sequence diagrams in rst documentation
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
Re: [RFC PATCH 2/2] mac80211: aes_ccm: cache AEAD request structures per CPU
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
[RFC PATCH 1/2] mac80211: aes_ccm: prepare key struct for storing context data
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 --- 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 +#include #include #include #include @@ -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_LEN32 -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_ae
[RFC PATCH 0/2] mac80211: aes_ccm: cache AEAD request allocations per CPU
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
[RFC PATCH 2/2] mac80211: aes_ccm: cache AEAD request structures per CPU
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 --- 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 */ } c
Re: [RFC PATCH 2/2] mac80211: aes_ccm: cache AEAD request structures per CPU
On 18 October 2016 at 15:16, Johannes Berg 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
Re: pull-request: mac80211 2016-10-18
From: Johannes Berg 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.
Re: [RFC PATCH 2/2] mac80211: aes_ccm: cache AEAD request structures per CPU
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
Re: [RFC PATCH 2/2] mac80211: aes_ccm: cache AEAD request structures per CPU
On 18 October 2016 at 15:24, Johannes Berg 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?
Re: sequence diagrams in rst documentation
On Tue, 18 Oct 2016, Johannes Berg 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-28154b16b...@redhat.com -- Jani Nikula, Intel Open Source Technology Center
Re: [PATCH v8 1/3] Documentation: dt: net: add ath9k wireless device binding
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 > --- > .../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
Intel 7260 not working on 4.4.24 / armv7
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-f
Re: Intel 7260 not working on 4.4.24 / armv7
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
Re: Intel 7260 not working on 4.4.24 / armv7
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
Re: sequence diagrams in rst documentation
> 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
Re: Intel 7260 not working on 4.4.24 / armv7
On Tue, Oct 18, 2016 at 7:22 PM, 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 > [ 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: > bLength18 > bDescriptorType 1 > bcdUSB 2.00 > bDeviceClass 224 Wireless > bDeviceSubClass 1 Radio Frequency > bDeviceProtocol 1 Bluetooth > bMaxPacketSize064 > idVendor 0x8087 Intel Corp. > idProduct 0x07dc > bcdDevice0.01 > iManufacturer 0 > iProduct0 > 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 > bInterfaceNumber0 > 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 > bmAttributes3 > Transfer TypeInterrupt > Synch Type None > Usage Type Data > wMaxPacketSize 0x0040 1x 64 bytes > bInterval 1 > Endpoint Descriptor: > bLength 7 > bDescriptorType 5 > bEndpointAddress 0x02 EP 2 OUT > bmAttributes2 > Transfer TypeBulk > Synch Type None > Usage Type Data > wMaxPacketSize 0x0040 1x 64 bytes > bInterval 1 > Endpoint Descriptor: > bLength 7 > bDescriptorType 5 > bEndpointAddress 0x82 EP 2 IN > bmAttributes2 > Transfer TypeBulk > Synch Type None > Usage Type Data > wMaxPacketSize 0x0040 1x 64 bytes > bInterval 1 > Interface Descriptor: > bLength 9 > bDescriptorType 4 > bInterfaceNumber1 > 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 > bmAttributes1 > Transfer TypeIsochronous > Synch Type None > Usage Type Data > wMaxPacketSize 0x 1x 0 bytes > bInterval 1 > Endp
Re: Intel 7260 not working on 4.4.24 / armv7
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 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: bLength18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass 224 Wireless bDeviceSubClass 1 Radio Frequency bDeviceProtocol 1 Bluetooth bMaxPacketSize064 idVendor 0x8087 Intel Corp. idProduct 0x07dc bcdDevice0.01 iManufacturer 0 iProduct0 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 bInterfaceNumber0 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 bmAttributes3 Transfer TypeInterrupt Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 1 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x02 EP 2 OUT bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 1 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x82 EP 2 IN bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 1 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber1 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 bmAttributes1 Transfer TypeIsochronous Synch Type None Usage Type
Re: Intel 7260 not working on 4.4.24 / armv7
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
Re: Intel 7260 not working on 4.4.24 / armv7
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)
[PATCH 2/7] mac80211: fix tid_agg_rx NULL dereference
From: Johannes Berg On drivers setting the SUPPORTS_REORDERING_BUFFER hardware flag, we crash when the peer sends an AddBA request while we already have a session open on the seame TID; this is because on those drivers, the tid_agg_rx is left NULL even though the session is valid, and the agg_session_valid bit is set. To fix this, store the dialog tokens outside the tid_agg_rx to be able to compare them to the received AddBA request. Fixes: f89e07d4cf26 ("mac80211: agg-rx: refuse ADDBA Request with timeout update") Reported-by: Emmanuel Grumbach Signed-off-by: Johannes Berg --- net/mac80211/agg-rx.c | 8 ++-- net/mac80211/debugfs_sta.c | 2 +- net/mac80211/sta_info.h| 4 ++-- 3 files changed, 5 insertions(+), 9 deletions(-) diff --git a/net/mac80211/agg-rx.c b/net/mac80211/agg-rx.c index f6749dc..3b5fd41 100644 --- a/net/mac80211/agg-rx.c +++ b/net/mac80211/agg-rx.c @@ -315,11 +315,7 @@ void __ieee80211_start_rx_ba_session(struct sta_info *sta, mutex_lock(&sta->ampdu_mlme.mtx); if (test_bit(tid, sta->ampdu_mlme.agg_session_valid)) { - tid_agg_rx = rcu_dereference_protected( - sta->ampdu_mlme.tid_rx[tid], - lockdep_is_held(&sta->ampdu_mlme.mtx)); - - if (tid_agg_rx->dialog_token == dialog_token) { + if (sta->ampdu_mlme.tid_rx_token[tid] == dialog_token) { ht_dbg_ratelimited(sta->sdata, "updated AddBA Req from %pM on tid %u\n", sta->sta.addr, tid); @@ -396,7 +392,6 @@ void __ieee80211_start_rx_ba_session(struct sta_info *sta, } /* update data */ - tid_agg_rx->dialog_token = dialog_token; tid_agg_rx->ssn = start_seq_num; tid_agg_rx->head_seq_num = start_seq_num; tid_agg_rx->buf_size = buf_size; @@ -418,6 +413,7 @@ void __ieee80211_start_rx_ba_session(struct sta_info *sta, if (status == WLAN_STATUS_SUCCESS) { __set_bit(tid, sta->ampdu_mlme.agg_session_valid); __clear_bit(tid, sta->ampdu_mlme.unexpected_agg); + sta->ampdu_mlme.tid_rx_token[tid] = dialog_token; } mutex_unlock(&sta->ampdu_mlme.mtx); diff --git a/net/mac80211/debugfs_sta.c b/net/mac80211/debugfs_sta.c index a2fcdb4..14ec63a 100644 --- a/net/mac80211/debugfs_sta.c +++ b/net/mac80211/debugfs_sta.c @@ -205,7 +205,7 @@ static ssize_t sta_agg_status_read(struct file *file, char __user *userbuf, p += scnprintf(p, sizeof(buf) + buf - p, "%02d", i); p += scnprintf(p, sizeof(buf) + buf - p, "\t\t%x", !!tid_rx); p += scnprintf(p, sizeof(buf) + buf - p, "\t%#.2x", - tid_rx ? tid_rx->dialog_token : 0); + tid_rx ? sta->ampdu_mlme.tid_rx_token[i] : 0); p += scnprintf(p, sizeof(buf) + buf - p, "\t%#.3x", tid_rx ? tid_rx->ssn : 0); diff --git a/net/mac80211/sta_info.h b/net/mac80211/sta_info.h index ed5fcb9..dd06ef0 100644 --- a/net/mac80211/sta_info.h +++ b/net/mac80211/sta_info.h @@ -184,7 +184,6 @@ struct tid_ampdu_tx { * @ssn: Starting Sequence Number expected to be aggregated. * @buf_size: buffer size for incoming A-MPDUs * @timeout: reset timer value (in TUs). - * @dialog_token: dialog token for aggregation session * @rcu_head: RCU head used for freeing this struct * @reorder_lock: serializes access to reorder buffer, see below. * @auto_seq: used for offloaded BA sessions to automatically pick head_seq_and @@ -213,7 +212,6 @@ struct tid_ampdu_rx { u16 ssn; u16 buf_size; u16 timeout; - u8 dialog_token; bool auto_seq; bool removed; }; @@ -225,6 +223,7 @@ struct tid_ampdu_rx { * to tid_tx[idx], which are protected by the sta spinlock) * tid_start_tx is also protected by sta->lock. * @tid_rx: aggregation info for Rx per TID -- RCU protected + * @tid_rx_token: dialog tokens for valid aggregation sessions * @tid_rx_timer_expired: bitmap indicating on which TIDs the * RX timer expired until the work for it runs * @tid_rx_stop_requested: bitmap indicating which BA sessions per TID the @@ -243,6 +242,7 @@ struct sta_ampdu_mlme { struct mutex mtx; /* rx */ struct tid_ampdu_rx __rcu *tid_rx[IEEE80211_NUM_TIDS]; + u8 tid_rx_token[IEEE80211_NUM_TIDS]; unsigned long tid_rx_timer_expired[BITS_TO_LONGS(IEEE80211_NUM_TIDS)]; unsigned long tid_rx_stop_requested[BITS_TO_LONGS(IEEE80211_NUM_TIDS)]; unsigned long agg_session_valid[BITS_TO_LONGS(IEEE80211_NUM_TIDS)]; -- 2.9.3
[PATCH 0/7] patches for mac80211/cfg80211 2016-10-18
From: Luca Coelho Hi Johannes, Here are a few patches for mac80211/cfg80211 from our internal tree. You're probably familiar with most of them, I'm just adding a cover letter to make it easier for you to reply "Applied all" (hopefully).:) Cheers, Luca. Emmanuel Grumbach (2): mac80211: allow the driver not to pass the tid to ieee80211_sta_uapsd_trigger mac80211: uapsd_queues is in QoS IE order Ilan Peer (1): cfg80211: Call rdev_disconnect() when connection is in progress Johannes Berg (3): wireless: radiotap: fix timestamp sampling position values mac80211: fix tid_agg_rx NULL dereference mac80211: improve RX aggregation data in debugfs Sara Sharon (1): mac80211: add a HW flag for supporting HW TX fragmentation drivers/net/wireless/ath/ath10k/mac.c | 1 + drivers/net/wireless/ti/wlcore/main.c | 1 + include/net/cfg80211.h| 10 ++ include/net/ieee80211_radiotap.h | 4 ++-- include/net/mac80211.h| 17 ++--- net/mac80211/agg-rx.c | 8 ++-- net/mac80211/debugfs.c| 1 + net/mac80211/debugfs_sta.c| 9 +++-- net/mac80211/ieee80211_i.h| 2 ++ net/mac80211/main.c | 4 net/mac80211/mlme.c | 2 +- net/mac80211/rx.c | 6 -- net/mac80211/sta_info.c | 13 - net/mac80211/sta_info.h | 4 ++-- net/mac80211/tx.c | 4 ++-- net/mac80211/util.c | 7 +++ net/mac80211/wpa.c| 2 +- net/wireless/sme.c| 2 +- 18 files changed, 66 insertions(+), 31 deletions(-) -- 2.9.3
[PATCH 4/7] mac80211: allow the driver not to pass the tid to ieee80211_sta_uapsd_trigger
From: Emmanuel Grumbach iwlwifi will check internally that the tid maps to an AC that is trigger enabled, but can't know what tid exactly. Allow the driver to pass a generic tid and make mac80211 assume that a trigger frame was received. Signed-off-by: Emmanuel Grumbach Signed-off-by: Luca Coelho --- include/net/mac80211.h | 4 net/mac80211/rx.c | 5 +++-- 2 files changed, 7 insertions(+), 2 deletions(-) diff --git a/include/net/mac80211.h b/include/net/mac80211.h index e50c9e0..f3dbada 100644 --- a/include/net/mac80211.h +++ b/include/net/mac80211.h @@ -4087,6 +4087,10 @@ void ieee80211_sta_pspoll(struct ieee80211_sta *sta); * This must be used in conjunction with ieee80211_sta_ps_transition() * and possibly ieee80211_sta_pspoll(); calls to all three must be * serialized. + * %IEEE80211_NUM_TIDS can be passed as the tid if the tid is unknown. + * In this case, mac80211 will not check that this tid maps to an AC + * that is trigger enabled and assume that the caller did the proper + * checks. */ void ieee80211_sta_uapsd_trigger(struct ieee80211_sta *sta, u8 tid); diff --git a/net/mac80211/rx.c b/net/mac80211/rx.c index fc08a50..837d562 100644 --- a/net/mac80211/rx.c +++ b/net/mac80211/rx.c @@ -1394,13 +1394,14 @@ void ieee80211_sta_uapsd_trigger(struct ieee80211_sta *pubsta, u8 tid) u8 ac = ieee802_1d_to_ac[tid & 7]; /* -* If this AC is not trigger-enabled do nothing. +* If this AC is not trigger-enabled do nothing unless the +* driver is calling us after it already checked. * * NB: This could/should check a separate bitmap of trigger- * enabled queues, but for now we only implement uAPSD w/o * TSPEC changes to the ACs, so they're always the same. */ - if (!(sta->sta.uapsd_queues & BIT(ac))) + if (!(sta->sta.uapsd_queues & BIT(ac)) && tid != IEEE80211_NUM_TIDS) return; /* if we are in a service period, do nothing */ -- 2.9.3
[PATCH 3/7] mac80211: improve RX aggregation data in debugfs
From: Johannes Berg When the driver sets the SUPPORTS_REORDERING_BUFFER hardware flag, the debugfs data for RX aggregation sessions won't even indicate that a session is open. Since the previous fix to store the dialog token separately, we can indicate that it's open and add the token so that there's at least some data (ssn is not available.) Signed-off-by: Johannes Berg --- net/mac80211/debugfs_sta.c | 9 +++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/net/mac80211/debugfs_sta.c b/net/mac80211/debugfs_sta.c index 14ec63a..f6003b8 100644 --- a/net/mac80211/debugfs_sta.c +++ b/net/mac80211/debugfs_sta.c @@ -199,13 +199,18 @@ static ssize_t sta_agg_status_read(struct file *file, char __user *userbuf, "TID\t\tRX\tDTKN\tSSN\t\tTX\tDTKN\tpending\n"); for (i = 0; i < IEEE80211_NUM_TIDS; i++) { + bool tid_rx_valid; + tid_rx = rcu_dereference(sta->ampdu_mlme.tid_rx[i]); tid_tx = rcu_dereference(sta->ampdu_mlme.tid_tx[i]); + tid_rx_valid = test_bit(i, sta->ampdu_mlme.agg_session_valid); p += scnprintf(p, sizeof(buf) + buf - p, "%02d", i); - p += scnprintf(p, sizeof(buf) + buf - p, "\t\t%x", !!tid_rx); + p += scnprintf(p, sizeof(buf) + buf - p, "\t\t%x", + tid_rx_valid); p += scnprintf(p, sizeof(buf) + buf - p, "\t%#.2x", - tid_rx ? sta->ampdu_mlme.tid_rx_token[i] : 0); + tid_rx_valid ? + sta->ampdu_mlme.tid_rx_token[i] : 0); p += scnprintf(p, sizeof(buf) + buf - p, "\t%#.3x", tid_rx ? tid_rx->ssn : 0); -- 2.9.3
[PATCH 1/7] wireless: radiotap: fix timestamp sampling position values
From: Johannes Berg The values don't match the radiotap spec, corrected that. Reported-by: Oz Shalev Signed-off-by: Johannes Berg --- include/net/ieee80211_radiotap.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/include/net/ieee80211_radiotap.h b/include/net/ieee80211_radiotap.h index ba07b9d..d0e7e3f 100644 --- a/include/net/ieee80211_radiotap.h +++ b/include/net/ieee80211_radiotap.h @@ -333,9 +333,9 @@ enum ieee80211_radiotap_type { #define IEEE80211_RADIOTAP_TIMESTAMP_UNIT_NS 0x0003 #define IEEE80211_RADIOTAP_TIMESTAMP_SPOS_MASK 0x00F0 #define IEEE80211_RADIOTAP_TIMESTAMP_SPOS_BEGIN_MDPU 0x -#define IEEE80211_RADIOTAP_TIMESTAMP_SPOS_EO_MPDU 0x0010 +#define IEEE80211_RADIOTAP_TIMESTAMP_SPOS_PLCP_SIG_ACQ 0x0010 #define IEEE80211_RADIOTAP_TIMESTAMP_SPOS_EO_PPDU 0x0020 -#define IEEE80211_RADIOTAP_TIMESTAMP_SPOS_PLCP_SIG_ACQ 0x0030 +#define IEEE80211_RADIOTAP_TIMESTAMP_SPOS_EO_MPDU 0x0030 #define IEEE80211_RADIOTAP_TIMESTAMP_SPOS_UNKNOWN 0x00F0 #define IEEE80211_RADIOTAP_TIMESTAMP_FLAG_64BIT0x00 -- 2.9.3
[PATCH 7/7] cfg80211: Call rdev_disconnect() when connection is in progress
From: Ilan Peer On a disconnect request from user space, cfg80211 would have called rdev_disconnect() only in case that 'current_bss' was set, i.e., connection has been established. Change this, so rdev_disconnect() would be called also in case that connection is in progress, so the connection attempt would be stopped. Signed-off-by: Ilan Peer Signed-off-by: Luca Coelho --- include/net/cfg80211.h | 7 --- net/wireless/sme.c | 2 +- 2 files changed, 5 insertions(+), 4 deletions(-) diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h index 10a26f0..2bbbcc3 100644 --- a/include/net/cfg80211.h +++ b/include/net/cfg80211.h @@ -2564,9 +2564,10 @@ struct cfg80211_nan_func { * cases, the result of roaming is indicated with a call to * cfg80211_roamed() or cfg80211_roamed_bss(). * (invoked with the wireless_dev mutex held) - * @disconnect: Disconnect from the BSS/ESS. Once done, call - * cfg80211_disconnected(). - * (invoked with the wireless_dev mutex held) + * @disconnect: Disconnect from the BSS/ESS or stop connection attempts if + * connection is in progress. Once done, call cfg80211_disconnected() in + * case connection was already established (invoked with the + * wireless_dev mutex held), otherwise call cfg80211_connect_timeout(). * * @join_ibss: Join the specified IBSS (or create if necessary). Once done, call * cfg80211_ibss_joined(), also call that function when changing BSSID due diff --git a/net/wireless/sme.c b/net/wireless/sme.c index a77db33..2b5bb38 100644 --- a/net/wireless/sme.c +++ b/net/wireless/sme.c @@ -1088,7 +1088,7 @@ int cfg80211_disconnect(struct cfg80211_registered_device *rdev, err = cfg80211_sme_disconnect(wdev, reason); else if (!rdev->ops->disconnect) cfg80211_mlme_down(rdev, dev); - else if (wdev->current_bss) + else if (wdev->ssid_len) err = rdev_disconnect(rdev, dev, reason); return err; -- 2.9.3
[PATCH 6/7] mac80211: uapsd_queues is in QoS IE order
From: Emmanuel Grumbach The uapsd_queue field is in QoS IE order and not in IEEE80211_AC_*'s order. This means that mac80211 would get confused between BK and BE which is certainly not such a big deal but needs to be fixed. Signed-off-by: Emmanuel Grumbach Signed-off-by: Luca Coelho --- include/net/cfg80211.h | 3 ++- include/net/mac80211.h | 3 ++- net/mac80211/ieee80211_i.h | 2 ++ net/mac80211/mlme.c| 2 +- net/mac80211/rx.c | 3 ++- net/mac80211/sta_info.c| 13 - net/mac80211/util.c| 7 +++ 7 files changed, 24 insertions(+), 9 deletions(-) diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h index 5000ec7..10a26f0 100644 --- a/include/net/cfg80211.h +++ b/include/net/cfg80211.h @@ -4574,7 +4574,8 @@ void cfg80211_auth_timeout(struct net_device *dev, const u8 *addr); * moves to cfg80211 in this call * @buf: authentication frame (header + body) * @len: length of the frame data - * @uapsd_queues: bitmap of ACs configured to uapsd. -1 if n/a. + * @uapsd_queues: bitmap of queues configured for uapsd. Same format + * as the AC bitmap in the QoS info field * * After being asked to associate via cfg80211_ops::assoc() the driver must * call either this function or cfg80211_auth_timeout(). diff --git a/include/net/mac80211.h b/include/net/mac80211.h index a1a2702..b9b24ab 100644 --- a/include/net/mac80211.h +++ b/include/net/mac80211.h @@ -1745,7 +1745,8 @@ struct ieee80211_sta_rates { * @drv_priv: data area for driver use, will always be aligned to * sizeof(void *), size is determined in hw information. * @uapsd_queues: bitmap of queues configured for uapsd. Only valid - * if wme is supported. + * if wme is supported. The bits order is like in + * IEEE80211_WMM_IE_STA_QOSINFO_AC_*. * @max_sp: max Service Period. Only valid if wme is supported. * @bandwidth: current bandwidth the station can receive with * @rx_nss: in HT/VHT, the maximum number of spatial streams the diff --git a/net/mac80211/ieee80211_i.h b/net/mac80211/ieee80211_i.h index 42d194a..b4e2b6c 100644 --- a/net/mac80211/ieee80211_i.h +++ b/net/mac80211/ieee80211_i.h @@ -84,6 +84,8 @@ struct ieee80211_local; #define IEEE80211_DEFAULT_MAX_SP_LEN \ IEEE80211_WMM_IE_STA_QOSINFO_SP_ALL +extern const u8 ieee80211_ac_to_qos_mask[IEEE80211_NUM_ACS]; + #define IEEE80211_DEAUTH_FRAME_LEN (24 /* hdr */ + 2 /* reason */) #define IEEE80211_MAX_NAN_INSTANCE_ID 255 diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c index 7486f2d..c8d3a9b 100644 --- a/net/mac80211/mlme.c +++ b/net/mac80211/mlme.c @@ -3193,7 +3193,7 @@ static void ieee80211_rx_mgmt_assoc_resp(struct ieee80211_sub_if_data *sdata, uapsd_queues = 0; for (ac = 0; ac < IEEE80211_NUM_ACS; ac++) if (sdata->tx_conf[ac].uapsd) - uapsd_queues |= BIT(ac); + uapsd_queues |= ieee80211_ac_to_qos_mask[ac]; } cfg80211_rx_assoc_resp(sdata->dev, bss, (u8 *)mgmt, len, uapsd_queues); diff --git a/net/mac80211/rx.c b/net/mac80211/rx.c index 837d562..21a8947 100644 --- a/net/mac80211/rx.c +++ b/net/mac80211/rx.c @@ -1401,7 +1401,8 @@ void ieee80211_sta_uapsd_trigger(struct ieee80211_sta *pubsta, u8 tid) * enabled queues, but for now we only implement uAPSD w/o * TSPEC changes to the ACs, so they're always the same. */ - if (!(sta->sta.uapsd_queues & BIT(ac)) && tid != IEEE80211_NUM_TIDS) + if (!(sta->sta.uapsd_queues & ieee80211_ac_to_qos_mask[ac]) && + tid != IEEE80211_NUM_TIDS) return; /* if we are in a service period, do nothing */ diff --git a/net/mac80211/sta_info.c b/net/mac80211/sta_info.c index ab91e1e..236d47e 100644 --- a/net/mac80211/sta_info.c +++ b/net/mac80211/sta_info.c @@ -709,7 +709,7 @@ static void __sta_info_recalc_tim(struct sta_info *sta, bool ignore_pending) for (ac = 0; ac < IEEE80211_NUM_ACS; ac++) { unsigned long tids; - if (ignore_for_tim & BIT(ac)) + if (ignore_for_tim & ieee80211_ac_to_qos_mask[ac]) continue; indicate_tim |= !skb_queue_empty(&sta->tx_filtered[ac]) || @@ -1389,7 +1389,7 @@ ieee80211_sta_ps_more_data(struct sta_info *sta, u8 ignored_acs, return true; for (ac = 0; ac < IEEE80211_NUM_ACS; ac++) { - if (ignored_acs & BIT(ac)) + if (ignored_acs & ieee80211_ac_to_qos_mask[ac]) continue; if (!skb_queue_empty(&sta->tx_filtered[ac]) || @@ -1414,7 +1414,7 @@ ieee80211_sta_ps_get_frames(struct sta_info *sta, int n_frames, u8 ignored_acs, for (ac = 0; ac < IEEE80211_NUM_ACS; ac++) { unsigned long tids; - if (ignored_acs & BIT(ac)) + if (ignored_acs & ieee80211_ac_to_qos_mask[ac])
[PATCH 5/7] mac80211: add a HW flag for supporting HW TX fragmentation
From: Sara Sharon Currently mac80211 determines whether HW does fragmentation by checking whether the set_frag_threshold callback is set or not. However, some drivers may want to set the HW fragmentation capability depending on HW generation. Allow this by checking a HW flag instead of checking the callback. Signed-off-by: Sara Sharon [added the flag to ath10k and wlcore] Signed-off-by: Luca Coelho --- drivers/net/wireless/ath/ath10k/mac.c | 1 + drivers/net/wireless/ti/wlcore/main.c | 1 + include/net/mac80211.h| 10 -- net/mac80211/debugfs.c| 1 + net/mac80211/main.c | 4 net/mac80211/tx.c | 4 ++-- net/mac80211/wpa.c| 2 +- 7 files changed, 18 insertions(+), 5 deletions(-) diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c index 76297d6..e322b6d 100644 --- a/drivers/net/wireless/ath/ath10k/mac.c +++ b/drivers/net/wireless/ath/ath10k/mac.c @@ -7881,6 +7881,7 @@ int ath10k_mac_register(struct ath10k *ar) ieee80211_hw_set(ar->hw, WANT_MONITOR_VIF); ieee80211_hw_set(ar->hw, CHANCTX_STA_CSA); ieee80211_hw_set(ar->hw, QUEUE_CONTROL); + ieee80211_hw_set(ar->hw, SUPPORTS_TX_FRAG); if (!test_bit(ATH10K_FLAG_RAW_MODE, &ar->dev_flags)) ieee80211_hw_set(ar->hw, SW_CRYPTO_CONTROL); diff --git a/drivers/net/wireless/ti/wlcore/main.c b/drivers/net/wireless/ti/wlcore/main.c index 471521a..9f39c6c 100644 --- a/drivers/net/wireless/ti/wlcore/main.c +++ b/drivers/net/wireless/ti/wlcore/main.c @@ -6086,6 +6086,7 @@ static int wl1271_init_ieee80211(struct wl1271 *wl) ieee80211_hw_set(wl->hw, SUPPORTS_DYNAMIC_PS); ieee80211_hw_set(wl->hw, SIGNAL_DBM); ieee80211_hw_set(wl->hw, SUPPORTS_PS); + ieee80211_hw_set(wl->hw, SUPPORTS_TX_FRAG); wl->hw->wiphy->cipher_suites = cipher_suites; wl->hw->wiphy->n_cipher_suites = ARRAY_SIZE(cipher_suites); diff --git a/include/net/mac80211.h b/include/net/mac80211.h index f3dbada..a1a2702 100644 --- a/include/net/mac80211.h +++ b/include/net/mac80211.h @@ -2025,6 +2025,10 @@ struct ieee80211_txq { * drivers, mac80211 packet loss mechanism will not be triggered and driver * is completely depending on firmware event for station kickout. * + * @IEEE80211_HW_SUPPORTS_TX_FRAG: Hardware does fragmentation by itself. + * The stack will not do fragmentation. + * The callback for @set_frag_threshold should be set as well. + * * @NUM_IEEE80211_HW_FLAGS: number of hardware flags, used for sizing arrays */ enum ieee80211_hw_flags { @@ -2066,6 +2070,7 @@ enum ieee80211_hw_flags { IEEE80211_HW_TX_AMSDU, IEEE80211_HW_TX_FRAG_LIST, IEEE80211_HW_REPORTS_LOW_ACK, + IEEE80211_HW_SUPPORTS_TX_FRAG, /* keep last, obviously */ NUM_IEEE80211_HW_FLAGS @@ -3093,8 +3098,9 @@ enum ieee80211_reconfig_type { * The callback must be atomic. * * @set_frag_threshold: Configuration of fragmentation threshold. Assign this - * if the device does fragmentation by itself; if this callback is - * implemented then the stack will not do fragmentation. + * if the device does fragmentation by itself. Note that to prevent the + * stack from doing fragmentation IEEE80211_HW_SUPPORTS_TX_FRAG + * should be set as well. * The callback can sleep. * * @set_rts_threshold: Configuration of RTS threshold (if device needs it) diff --git a/net/mac80211/debugfs.c b/net/mac80211/debugfs.c index f56e2f4..e02ba42 100644 --- a/net/mac80211/debugfs.c +++ b/net/mac80211/debugfs.c @@ -210,6 +210,7 @@ static const char *hw_flag_names[] = { FLAG(TX_AMSDU), FLAG(TX_FRAG_LIST), FLAG(REPORTS_LOW_ACK), + FLAG(SUPPORTS_TX_FRAG), #undef FLAG }; diff --git a/net/mac80211/main.c b/net/mac80211/main.c index 1075ac2..0d9163c 100644 --- a/net/mac80211/main.c +++ b/net/mac80211/main.c @@ -821,6 +821,10 @@ int ieee80211_register_hw(struct ieee80211_hw *hw) !local->ops->tdls_recv_channel_switch)) return -EOPNOTSUPP; + if (WARN_ON(ieee80211_hw_check(hw, SUPPORTS_TX_FRAG) && + !local->ops->set_frag_threshold)) + return -EINVAL; + if (WARN_ON(local->hw.wiphy->interface_modes & BIT(NL80211_IFTYPE_NAN) && (!local->ops->start_nan || !local->ops->stop_nan))) diff --git a/net/mac80211/tx.c b/net/mac80211/tx.c index 772e369..62ccaf6 100644 --- a/net/mac80211/tx.c +++ b/net/mac80211/tx.c @@ -934,7 +934,7 @@ ieee80211_tx_h_fragment(struct ieee80211_tx_data *tx) if (info->flags & IEEE80211_TX_CTL_DONTFRAG) return TX_CONTINUE; - if (tx->local->ops->set_frag_threshold) + if (ieee80211_hw_check(&tx->local->hw, SUPPORTS_TX_FRAG)) return TX_CONTINUE; /* @@ -2800,7 +2800,7 @@ void ieee80211_check_fast_xm
Re: sequence diagrams in rst documentation
On Tue, 18 Oct 2016 13:43:41 +0200 Johannes Berg wrote: > > 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. OK, I've read through all of this. My thoughts, for whatever it's worth. We already carry a few sphinx plugins in the kernel; there is room for more if we *really* need them. But... - Part of the idea behind switching over to sphinx was to be able to get away from maintaining our own formatting system. Adding plugins to the kernel is a step away from that goal. So I'd like to be sure that there's nothing that's part of standard sphinx that will do the job first. That said, I think that requiring people to install plugins from contrib sites or third-party repos may be even worse. We don't want to put people through misery just to format the docs. In summary, I think we can consider taking on a module if it's what we need to do the docs right. And if somebody agrees to maintain it! :) I've heard others say they would like better diagramming support. Do you think that, maybe, something like aafigure would do the trick? https://pythonhosted.org/sphinxcontrib-aafig/ I've not actually played with it at all, but I like the idea that we'd have readable diagrams in the source docs as well... jon
[PATCH net-next 2/6] net: use core MTU range checking in wireless drivers
- set max_mtu in wil6210 driver - set max_mtu in atmel driver - set min/max_mtu in cisco airo driver, remove airo_change_mtu - set min/max_mtu in ipw2100/ipw2200 drivers, remove libipw_change_mtu - set min/max_mtu in p80211netdev, remove wlan_change_mtu CC: net...@vger.kernel.org CC: linux-wireless@vger.kernel.org CC: Maya Erez CC: Simon Kelley CC: Stanislav Yakovlev Signed-off-by: Jarod Wilson --- drivers/net/wireless/ath/wil6210/netdev.c | 17 + drivers/net/wireless/atmel/atmel.c | 13 - drivers/net/wireless/cisco/airo.c | 14 +++--- drivers/net/wireless/intel/ipw2x00/ipw2100.c | 3 ++- drivers/net/wireless/intel/ipw2x00/ipw2200.c | 8 ++-- drivers/net/wireless/intel/ipw2x00/libipw.h| 1 - drivers/net/wireless/intel/ipw2x00/libipw_module.c | 9 - drivers/staging/wlan-ng/p80211netdev.c | 18 +- 8 files changed, 21 insertions(+), 62 deletions(-) diff --git a/drivers/net/wireless/ath/wil6210/netdev.c b/drivers/net/wireless/ath/wil6210/netdev.c index 61de5e9..d18372c 100644 --- a/drivers/net/wireless/ath/wil6210/netdev.c +++ b/drivers/net/wireless/ath/wil6210/netdev.c @@ -41,21 +41,6 @@ static int wil_stop(struct net_device *ndev) return wil_down(wil); } -static int wil_change_mtu(struct net_device *ndev, int new_mtu) -{ - struct wil6210_priv *wil = ndev_to_wil(ndev); - - if (new_mtu < 68 || new_mtu > mtu_max) { - wil_err(wil, "invalid MTU %d\n", new_mtu); - return -EINVAL; - } - - wil_dbg_misc(wil, "change MTU %d -> %d\n", ndev->mtu, new_mtu); - ndev->mtu = new_mtu; - - return 0; -} - static int wil_do_ioctl(struct net_device *ndev, struct ifreq *ifr, int cmd) { struct wil6210_priv *wil = ndev_to_wil(ndev); @@ -69,7 +54,6 @@ static const struct net_device_ops wil_netdev_ops = { .ndo_start_xmit = wil_start_xmit, .ndo_set_mac_address= eth_mac_addr, .ndo_validate_addr = eth_validate_addr, - .ndo_change_mtu = wil_change_mtu, .ndo_do_ioctl = wil_do_ioctl, }; @@ -126,6 +110,7 @@ static int wil6210_netdev_poll_tx(struct napi_struct *napi, int budget) static void wil_dev_setup(struct net_device *dev) { ether_setup(dev); + dev->max_mtu = mtu_max; dev->tx_queue_len = WIL_TX_Q_LEN_DEFAULT; } diff --git a/drivers/net/wireless/atmel/atmel.c b/drivers/net/wireless/atmel/atmel.c index bf2e9a0..eb92d5a 100644 --- a/drivers/net/wireless/atmel/atmel.c +++ b/drivers/net/wireless/atmel/atmel.c @@ -1295,14 +1295,6 @@ static struct iw_statistics *atmel_get_wireless_stats(struct net_device *dev) return &priv->wstats; } -static int atmel_change_mtu(struct net_device *dev, int new_mtu) -{ - if ((new_mtu < 68) || (new_mtu > 2312)) - return -EINVAL; - dev->mtu = new_mtu; - return 0; -} - static int atmel_set_mac_address(struct net_device *dev, void *p) { struct sockaddr *addr = p; @@ -1506,7 +1498,6 @@ static const struct file_operations atmel_proc_fops = { static const struct net_device_ops atmel_netdev_ops = { .ndo_open = atmel_open, .ndo_stop = atmel_close, - .ndo_change_mtu = atmel_change_mtu, .ndo_set_mac_address= atmel_set_mac_address, .ndo_start_xmit = start_tx, .ndo_do_ioctl = atmel_ioctl, @@ -1600,6 +1591,10 @@ struct net_device *init_atmel_card(unsigned short irq, unsigned long port, dev->irq = irq; dev->base_addr = port; + /* MTU range: 68 - 2312 */ + dev->min_mtu = 68; + dev->max_mtu = MAX_WIRELESS_BODY - ETH_FCS_LEN; + SET_NETDEV_DEV(dev, sys_dev); if ((rc = request_irq(dev->irq, service_interrupt, IRQF_SHARED, dev->name, dev))) { diff --git a/drivers/net/wireless/cisco/airo.c b/drivers/net/wireless/cisco/airo.c index 69b826d..4b04045 100644 --- a/drivers/net/wireless/cisco/airo.c +++ b/drivers/net/wireless/cisco/airo.c @@ -2329,14 +2329,6 @@ static int airo_set_mac_address(struct net_device *dev, void *p) return 0; } -static int airo_change_mtu(struct net_device *dev, int new_mtu) -{ - if ((new_mtu < 68) || (new_mtu > 2400)) - return -EINVAL; - dev->mtu = new_mtu; - return 0; -} - static LIST_HEAD(airo_devices); static void add_airo_dev(struct airo_info *ai) @@ -2656,7 +2648,6 @@ static const struct net_device_ops airo11_netdev_ops = { .ndo_get_stats = airo_get_stats, .ndo_set_mac_address= airo_set_mac_address, .ndo_do_ioctl = airo_ioctl, - .ndo_change_mtu = airo_change_mtu, }; static void wifi_setup(struct net_device *dev) @@ -2668,6 +2659,8 @@ static void wifi_setup(struct net_device *dev) dev->type = ARPHRD_IEEE80211; dev->hard_hea
Re: [PATCH] crypto: ccm - avoid scatterlist for MAC encryption
On Mon, Oct 17, 2016 at 06:21:14PM +0100, Ard Biesheuvel wrote: > > Annoyingly, all this complication with scatterlists etc is for doing > asynchronous crypto via DMA capable crypto accelerators, and the > networking code (ipsec as well as mac80211, afaik) only allow > synchronous in the first place, given that they execute in softirq > context. I'm still thinking about the issue (in particular, whether we should continue to rely on the request context being SG-capable or allow it to be on the stack for AEAD). But IPsec definitely supports async crypto. In fact it was the very first user of async crypto. mac80211 on the other hand is currently sync-only. Cheers, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
[PATCH] cfg80211: allow vendor commands to be sent to nan interface
From: Andrei Otcheretianski Allow vendor commands that require WIPHY_VENDOR_CMD_NEED_RUNNING flag, to be sent to NAN interface. Signed-off-by: Andrei Otcheretianski Signed-off-by: Luca Coelho --- net/wireless/nl80211.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c index e48b9c3..fcf5b4f 100644 --- a/net/wireless/nl80211.c +++ b/net/wireless/nl80211.c @@ -11258,7 +11258,8 @@ static int nl80211_vendor_cmd(struct sk_buff *skb, struct genl_info *info) if (wdev->netdev && !netif_running(wdev->netdev)) return -ENETDOWN; - if (!wdev->netdev && !wdev->p2p_started) + if (!wdev->netdev && !wdev->p2p_started && + !wdev->nan_started) return -ENETDOWN; } -- 2.9.3