summaryrefslogtreecommitdiffstats
path: root/net/mac80211
diff options
context:
space:
mode:
authorManikanta Pubbisetty <mpubbise@codeaurora.org>2018-03-28 18:34:19 +0530
committerJohannes Berg <johannes.berg@intel.com>2018-03-29 11:35:22 +0200
commitdb3bdcb9c3ffc628c5284d7ed03a704295ba1214 (patch)
tree29260761f4478e8cb841fa9a2b841d57615afe74 /net/mac80211
parent19d3577e35e0cbb42694811b096e749a0f89a824 (diff)
downloadlinux-db3bdcb9c3ffc628c5284d7ed03a704295ba1214.tar.bz2
mac80211: allow AP_VLAN operation on crypto controlled devices
In the current implementation, mac80211 advertises the support of AP_VLANs based on the driver's support for AP mode; it also blocks encrypted AP_VLAN operation on devices advertising SW_CRYPTO_CONTROL. The implementation seems weird in it's current form and could be often confusing, this is because there can be drivers advertising both SW_CRYPTO_CONTROL and AP mode support (ex: ath10k) in which case AP_VLAN will still be supported but only in open BSS and not in secured BSS. When SW_CRYPTO_CONTROL is enabled, it makes more sense if the decision to support AP_VLANs is left to the driver. Mac80211 can then allow AP_VLAN operations depending on the driver support. Signed-off-by: Manikanta Pubbisetty <mpubbise@codeaurora.org> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Diffstat (limited to 'net/mac80211')
-rw-r--r--net/mac80211/key.c8
-rw-r--r--net/mac80211/main.c8
2 files changed, 11 insertions, 5 deletions
diff --git a/net/mac80211/key.c b/net/mac80211/key.c
index aee05ec3f7ea..ee0d0cc8dc3b 100644
--- a/net/mac80211/key.c
+++ b/net/mac80211/key.c
@@ -126,7 +126,7 @@ static void decrease_tailroom_need_count(struct ieee80211_sub_if_data *sdata,
static int ieee80211_key_enable_hw_accel(struct ieee80211_key *key)
{
- struct ieee80211_sub_if_data *sdata;
+ struct ieee80211_sub_if_data *sdata = key->sdata;
struct sta_info *sta;
int ret = -EOPNOTSUPP;
@@ -162,7 +162,6 @@ static int ieee80211_key_enable_hw_accel(struct ieee80211_key *key)
if (sta && !sta->uploaded)
goto out_unsupported;
- sdata = key->sdata;
if (sdata->vif.type == NL80211_IFTYPE_AP_VLAN) {
/*
* The driver doesn't know anything about VLAN interfaces.
@@ -214,8 +213,11 @@ static int ieee80211_key_enable_hw_accel(struct ieee80211_key *key)
/* all of these we can do in software - if driver can */
if (ret == 1)
return 0;
- if (ieee80211_hw_check(&key->local->hw, SW_CRYPTO_CONTROL))
+ if (ieee80211_hw_check(&key->local->hw, SW_CRYPTO_CONTROL)) {
+ if (sdata->vif.type == NL80211_IFTYPE_AP_VLAN)
+ return 0;
return -EINVAL;
+ }
return 0;
default:
return -EINVAL;
diff --git a/net/mac80211/main.c b/net/mac80211/main.c
index 0785d04a80bc..8d0333b5355b 100644
--- a/net/mac80211/main.c
+++ b/net/mac80211/main.c
@@ -930,8 +930,12 @@ int ieee80211_register_hw(struct ieee80211_hw *hw)
IEEE80211_HT_CAP_SM_PS_SHIFT;
}
- /* if low-level driver supports AP, we also support VLAN */
- if (local->hw.wiphy->interface_modes & BIT(NL80211_IFTYPE_AP)) {
+ /* if low-level driver supports AP, we also support VLAN.
+ * drivers advertising SW_CRYPTO_CONTROL should enable AP_VLAN
+ * based on their support to transmit SW encrypted packets.
+ */
+ if (local->hw.wiphy->interface_modes & BIT(NL80211_IFTYPE_AP) &&
+ !ieee80211_hw_check(&local->hw, SW_CRYPTO_CONTROL)) {
hw->wiphy->interface_modes |= BIT(NL80211_IFTYPE_AP_VLAN);
hw->wiphy->software_iftypes |= BIT(NL80211_IFTYPE_AP_VLAN);
}