linux.git/net/wireless/reg.c, branch v5.19 Linux kernel source tree cfg80211: declare MODULE_FIRMWARE for regulatory.db 2022-05-04T10:32:39+00:00 Dimitri John Ledkov dimitri.ledkov@canonical.com 2022-04-14T12:50:03+00:00 7bc7981eeebe1b8e603ad2ffc5e84f4df76920dd Add MODULE_FIRMWARE declarations for regulatory.db and regulatory.db.p7s such that userspace tooling can discover and include these files. Cc: stable@vger.kernel.org Signed-off-by: Dimitri John Ledkov <dimitri.ledkov@canonical.com> Link: https://lore.kernel.org/r/20220414125004.267819-1-dimitri.ledkov@canonical.com Signed-off-by: Johannes Berg <johannes.berg@intel.com> 
Add MODULE_FIRMWARE declarations for regulatory.db and
regulatory.db.p7s such that userspace tooling can discover and include
these files.

Cc: stable@vger.kernel.org
Signed-off-by: Dimitri John Ledkov <dimitri.ledkov@canonical.com>
Link: https://lore.kernel.org/r/20220414125004.267819-1-dimitri.ledkov@canonical.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
nl80211: add support for 320MHz channel limitation 2022-02-16T14:43:02+00:00 Sriram R quic_srirrama@quicinc.com 2022-02-14T16:29:56+00:00 c2b3d7699fb0ce66538b829af43970acc2f89060 Add support to advertise drivers or regulatory limitations on 320 MHz channels to userspace. Signed-off-by: Sriram R <quic_srirrama@quicinc.com> Co-authored-by: Karthikeyan Periyasamy <quic_periyasia@quicinc.com> Signed-off-by: Karthikeyan Periyasamy <quic_periyasia@quicinc.com> Co-authored-by: Veerendranath Jakkam <quic_vjakkam@quicinc.com> Signed-off-by: Veerendranath Jakkam <quic_vjakkam@quicinc.com> Link: https://lore.kernel.org/r/1640163883-12696-6-git-send-email-quic_vjakkam@quicinc.com Link: https://lore.kernel.org/r/20220214163009.175289-3-johannes@sipsolutions.net Signed-off-by: Johannes Berg <johannes.berg@intel.com> 
Add support to advertise drivers or regulatory limitations on 320 MHz
channels to userspace.

Signed-off-by: Sriram R <quic_srirrama@quicinc.com>
Co-authored-by: Karthikeyan Periyasamy <quic_periyasia@quicinc.com>
Signed-off-by: Karthikeyan Periyasamy <quic_periyasia@quicinc.com>
Co-authored-by: Veerendranath Jakkam <quic_vjakkam@quicinc.com>
Signed-off-by: Veerendranath Jakkam <quic_vjakkam@quicinc.com>
Link: https://lore.kernel.org/r/1640163883-12696-6-git-send-email-quic_vjakkam@quicinc.com
Link: https://lore.kernel.org/r/20220214163009.175289-3-johannes@sipsolutions.net
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Merge tag 'mac80211-next-for-net-next-2021-12-21' of git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211-next 2021-12-21T15:41:52+00:00 Jakub Kicinski kuba@kernel.org 2021-12-21T15:41:47+00:00 294e70c952b494918f139670cf5a89839a2e03e6 Johannes Berg says: ==================== This time we have: * ndo_fill_forward_path support in mac80211, to let drivers use it * association comeback notification for userspace, to be able to react more sensibly to long delays * support for background radar detection hardware in some chipsets * SA Query Procedures offload on the AP side * more logging if we find problems with HT/VHT/HE * various cleanups and minor fixes Conflicts: net/wireless/reg.c: e08ebd6d7b90 ("cfg80211: Acquire wiphy mutex on regulatory work") 701fdfe348f7 ("cfg80211: Enable regulatory enforcement checks for drivers supporting mesh iface") https://lore.kernel.org/r/20211221111950.57ecc6a7@canb.auug.org.au drivers/net/wireless/ath/ath10k/wmi.c: 7f599aeccbd2 ("cfg80211: Use the HE operation IE to determine a 6GHz BSS channel") 3bf2537ec2e3 ("ath10k: drop beacon and probe response which leak from other channel") https://lore.kernel.org/r/20211221115004.1cd6b262@canb.auug.org.au * tag 'mac80211-next-for-net-next-2021-12-21' of git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211-next: (32 commits) cfg80211: Enable regulatory enforcement checks for drivers supporting mesh iface rfkill: allow to get the software rfkill state cfg80211: refactor cfg80211_get_ies_channel_number() nl82011: clarify interface combinations wrt. channels nl80211: Add support to offload SA Query procedures for AP SME device nl80211: Add support to set AP settings flags with single attribute mac80211: add more HT/VHT/HE state logging cfg80211: Use the HE operation IE to determine a 6GHz BSS channel cfg80211: rename offchannel_chain structs to background_chain to avoid confusion with ETSI standard mac80211: Notify cfg80211 about association comeback cfg80211: Add support for notifying association comeback mac80211: introduce channel switch disconnect function cfg80211: Fix order of enum nl80211_band_iftype_attr documentation cfg80211: simplify cfg80211_chandef_valid() mac80211: Remove a couple of obsolete TODO mac80211: fix FEC flag in radio tap header mac80211: use coarse boottime for airtime fairness code ieee80211: change HE nominal packet padding value defines cfg80211: use ieee80211_bss_get_elem() instead of _get_ie() mac80211: Use memset_after() to clear tx status ... ==================== Link: https://lore.kernel.org/r/20211221112532.28708-1-johannes@sipsolutions.net Signed-off-by: Jakub Kicinski <kuba@kernel.org> 
Johannes Berg says:

====================
This time we have:
 * ndo_fill_forward_path support in mac80211, to let drivers use it
 * association comeback notification for userspace, to be able
   to react more sensibly to long delays
 * support for background radar detection hardware in some chipsets
 * SA Query Procedures offload on the AP side
 * more logging if we find problems with HT/VHT/HE
 * various cleanups and minor fixes

Conflicts:

net/wireless/reg.c:
  e08ebd6d7b90 ("cfg80211: Acquire wiphy mutex on regulatory work")
  701fdfe348f7 ("cfg80211: Enable regulatory enforcement checks for drivers supporting mesh iface")
  https://lore.kernel.org/r/20211221111950.57ecc6a7@canb.auug.org.au

drivers/net/wireless/ath/ath10k/wmi.c:
  7f599aeccbd2 ("cfg80211: Use the HE operation IE to determine a 6GHz BSS channel")
  3bf2537ec2e3 ("ath10k: drop beacon and probe response which leak from other channel")
  https://lore.kernel.org/r/20211221115004.1cd6b262@canb.auug.org.au

* tag 'mac80211-next-for-net-next-2021-12-21' of git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211-next: (32 commits)
  cfg80211: Enable regulatory enforcement checks for drivers supporting mesh iface
  rfkill: allow to get the software rfkill state
  cfg80211: refactor cfg80211_get_ies_channel_number()
  nl82011: clarify interface combinations wrt. channels
  nl80211: Add support to offload SA Query procedures for AP SME device
  nl80211: Add support to set AP settings flags with single attribute
  mac80211: add more HT/VHT/HE state logging
  cfg80211: Use the HE operation IE to determine a 6GHz BSS channel
  cfg80211: rename offchannel_chain structs to background_chain to avoid confusion with ETSI standard
  mac80211: Notify cfg80211 about association comeback
  cfg80211: Add support for notifying association comeback
  mac80211: introduce channel switch disconnect function
  cfg80211: Fix order of enum nl80211_band_iftype_attr documentation
  cfg80211: simplify cfg80211_chandef_valid()
  mac80211: Remove a couple of obsolete TODO
  mac80211: fix FEC flag in radio tap header
  mac80211: use coarse boottime for airtime fairness code
  ieee80211: change HE nominal packet padding value defines
  cfg80211: use ieee80211_bss_get_elem() instead of _get_ie()
  mac80211: Use memset_after() to clear tx status
  ...
====================

