summaryrefslogtreecommitdiffstats
path: root/include/net/mac80211.h
diff options
context:
space:
mode:
authorJohannes Berg2015-01-22 18:44:19 +0100
committerJohannes Berg2015-01-22 22:01:01 +0100
commitfa7e1fbcb52cc9efab394526a566d80fb31529bb (patch)
tree3fe7b35805171a28a7f23389a2a40cee834e5381 /include/net/mac80211.h
parentmac80211: fix HW registration error paths (diff)
downloadkernel-qcow2-linux-fa7e1fbcb52cc9efab394526a566d80fb31529bb.tar.gz
kernel-qcow2-linux-fa7e1fbcb52cc9efab394526a566d80fb31529bb.tar.xz
kernel-qcow2-linux-fa7e1fbcb52cc9efab394526a566d80fb31529bb.zip
mac80211: allow drivers to control software crypto
Some drivers unfortunately cannot support software crypto, but mac80211 currently assumes that they do. This has the issue that if the hardware enabling fails for some reason, the software fallback is used, which won't work. This clearly isn't desirable, the error should be reported and the key setting refused. Support this in mac80211 by allowing drivers to set a new HW flag IEEE80211_HW_SW_CRYPTO_CONTROL, in which case mac80211 will only allow software fallback if the set_key() method returns 1. The driver will also need to advertise supported cipher suites so that mac80211 doesn't advertise any (future) software ciphers that the driver can't actually do. While at it, to make it easier to support this, refactor the ieee80211_init_cipher_suites() code. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Diffstat (limited to 'include/net/mac80211.h')
-rw-r--r--include/net/mac80211.h12
1 files changed, 12 insertions, 0 deletions
diff --git a/include/net/mac80211.h b/include/net/mac80211.h
index 275ee56152ad..33b87c50a4cf 100644
--- a/include/net/mac80211.h
+++ b/include/net/mac80211.h
@@ -1634,6 +1634,12 @@ struct ieee80211_tx_control {
* be created. It is expected user-space will create vifs as
* desired (and thus have them named as desired).
*
+ * @IEEE80211_HW_SW_CRYPTO_CONTROL: The driver wants to control which of the
+ * crypto algorithms can be done in software - so don't automatically
+ * try to fall back to it if hardware crypto fails, but do so only if
+ * the driver returns 1. This also forces the driver to advertise its
+ * supported cipher suites.
+ *
* @IEEE80211_HW_QUEUE_CONTROL: The driver wants to control per-interface
* queue mapping in order to use different queues (not just one per AC)
* for different virtual interfaces. See the doc section on HW queue
@@ -1681,6 +1687,7 @@ enum ieee80211_hw_flags {
IEEE80211_HW_MFP_CAPABLE = 1<<13,
IEEE80211_HW_WANT_MONITOR_VIF = 1<<14,
IEEE80211_HW_NO_AUTO_VIF = 1<<15,
+ IEEE80211_HW_SW_CRYPTO_CONTROL = 1<<16,
/* free slots */
IEEE80211_HW_REPORTS_TX_ACK_STATUS = 1<<18,
IEEE80211_HW_CONNECTION_MONITOR = 1<<19,
@@ -1955,6 +1962,11 @@ void ieee80211_free_txskb(struct ieee80211_hw *hw, struct sk_buff *skb);
* added; if you return 0 then hw_key_idx must be assigned to the
* hardware key index, you are free to use the full u8 range.
*
+ * Note that in the case that the @IEEE80211_HW_SW_CRYPTO_CONTROL flag is
+ * set, mac80211 will not automatically fall back to software crypto if
+ * enabling hardware crypto failed. The set_key() call may also return the
+ * value 1 to permit this specific key/algorithm to be done in software.
+ *
* When the cmd is %DISABLE_KEY then it must succeed.
*
* Note that it is permissible to not decrypt a frame even if a key