<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-dev/net/wireless/mlme.c, branch linus/master</title>
<subtitle>Linux kernel development work - see feature branches</subtitle>
<id>https://git.zx2c4.com/linux-dev/atom/net/wireless/mlme.c?h=linus%2Fmaster</id>
<link rel='self' href='https://git.zx2c4.com/linux-dev/atom/net/wireless/mlme.c?h=linus%2Fmaster'/>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/'/>
<updated>2021-12-20T09:37:36Z</updated>
<entry>
<title>cfg80211: rename offchannel_chain structs to background_chain to avoid confusion with ETSI standard</title>
<updated>2021-12-20T09:37:36Z</updated>
<author>
<name>Lorenzo Bianconi</name>
<email>lorenzo@kernel.org</email>
</author>
<published>2021-11-29T13:11:24Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/commit/?id=a95bfb876fa87e2d0fa718ee61a8030ddf162d2b'/>
<id>urn:sha1:a95bfb876fa87e2d0fa718ee61a8030ddf162d2b</id>
<content type='text'>
ETSI standard defines "Offchannel CAC" as:
"Off-Channel CAC is performed by a number of non-continuous checks
spread over a period in time. This period, which is required to
determine the presence of radar signals, is defined as the Off-Channel
CAC Time..
Minimum Off-Channel CAC Time 6 minutes and Maximum Off-Channel CAC Time
4 hours..".
mac80211 implementation refers to a dedicated hw chain used for continuous
radar monitoring. Rename offchannel_* references to background_* in
order to avoid confusion with ETSI standard.

Signed-off-by: Lorenzo Bianconi &lt;lorenzo@kernel.org&gt;
Link: https://lore.kernel.org/r/4204cc1d648d76b44557981713231e030a3bd991.1638190762.git.lorenzo@kernel.org
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
</content>
</entry>
<entry>
<title>cfg80211: allow continuous radar monitoring on offchannel chain</title>
<updated>2021-11-26T10:50:27Z</updated>
<author>
<name>Lorenzo Bianconi</name>
<email>lorenzo@kernel.org</email>
</author>
<published>2021-11-16T14:03:36Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/commit/?id=8415816493b7589e74ff4e1e7eaf3aadc7b73621'/>
<id>urn:sha1:8415816493b7589e74ff4e1e7eaf3aadc7b73621</id>
<content type='text'>
Allow continuous radar detection on the offchannel chain in order
to switch to the monitored channel whenever the underlying driver
reports a radar pattern on the main channel.

Tested-by: Owen Peng &lt;owen.peng@mediatek.com&gt;
Signed-off-by: Lorenzo Bianconi &lt;lorenzo@kernel.org&gt;
Link: https://lore.kernel.org/r/d46217310a49b14ff0e9c002f0a6e0547d70fd2c.1637071350.git.lorenzo@kernel.org
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
</content>
</entry>
<entry>
<title>cfg80211: schedule offchan_cac_abort_wk in cfg80211_radar_event</title>
<updated>2021-11-26T10:49:54Z</updated>
<author>
<name>Lorenzo Bianconi</name>
<email>lorenzo@kernel.org</email>
</author>
<published>2021-11-16T11:41:52Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/commit/?id=c47240cb46a10c40686ce4e25c64aaed676f71c9'/>
<id>urn:sha1:c47240cb46a10c40686ce4e25c64aaed676f71c9</id>
<content type='text'>
If necessary schedule offchan_cac_abort_wk work in cfg80211_radar_event
routine adding offchan parameter to cfg80211_radar_event signature.
Rename cfg80211_radar_event in __cfg80211_radar_event and introduce
the two following inline helpers:
- cfg80211_radar_event
- cfg80211_offchan_radar_event
Doing so the drv will not need to run cfg80211_offchan_cac_abort() after
radar detection on the offchannel chain.

Tested-by: Owen Peng &lt;owen.peng@mediatek.com&gt;
Signed-off-by: Lorenzo Bianconi &lt;lorenzo@kernel.org&gt;
Link: https://lore.kernel.org/r/3ff583e021e3343a3ced54a7b09b5e184d1880dc.1637062727.git.lorenzo@kernel.org
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
</content>
</entry>
<entry>
<title>cfg80211: fix possible NULL pointer dereference in cfg80211_stop_offchan_radar_detection</title>
<updated>2021-11-26T10:46:12Z</updated>
<author>
<name>Lorenzo Bianconi</name>
<email>lorenzo@kernel.org</email>
</author>
<published>2021-11-03T17:02:35Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/commit/?id=91e89c77322d2a65ede9f418642942f3c096a63b'/>
<id>urn:sha1:91e89c77322d2a65ede9f418642942f3c096a63b</id>
<content type='text'>
Fix the following NULL pointer dereference in
cfg80211_stop_offchan_radar_detection routine that occurs when hostapd
is stopped during the CAC on offchannel chain:

