diff options
| author | Manikanta Pubbisetty <mpubbise@codeaurora.org> | 2019-07-22 10:14:50 +0300 |
|---|---|---|
| committer | Johannes Berg <johannes.berg@intel.com> | 2019-07-26 14:50:43 +0300 |
| commit | e6f4051123fd33901e9655a675b22aefcdc5d277 (patch) | |
| tree | 43c53eee6035e004f879f708191f9e04440c6443 /net/mac80211/mlme.c | |
| parent | 47d858d0bdcd47cc1c6c9eeca91b091dd9e55637 (diff) | |
| download | linux-e6f4051123fd33901e9655a675b22aefcdc5d277.tar.xz | |
{nl,mac}80211: fix interface combinations on crypto controlled devices
Commit 33d915d9e8ce ("{nl,mac}80211: allow 4addr AP operation on
crypto controlled devices") has introduced a change which allows
4addr operation on crypto controlled devices (ex: ath10k). This
change has inadvertently impacted the interface combinations logic
on such devices.
General rule is that software interfaces like AP/VLAN should not be
listed under supported interface combinations and should not be
considered during validation of these combinations; because of the
aforementioned change, AP/VLAN interfaces(if present) will be checked
against interfaces supported by the device and blocks valid interface
combinations.
Consider a case where an AP and AP/VLAN are up and running; when a
second AP device is brought up on the same physical device, this AP
will be checked against the AP/VLAN interface (which will not be
part of supported interface combinations of the device) and blocks
second AP to come up.
Add a new API cfg80211_iftype_allowed() to fix the problem, this
API works for all devices with/without SW crypto control.
Signed-off-by: Manikanta Pubbisetty <mpubbise@codeaurora.org>
Fixes: 33d915d9e8ce ("{nl,mac}80211: allow 4addr AP operation on crypto controlled devices")
Link: https://lore.kernel.org/r/1563779690-9716-1-git-send-email-mpubbise@codeaurora.org
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Diffstat (limited to 'net/mac80211/mlme.c')
0 files changed, 0 insertions, 0 deletions