linux-stable.git/net/wireless/reg.c, branch linux-6.7.y

wifi: cfg80211: reg: describe return values in kernel-doc

2023-09-25T07:12:33+00:00

Describe the function return values in kernel-doc.

Signed-off-by: Johannes Berg 
Signed-off-by: Gregory Greenman 
Link: https://lore.kernel.org/r/20230920211508.8b1e45c8bab8.I6dbae4f6dfe8f5352bc44565cc5131e73dd1873f@changeid
Signed-off-by: Johannes Berg

wifi: cfg80211: save power spectral density(psd) of regulatory rule

2023-09-18T07:44:05+00:00

6 GHz regulatory domains introduces Power Spectral Density (PSD).
The PSD value of the regulatory rule should be taken into effect
for the ieee80211_channels falling into that particular regulatory
rule. Save the values in the channel which has PSD value and add
nl80211 attributes accordingly to handle it.

Co-developed-by: Aditya Kumar Singh 
Signed-off-by: Aditya Kumar Singh 
Signed-off-by: Wen Gong 
Link: https://lore.kernel.org/r/20230914082026.3709-1-quic_wgong@quicinc.com
[use hole in chan flags, reword docs]
Signed-off-by: Johannes Berg

wifi: cfg80211: call reg_call_notifier on beacon hints

2023-09-13T10:34:01+00:00

Currently the channel property updates are not propagated to
driver. This causes issues in the discovery of hidden SSIDs and
fails to connect to them.
This change defines a new wiphy flag which when enabled by vendor
driver, the reg_call_notifier callback will be trigger on beacon
hints. This ensures that the channel property changes are visible
to the vendor driver. The vendor changes the channels for active
scans. This fixes the discovery issue of hidden SSID.

Signed-off-by: Abhishek Kumar 
Link: https://lore.kernel.org/r/20230629035254.1.I059fe585f9f9e896c2d51028ef804d197c8c009e@changeid
Signed-off-by: Johannes Berg

wifi: cfg80211: allow reg update by driver even if wiphy->regd is set

2023-09-13T10:34:01+00:00

Currently regulatory update by driver is not allowed when the
wiphy->regd is already set and drivers_request->intersect is false.

During wiphy registration, some drivers (ath10k does this currently)
first register the world regulatory to cfg80211 using
wiphy_apply_custom_regulatory(). The driver then obtain the current
operating country and tries to update the correct regulatory to
cfg80211 using regulatory_hint().

But at this point, wiphy->regd is already set to world regulatory.
Also, since this is the first request from driver after the world
regulatory is set this will result in drivers_request->intersect
set to false. In this condition the driver request regulatory is not
allowed to update to cfg80211 in reg_set_rd_driver(). This restricts
the device operation to the world regulatory.

This driver request to update the regulatory with current operating
country is valid and should be updated to cfg80211. Hence allow
regulatory update by driver even if the wiphy->regd is already set
and driver_request->intersect is false.

Signed-off-by: Raj Kumar Bhagat 
Reviewed-by: Jeff Johnson 
Link: https://lore.kernel.org/r/20230421061312.13722-1-quic_rajkbhag@quicinc.com
Signed-off-by: Johannes Berg

wifi: cfg80211: remove wdev mutex

2023-09-11T09:27:23+00:00

Since we're now protecting everything with the wiphy mutex
(and were really using it for almost everything before),
there's no longer any real reason to have a separate wdev
mutex. It may feel better, but really has no value.

Signed-off-by: Johannes Berg

wifi: cfg80211: reg: hold wiphy mutex for wdev iteration

2023-09-11T09:27:21+00:00

Since we will want to remove the wdev lock in the future,
lock the wiphy here to iterate and check the flags.

Reviewed-by: Emmanuel Grumbach 
Signed-off-by: Johannes Berg

wifi: cfg80211: check RTNL when iterating devices

2023-09-11T09:27:19+00:00

Add a new "for_each_rdev()" macro and check that we
hold the RTNL when calling it.

Signed-off-by: Johannes Berg

wifi: nl80211/reg: add no-EHT regulatory flag

2023-06-21T12:01:29+00:00

This just propagates to the channel flags, like no-HE and
similar other flags before it.

Signed-off-by: Johannes Berg 
Signed-off-by: Gregory Greenman 
Link: https://lore.kernel.org/r/20230619161906.74ce2983aed8.Ifa343ba89c11760491daad5aee5a81209d5735a7@changeid
Signed-off-by: Johannes Berg

wifi: cfg80211: fix regulatory disconnect with OCB/NAN

2023-06-19T10:05:29+00:00

Since regulatory disconnect was added, OCB and NAN interface
types were added, which made it completely unusable for any
driver that allowed OCB/NAN. Add OCB/NAN (though NAN doesn't
do anything, we don't have any info) and also remove all the
logic that opts out, so it won't be broken again if/when new
interface types are added.

Fixes: 6e0bd6c35b02 ("cfg80211: 802.11p OCB mode handling")
Fixes: cb3b7d87652a ("cfg80211: add start / stop NAN commands")
Signed-off-by: Johannes Berg 
Link: https://lore.kernel.org/r/20230616222844.2794d1625a26.I8e78a3789a29e6149447b3139df724a6f1b46fc3@changeid
Signed-off-by: Johannes Berg

wifi: cfg80211: fix regulatory disconnect for non-MLO

2023-06-19T10:05:29+00:00

The multi-link loop here broke disconnect when multi-link
operation (MLO) isn't active for a given interface, since
in that case valid_links is 0 (indicating no links, i.e.
no MLO.)

Fix this by taking that into account properly and skipping
the link only if there are valid_links in the first place.

Cc: stable@vger.kernel.org
Fixes: 7b0a0e3c3a88 ("wifi: cfg80211: do some rework towards MLO link APIs")
Signed-off-by: Johannes Berg 
Link: https://lore.kernel.org/r/20230616222844.eb073d650c75.I72739923ef80919889ea9b50de9e4ba4baa836ae@changeid
Signed-off-by: Johannes Berg