Sat Jan  1 0[  779.567851]   ESR = 0x96000005
0:12:50 2000 dae[  779.572346]   EC = 0x25: DABT (current EL), IL = 32 bits
mon.debug hostap[  779.578984]   SET = 0, FnV = 0
d: hostapd_inter[  779.583445]   EA = 0, S1PTW = 0
face_deinit_free[  779.587936] Data abort info:
: num_bss=1 conf[  779.592224]   ISV = 0, ISS = 0x00000005
-&gt;num_bss=1
Sat[  779.597403]   CM = 0, WnR = 0
 Jan  1 00:12:50[  779.601749] user pgtable: 4k pages, 39-bit VAs, pgdp=00000000418b2000
 2000 daemon.deb[  779.609601] [0000000000000000] pgd=0000000000000000, p4d=0000000000000000, pud=0000000000000000
ug hostapd: host[  779.619657] Internal error: Oops: 96000005 [#1] SMP
[  779.770810] CPU: 0 PID: 2202 Comm: hostapd Not tainted 5.10.75 #0
[  779.776892] Hardware name: MediaTek MT7622 RFB1 board (DT)
[  779.782370] pstate: 80000005 (Nzcv daif -PAN -UAO -TCO BTYPE=--)
[  779.788384] pc : cfg80211_chandef_valid+0x10/0x490 [cfg80211]
[  779.794128] lr : cfg80211_check_station_change+0x3190/0x3950 [cfg80211]
[  779.800731] sp : ffffffc01204b7e0
[  779.804036] x29: ffffffc01204b7e0 x28: ffffff80039bdc00
[  779.809340] x27: 0000000000000000 x26: ffffffc008cb3050
[  779.814644] x25: 0000000000000000 x24: 0000000000000002
[  779.819948] x23: ffffff8002630000 x22: ffffff8003e748d0
[  779.825252] x21: 0000000000000cc0 x20: ffffff8003da4a00
[  779.830556] x19: 0000000000000000 x18: ffffff8001bf7ce0
[  779.835860] x17: 00000000ffffffff x16: 0000000000000000
[  779.841164] x15: 0000000040d59200 x14: 00000000000019c0
[  779.846467] x13: 00000000000001c8 x12: 000636b9e9dab1c6
[  779.851771] x11: 0000000000000141 x10: 0000000000000820
[  779.857076] x9 : 0000000000000000 x8 : ffffff8003d7d038
[  779.862380] x7 : 0000000000000000 x6 : ffffff8003d7d038
[  779.867683] x5 : 0000000000000e90 x4 : 0000000000000038
[  779.872987] x3 : 0000000000000002 x2 : 0000000000000004
[  779.878291] x1 : 0000000000000000 x0 : 0000000000000000
[  779.883594] Call trace:
[  779.886039]  cfg80211_chandef_valid+0x10/0x490 [cfg80211]
[  779.891434]  cfg80211_check_station_change+0x3190/0x3950 [cfg80211]
[  779.897697]  nl80211_radar_notify+0x138/0x19c [cfg80211]
[  779.903005]  cfg80211_stop_offchan_radar_detection+0x7c/0x8c [cfg80211]
[  779.909616]  __cfg80211_leave+0x2c/0x190 [cfg80211]
[  779.914490]  cfg80211_register_netdevice+0x1c0/0x6d0 [cfg80211]
[  779.920404]  raw_notifier_call_chain+0x50/0x70
[  779.924841]  call_netdevice_notifiers_info+0x54/0xa0
[  779.929796]  __dev_close_many+0x40/0x100
[  779.933712]  __dev_change_flags+0x98/0x190
[  779.937800]  dev_change_flags+0x20/0x60
[  779.941628]  devinet_ioctl+0x534/0x6d0
[  779.945370]  inet_ioctl+0x1bc/0x230
[  779.948849]  sock_do_ioctl+0x44/0x200
[  779.952502]  sock_ioctl+0x268/0x4c0
[  779.955985]  __arm64_sys_ioctl+0xac/0xd0
[  779.959900]  el0_svc_common.constprop.0+0x60/0x110
[  779.964682]  do_el0_svc+0x1c/0x24
[  779.967990]  el0_svc+0x10/0x1c
[  779.971036]  el0_sync_handler+0x9c/0x120
[  779.974950]  el0_sync+0x148/0x180
[  779.978259] Code: a9bc7bfd 910003fd a90153f3 aa0003f3 (f9400000)
[  779.984344] ---[ end trace 0e67b4f5d6cdeec7 ]---
[  779.996400] Kernel panic - not syncing: Oops: Fatal exception
[  780.002139] SMP: stopping secondary CPUs
[  780.006057] Kernel Offset: disabled
[  780.009537] CPU features: 0x0000002,04002004
[  780.013796] Memory Limit: none

Fixes: b8f5facf286b ("cfg80211: implement APIs for dedicated radar detection HW")
Reported-by: Evelyn Tsai &lt;evelyn.tsai@mediatek.com&gt;
Tested-by: Evelyn Tsai &lt;evelyn.tsai@mediatek.com&gt;
Signed-off-by: Lorenzo Bianconi &lt;lorenzo@kernel.org&gt;
Link: https://lore.kernel.org/r/c2e34c065bf8839c5ffa45498ae154021a72a520.1635958796.git.lorenzo@kernel.org
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
</content>
</entry>
<entry>
<title>cfg80211: move offchan_cac_event to a dedicated work</title>
<updated>2021-11-19T08:38:50Z</updated>
<author>
<name>Lorenzo Bianconi</name>
<email>lorenzo@kernel.org</email>
</author>
<published>2021-10-27T09:03:42Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/commit/?id=1507b153198137dfa9cb4bec7c5dee07089ec3af'/>
<id>urn:sha1:1507b153198137dfa9cb4bec7c5dee07089ec3af</id>
<content type='text'>
In order to make cfg80211_offchan_cac_abort() (renamed from
cfg80211_offchan_cac_event) callable in other contexts and
without so much locking restrictions, make it trigger a new
work instead of operating directly.

Do some other renames while at it to clarify.

Signed-off-by: Lorenzo Bianconi &lt;lorenzo@kernel.org&gt;
Link: https://lore.kernel.org/r/6145c3d0f30400a568023f67981981d24c7c6133.1635325205.git.lorenzo@kernel.org
[rewrite commit log]
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
</content>
</entry>
<entry>
<title>cfg80211: implement APIs for dedicated radar detection HW</title>
<updated>2021-11-19T08:38:49Z</updated>
<author>
<name>Lorenzo Bianconi</name>
<email>lorenzo@kernel.org</email>
</author>
<published>2021-10-23T09:10:50Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/commit/?id=bc2dfc02836b1133d1bf4d22aa13d48ac98eabef'/>
<id>urn:sha1:bc2dfc02836b1133d1bf4d22aa13d48ac98eabef</id>
<content type='text'>
If a dedicated (off-channel) radar detection hardware (chain)
is available in the hardware/driver, allow this to be used by
calling the NL80211_CMD_RADAR_DETECT command with a new flag
attribute requesting off-channel radar detection is used.

Offchannel CAC (channel availability check) avoids the CAC
downtime when switching to a radar channel or when turning on
the AP.

Drivers advertise support for this using the new feature flag
NL80211_EXT_FEATURE_RADAR_OFFCHAN.

Tested-by: Evelyn Tsai &lt;evelyn.tsai@mediatek.com&gt;
Signed-off-by: Lorenzo Bianconi &lt;lorenzo@kernel.org&gt;
Link: https://lore.kernel.org/r/7468e291ef5d05d692c1738d25b8f778d8ea5c3f.1634979655.git.lorenzo@kernel.org
Link: https://lore.kernel.org/r/1e60e60fef00e14401adae81c3d49f3e5f307537.1634979655.git.lorenzo@kernel.org
Link: https://lore.kernel.org/r/85fa50f57fc3adb2934c8d9ca0be30394de6b7e8.1634979655.git.lorenzo@kernel.org
Link: https://lore.kernel.org/r/4b6c08671ad59aae0ac46fc94c02f31b1610eb72.1634979655.git.lorenzo@kernel.org
Link: https://lore.kernel.org/r/241849ccaf2c228873c6f8495bf87b19159ba458.1634979655.git.lorenzo@kernel.org
[remove offchan_mutex, fix cfg80211_stop_offchan_radar_detection(),
 remove gfp_t argument, fix documentation, fix tracing]
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
</content>
</entry>
<entry>
<title>cfg80211: fix management registrations locking</title>
<updated>2021-10-25T13:20:22Z</updated>
<author>
<name>Johannes Berg</name>
<email>johannes.berg@intel.com</email>
</author>
<published>2021-10-25T11:31:12Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/commit/?id=09b1d5dc6ce1c9151777f6c4e128a59457704c97'/>
<id>urn:sha1:09b1d5dc6ce1c9151777f6c4e128a59457704c97</id>
<content type='text'>
The management registrations locking was broken, the list was
locked for each wdev, but cfg80211_mgmt_registrations_update()
iterated it without holding all the correct spinlocks, causing
list corruption.

Rather than trying to fix it with fine-grained locking, just
move the lock to the wiphy/rdev (still need the list on each
wdev), we already need to hold the wdev lock to change it, so
there's no contention on the lock in any case. This trivially
fixes the bug since we hold one wdev's lock already, and now
will hold the lock that protects all lists.

Cc: stable@vger.kernel.org
Reported-by: Jouni Malinen &lt;j@w1.fi&gt;
Fixes: 6cd536fe62ef ("cfg80211: change internal management frame registration API")
Link: https://lore.kernel.org/r/20211025133111.5cf733eab0f4.I7b0abb0494ab712f74e2efcd24bb31ac33f7eee9@changeid
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
</content>
</entry>
<entry>
<title>cfg80211: avoid holding the RTNL when calling the driver</title>
<updated>2021-01-26T10:55:50Z</updated>
<author>
<name>Johannes Berg</name>
<email>johannes.berg@intel.com</email>
</author>
<published>2021-01-22T15:19:43Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/commit/?id=a05829a7222e9d10c416dd2dbbf3929fe6646b89'/>
<id>urn:sha1:a05829a7222e9d10c416dd2dbbf3929fe6646b89</id>
<content type='text'>
Currently, _everything_ in cfg80211 holds the RTNL, and if you
have a slow USB device (or a few) you can get some bad lock
contention on that.

Fix that by re-adding a mutex to each wiphy/rdev as we had at
some point, so we have locking for the wireless_dev lists and
all the other things in there, and also so that drivers still
don't have to worry too much about it (they still won't get
parallel calls for a single device).