Link: https://lore.kernel.org/r/20211221112532.28708-1-johannes@sipsolutions.net
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
cfg80211: Enable regulatory enforcement checks for drivers supporting mesh iface 2021-12-20T10:18:30+00:00 Sriram R quic_srirrama@quicinc.com 2021-12-02T01:38:40+00:00 701fdfe348f7e5c9fe71caa3558d63dbb4bc4b81 Currently cfg80211 checks for invalid channels whenever there is a regulatory update and stops the active interfaces if it is operating on an unsupported channel in the new regulatory domain. This is done based on a regulatory flag REGULATORY_IGNORE_STALE_KICKOFF set during wiphy registration which disables this enforcement when unsupported interface modes are supported by driver. Add support to enable this enforcement when Mesh Point interface type is advertised by drivers. Signed-off-by: Sriram R <quic_srirrama@quicinc.com> Link: https://lore.kernel.org/r/1638409120-28997-1-git-send-email-quic_srirrama@quicinc.com Signed-off-by: Johannes Berg <johannes.berg@intel.com> 
Currently cfg80211 checks for invalid channels whenever there is a
regulatory update and stops the active interfaces if it is operating on
an unsupported channel in the new regulatory domain.

This is done based on a regulatory flag REGULATORY_IGNORE_STALE_KICKOFF
set during wiphy registration which disables this enforcement when
unsupported interface modes are supported by driver.

Add support to enable this enforcement when Mesh Point interface type
is advertised by drivers.

Signed-off-by: Sriram R <quic_srirrama@quicinc.com>
Link: https://lore.kernel.org/r/1638409120-28997-1-git-send-email-quic_srirrama@quicinc.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
cfg80211: Acquire wiphy mutex on regulatory work 2021-12-14T10:20:11+00:00 Ilan Peer ilan.peer@intel.com 2021-12-02T13:28:54+00:00 e08ebd6d7b90ae81f21425ca39136f5b2272580f The function cfg80211_reg_can_beacon_relax() expects wiphy mutex to be held when it is being called. However, when reg_leave_invalid_chans() is called the mutex is not held. Fix it by acquiring the lock before calling the function. Fixes: a05829a7222e ("cfg80211: avoid holding the RTNL when calling the driver") Signed-off-by: Ilan Peer <ilan.peer@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20211202152831.527686cda037.I40ad9372a47cbad53b4aae7b5a6ccc0dc3fddf8b@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com> 
The function cfg80211_reg_can_beacon_relax() expects wiphy
mutex to be held when it is being called. However, when
reg_leave_invalid_chans() is called the mutex is not held.
Fix it by acquiring the lock before calling the function.

Fixes: a05829a7222e ("cfg80211: avoid holding the RTNL when calling the driver")
Signed-off-by: Ilan Peer <ilan.peer@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20211202152831.527686cda037.I40ad9372a47cbad53b4aae7b5a6ccc0dc3fddf8b@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
nl80211: remove reload flag from regulatory_request 2021-12-14T10:18:46+00:00 Finn Behrens me@kloenk.de 2021-12-01T12:49:18+00:00 37d33114240ede043c42463a6347f68ed72d6904 This removes the previously unused reload flag, which was introduced in 1eda919126b4. The request is handled as NL80211_REGDOM_SET_BY_CORE, which is parsed unconditionally. Reported-by: kernel test robot <lkp@intel.com> Reported-by: Nathan Chancellor <nathan@kernel.org> Fixes: 1eda919126b4 ("nl80211: reset regdom when reloading regdb") Link: https://lore.kernel.org/all/YaZuKYM5bfWe2Urn@archlinux-ax161/ Signed-off-by: Finn Behrens <me@kloenk.de> Reviewed-by: Nathan Chancellor <nathan@kernel.org> Link: https://lore.kernel.org/r/YadvTolO8rQcNCd/@gimli.kloenk.dev Signed-off-by: Johannes Berg <johannes.berg@intel.com> 
This removes the previously unused reload flag, which was introduced in
1eda919126b4.
The request is handled as NL80211_REGDOM_SET_BY_CORE, which is parsed
unconditionally.

