blob: ad24dfda5a77759e97ebe5c53054d0d7761e8c3c [file] [log] [blame]
developer6a1998b2022-12-08 18:09:45 +08001From: Hauke Mehrtens <hauke@hauke-m.de>
2Date: Mon, 24 Feb 2020 00:00:00 +0100
3Subject: [PATCH] mac80211: Allow IBSS mode and different beacon intervals
4
5ath10k-ct supports the combination to select IBSS (ADHOC) mode and
6different beacon intervals together. mac80211 does not like this
7combination, but Ben says this is ok, so remove this check.
8
9ath10k-ct starting with version 5.2 allows the combination of
10NL80211_IFTYPE_ADHOC and beacon_int_min_gcd in ath10k_10x_ct_if_comb
11which triggers this warning. Ben told me that this is not a big problem
12and we should ignore this.
13---
14 net/wireless/core.c | 15 ---------------
15 1 file changed, 15 deletions(-)
16
17--- a/net/wireless/core.c
18+++ b/net/wireless/core.c
developer95671ae2023-09-25 14:16:05 +080019@@ -649,21 +649,6 @@ static int wiphy_verify_combinations(str
developer6a1998b2022-12-08 18:09:45 +080020 c->limits[j].max > 1))
21 return -EINVAL;
22
23- /*
24- * This isn't well-defined right now. If you have an
25- * IBSS interface, then its beacon interval may change
26- * by joining other networks, and nothing prevents it
27- * from doing that.
28- * So technically we probably shouldn't even allow AP
29- * and IBSS in the same interface, but it seems that
30- * some drivers support that, possibly only with fixed
31- * beacon intervals for IBSS.
32- */
33- if (WARN_ON(types & BIT(NL80211_IFTYPE_ADHOC) &&
34- c->beacon_int_min_gcd)) {
35- return -EINVAL;
36- }
37-
38 cnt += c->limits[j].max;
39 /*
40 * Don't advertise an unsupported type