Then, we can restrict the RTNL to a few cases where we add or
remove interfaces and really need the added protection. Some
of the global list management still also uses the RTNL, since
we need to have it anyway for netdev management, but we only
hold the RTNL for very short periods of time here.

Link: https://lore.kernel.org/r/20210122161942.81df9f5e047a.I4a8e1a60b18863ea8c5e6d3a0faeafb2d45b2f40@changeid
Tested-by: Marek Szyprowski &lt;m.szyprowski@samsung.com&gt; [marvell driver issues]
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
</content>
</entry>
<entry>
<title>cfg80211: support immediate reconnect request hint</title>
<updated>2020-12-11T12:20:05Z</updated>
<author>
<name>Johannes Berg</name>
<email>johannes.berg@intel.com</email>
</author>
<published>2020-12-06T12:54:42Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/commit/?id=3bb02143ff55fec55558da4ad48425bf368eb8ed'/>
<id>urn:sha1:3bb02143ff55fec55558da4ad48425bf368eb8ed</id>
<content type='text'>
There are cases where it's necessary to disconnect, but an
immediate reconnection is desired. Support a hint to userspace
that this is the case, by including a new attribute in the
deauth or disassoc event.

Signed-off-by: Luca Coelho &lt;luciano.coelho@intel.com&gt;
Link: https://lore.kernel.org/r/iwlwifi.20201206145305.58d33941fb9d.I0e7168c205c7949529c8e3b86f3c9b12c01a7017@changeid
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
</content>
</entry>
<entry>
<title>cfg80211: handle Association Response from S1G STA</title>
<updated>2020-09-28T11:54:03Z</updated>
<author>
<name>Thomas Pedersen</name>
<email>thomas@adapt-ip.com</email>
</author>
<published>2020-09-22T02:28:09Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/commit/?id=80ca25711380c8eabe51eed875ca9432b4f8939e'/>
<id>urn:sha1:80ca25711380c8eabe51eed875ca9432b4f8939e</id>
<content type='text'>
The sending STA type is implicit based on beacon or probe
response content. If sending STA was an S1G STA, adjust
the Information Element location accordingly.

Signed-off-by: Thomas Pedersen &lt;thomas@adapt-ip.com&gt;
Link: https://lore.kernel.org/r/20200922022818.15855-9-thomas@adapt-ip.com
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
</content>
</entry>
</feed>