Reported-by: kernel test robot <lkp@intel.com>
Reported-by: Nathan Chancellor <nathan@kernel.org>
Fixes: 1eda919126b4 ("nl80211: reset regdom when reloading regdb")
Link: https://lore.kernel.org/all/YaZuKYM5bfWe2Urn@archlinux-ax161/
Signed-off-by: Finn Behrens <me@kloenk.de>
Reviewed-by: Nathan Chancellor <nathan@kernel.org>
Link: https://lore.kernel.org/r/YadvTolO8rQcNCd/@gimli.kloenk.dev
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
nl80211: reset regdom when reloading regdb 2021-11-29T08:31:56+00:00 Finn Behrens me@kloenk.dev 2021-11-27T10:28:53+00:00 1eda919126b420fee6b8d546f7f728fbbd4b8f11 Reload the regdom when the regulatory db is reloaded. Otherwise, the user had to change the regulatoy domain to a different one and then reset it to the correct one to have a new regulatory db take effect after a reload. Signed-off-by: Finn Behrens <fin@nyantec.com> Link: https://lore.kernel.org/r/YaIIZfxHgqc/UTA7@gimli.kloenk.dev [edit commit message] Signed-off-by: Johannes Berg <johannes.berg@intel.com> 
Reload the regdom when the regulatory db is reloaded.
Otherwise, the user had to change the regulatoy domain
to a different one and then reset it to the correct
one to have a new regulatory db take effect after a
reload.

Signed-off-by: Finn Behrens <fin@nyantec.com>
Link: https://lore.kernel.org/r/YaIIZfxHgqc/UTA7@gimli.kloenk.dev
[edit commit message]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
cfg80211: use wiphy DFS domain if it is self-managed 2021-08-26T09:04:55+00:00 Sriram R srirrama@codeaurora.org 2021-08-25T23:38:50+00:00 90bd5bee50f2a209ba66f013866959a56ff400b9 Currently during CAC start or other radar events, the DFS domain is fetched from cfg based on global DFS domain, even if the wiphy regdomain disagrees. But this could be different in case of self managed wiphy's in case the self managed driver updates its database or supports regions which has DFS domain set to UNSET in cfg80211 local regdomain. So for explicitly self-managed wiphys, just use their DFS domain. Signed-off-by: Sriram R <srirrama@codeaurora.org> Link: https://lore.kernel.org/r/1629934730-16388-1-git-send-email-srirrama@codeaurora.org Signed-off-by: Johannes Berg <johannes.berg@intel.com> 
Currently during CAC start or other radar events, the DFS
domain is fetched from cfg based on global DFS domain,
even if the wiphy regdomain disagrees.

But this could be different in case of self managed wiphy's
in case the self managed driver updates its database or supports
regions which has DFS domain set to UNSET in cfg80211 local
regdomain.

So for explicitly self-managed wiphys, just use their DFS
domain.

Signed-off-by: Sriram R <srirrama@codeaurora.org>
Link: https://lore.kernel.org/r/1629934730-16388-1-git-send-email-srirrama@codeaurora.org
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
cfg80211: set custom regdomain after wiphy registration 2021-06-23T11:05:09+00:00 Miri Korenblit miriam.rachel.korenblit@intel.com 2021-06-18T10:41:46+00:00 1b7b3ac8ff3317cdcf07a1c413de9bdb68019c2b We used to set regulatory info before the registration of the device and then the regulatory info didn't get set, because the device isn't registered so there isn't a device to set the regulatory info for. So set the regulatory info after the device registration. Call reg_process_self_managed_hints() once again after the device registration because it does nothing before it. Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20210618133832.c96eadcffe80.I86799c2c866b5610b4cf91115c21d8ceb525c5aa@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com> 
We used to set regulatory info before the registration of
the device and then the regulatory info didn't get set, because
the device isn't registered so there isn't a device to set the
regulatory info for. So set the regulatory info after the device
registration.
Call reg_process_self_managed_hints() once again after the device
registration because it does nothing before it.

Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20210618133832.c96eadcffe80.I86799c2c866b5610b4cf91115c21d8ceb525c5aa@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
cfg80211: reg: improve bad regulatory warning 2021-06-23T10:42:49+00:00 Johannes Berg johannes.berg@intel.com 2021-06-18T10:41:56+00:00 b767ecdaf98a999ef710f4f290bdd89257a90db0 There's a WARN_ON here but it says nothing, and the later dump of the regdomain aren't usually printed. As a first step, include the regdomain code in the WARN_ON message, just like in other similar instances. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20210618133832.853ffdd6c62b.I63e37b2ab184ee3653686e4df4dd23eb303687d2@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com> 
There's a WARN_ON here but it says nothing, and the later
dump of the regdomain aren't usually printed. As a first
step, include the regdomain code in the WARN_ON message,
just like in other similar instances.

Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20210618133832.853ffdd6c62b.I63e37b2ab184ee3653686e4df4dd23eb303687d2@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>