net: wireless: Remove adhoc and beacon_int_min_gcd check.

Commit Message

Ben Greear Dec. 5, 2024, 10:55 p.m. UTC

From: Ben Greear <[e-mail]>

This check keeps mtk7996 from loading.  If someone thinks
they can get ADHOC to work, let them try it.  If the
kernel really needs to restrict some combination, then
it should be done at time user attempts to actually
use that combination, not at driver load.

Signed-off-by: Ben Greear <[e-mail]>
---
 net/wireless/core.c | 15 ---------------
 1 file changed, 15 deletions(-)

Comments

Johannes Berg Dec. 6, 2024, 9:43 a.m. UTC | #1

On Thu, 2024-12-05 at 14:55 -0800, [e-mail] wrote:
> From: Ben Greear <[e-mail]>
> 
> This check keeps mtk7996 from loading.  If someone thinks
> they can get ADHOC to work, let them try it.  If the
> kernel really needs to restrict some combination, then
> it should be done at time user attempts to actually
> use that combination, not at driver load.
> 

I disagree, the driver shouldn't advertise non-sense interface
combinations that cannot possibly work correctly.

johannes

Ben Greear Dec. 6, 2024, 3:12 p.m. UTC | #2

On 12/6/24 01:43, Johannes Berg wrote:
> On Thu, 2024-12-05 at 14:55 -0800, [e-mail] wrote:
>> From: Ben Greear <[e-mail]>
>>
>> This check keeps mtk7996 from loading.  If someone thinks
>> they can get ADHOC to work, let them try it.  If the
>> kernel really needs to restrict some combination, then
>> it should be done at time user attempts to actually
>> use that combination, not at driver load.
>>
> 
> I disagree, the driver shouldn't advertise non-sense interface
> combinations that cannot possibly work correctly.

 From the code comment, it looks like it might be possible to get into
a bad configuration if peer ADHOC uses a small beacon time, and if
that also messes up mtk7996 firmware somehow.  But also,
it could work just fine if they did not use a small beacon time,
or if firmware magically deals with this somehow with work-arounds
specific to ADHOC (and yet still want normal APs to use 100 or larger
for beacon timer).  So 'cannot possibly work correctly'
is a bit of overreach I think.

Hello Felix,

Any suggestions for how to fix this?  Disable ADHOC in 7996, or set the beacon_int_min_gcd
to zero to allow it to be any duration?

What is openwrt doing to allow mtk7996 to load?

Thanks,
Ben

Patch

diff --git a/net/wireless/core.c b/net/wireless/core.c
index 74ca18833df1..9c8827266700 100644
--- a/net/wireless/core.c
+++ b/net/wireless/core.c
@@ -658,21 +658,6 @@  static int wiphy_verify_combinations(struct wiphy *wiphy)
 				    c->limits[j].max > 1))
 				return -EINVAL;
 
-			/*
-			 * This isn't well-defined right now. If you have an
-			 * IBSS interface, then its beacon interval may change
-			 * by joining other networks, and nothing prevents it
-			 * from doing that.
-			 * So technically we probably shouldn't even allow AP
-			 * and IBSS in the same interface, but it seems that
-			 * some drivers support that, possibly only with fixed
-			 * beacon intervals for IBSS.
-			 */
-			if (WARN_ON(types & BIT(NL80211_IFTYPE_ADHOC) &&
-				    c->beacon_int_min_gcd)) {
-				return -EINVAL;
-			}
-
 			cnt += c->limits[j].max;
 			/*
 			 * Don't advertise an unsupported type