<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-stable.git/drivers/net/wireless, branch v5.10</title>
<subtitle>Linux kernel stable tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/'/>
<entry>
<title>rtw88: debug: Fix uninitialized memory in debugfs code</title>
<updated>2020-12-03T16:00:45+00:00</updated>
<author>
<name>Dan Carpenter</name>
<email>dan.carpenter@oracle.com</email>
</author>
<published>2020-12-03T08:43:37+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=74a8c816fa8fa7862df870660e9821abb56649fe'/>
<id>74a8c816fa8fa7862df870660e9821abb56649fe</id>
<content type='text'>
This code does not ensure that the whole buffer is initialized and none
of the callers check for errors so potentially none of the buffer is
initialized.  Add a memset to eliminate this bug.

Fixes: e3037485c68e ("rtw88: new Realtek 802.11ac driver")
Signed-off-by: Dan Carpenter &lt;dan.carpenter@oracle.com&gt;
Signed-off-by: Kalle Valo &lt;kvalo@codeaurora.org&gt;
Link: https://lore.kernel.org/r/X8ilOfVz3pf0T5ec@mwanda
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This code does not ensure that the whole buffer is initialized and none
of the callers check for errors so potentially none of the buffer is
initialized.  Add a memset to eliminate this bug.

Fixes: e3037485c68e ("rtw88: new Realtek 802.11ac driver")
Signed-off-by: Dan Carpenter &lt;dan.carpenter@oracle.com&gt;
Signed-off-by: Kalle Valo &lt;kvalo@codeaurora.org&gt;
Link: https://lore.kernel.org/r/X8ilOfVz3pf0T5ec@mwanda
</pre>
</div>
</content>
</entry>
<entry>
<title>mt76: usb: fix crash on device removal</title>
<updated>2020-12-02T19:06:10+00:00</updated>
<author>
<name>Stanislaw Gruszka</name>
<email>stf_xl@wp.pl</email>
</author>
<published>2020-11-26T12:55:20+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=807982017730cfe853fce49ba26d453e31c84898'/>
<id>807982017730cfe853fce49ba26d453e31c84898</id>
<content type='text'>
Currently 'while (q-&gt;queued &gt; 0)' loop was removed from mt76u_stop_tx()
code. This causes crash on device removal as we try to cleanup empty
queue:

[   96.495571] kernel BUG at include/linux/skbuff.h:2297!
[   96.498983] invalid opcode: 0000 [#1] SMP PTI
[   96.501162] CPU: 3 PID: 27 Comm: kworker/3:0 Not tainted 5.10.0-rc5+ #11
[   96.502754] Hardware name: LENOVO 20DGS08H00/20DGS08H00, BIOS J5ET48WW (1.19 ) 08/27/2015
[   96.504378] Workqueue: usb_hub_wq hub_event
[   96.505983] RIP: 0010:skb_pull+0x2d/0x30
[   96.507576] Code: 00 00 8b 47 70 39 c6 77 1e 29 f0 89 47 70 3b 47 74 72 17 48 8b 87 c8 00 00 00 89 f6 48 01 f0 48 89 87 c8 00 00 00 c3 31 c0 c3 &lt;0f&gt; 0b 90 0f 1f 44 00 00 53 48 89 fb 48 8b bf c8 00 00 00 8b 43 70
[   96.509296] RSP: 0018:ffffb11b801639b8 EFLAGS: 00010287
[   96.511038] RAX: 000000001c6939ed RBX: ffffb11b801639f8 RCX: 0000000000000000
[   96.512964] RDX: ffffb11b801639f8 RSI: 0000000000000018 RDI: ffff90c64e4fb800
[   96.514710] RBP: ffff90c654551ee0 R08: ffff90c652bce7a8 R09: ffffb11b80163728
[   96.516450] R10: 0000000000000001 R11: 0000000000000001 R12: ffff90c64e4fb800
[   96.519749] R13: 0000000000000010 R14: 0000000000000020 R15: ffff90c64e352ce8
[   96.523455] FS:  0000000000000000(0000) GS:ffff90c96eec0000(0000) knlGS:0000000000000000
[   96.527171] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[   96.530900] CR2: 0000242556f18288 CR3: 0000000146a10002 CR4: 00000000003706e0
[   96.534678] Call Trace:
[   96.538418]  mt76x02u_tx_complete_skb+0x1f/0x50 [mt76x02_usb]
[   96.542231]  mt76_queue_tx_complete+0x23/0x50 [mt76]
[   96.546028]  mt76u_stop_tx.cold+0x71/0xa2 [mt76_usb]
[   96.549797]  mt76x0u_stop+0x2f/0x90 [mt76x0u]
[   96.553638]  drv_stop+0x33/0xd0 [mac80211]
[   96.557449]  ieee80211_do_stop+0x558/0x860 [mac80211]
[   96.561262]  ? dev_deactivate_many+0x298/0x2d0
[   96.565101]  ieee80211_stop+0x16/0x20 [mac80211]

Fix that by adding while loop again. We need loop, not just single
check, to clean all pending entries.

Additionally move mt76_worker_disable/enable after !mt76_has_tx_pending()
as we want to tx_worker to run to process tx queues, while we wait for
exactly that.

I was a bit worried about accessing q-&gt;queued without lock, but
mt76_worker_disable() -&gt; kthread_park() should assure this value will
be seen updated on other cpus.

Fixes: fe5b5ab52e9d ("mt76: unify queue tx cleanup code")
Signed-off-by: Stanislaw Gruszka &lt;stf_xl@wp.pl&gt;
Acked-by: Felix Fietkau &lt;nbd@nbd.name&gt;
Signed-off-by: Kalle Valo &lt;kvalo@codeaurora.org&gt;
Link: https://lore.kernel.org/r/20201126125520.72912-1-stf_xl@wp.pl
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Currently 'while (q-&gt;queued &gt; 0)' loop was removed from mt76u_stop_tx()
code. This causes crash on device removal as we try to cleanup empty
queue:

[   96.495571] kernel BUG at include/linux/skbuff.h:2297!
[   96.498983] invalid opcode: 0000 [#1] SMP PTI
[   96.501162] CPU: 3 PID: 27 Comm: kworker/3:0 Not tainted 5.10.0-rc5+ #11
[   96.502754] Hardware name: LENOVO 20DGS08H00/20DGS08H00, BIOS J5ET48WW (1.19 ) 08/27/2015
[   96.504378] Workqueue: usb_hub_wq hub_event
[   96.505983] RIP: 0010:skb_pull+0x2d/0x30
[   96.507576] Code: 00 00 8b 47 70 39 c6 77 1e 29 f0 89 47 70 3b 47 74 72 17 48 8b 87 c8 00 00 00 89 f6 48 01 f0 48 89 87 c8 00 00 00 c3 31 c0 c3 &lt;0f&gt; 0b 90 0f 1f 44 00 00 53 48 89 fb 48 8b bf c8 00 00 00 8b 43 70
[   96.509296] RSP: 0018:ffffb11b801639b8 EFLAGS: 00010287
[   96.511038] RAX: 000000001c6939ed RBX: ffffb11b801639f8 RCX: 0000000000000000
[   96.512964] RDX: ffffb11b801639f8 RSI: 0000000000000018 RDI: ffff90c64e4fb800
[   96.514710] RBP: ffff90c654551ee0 R08: ffff90c652bce7a8 R09: ffffb11b80163728
[   96.516450] R10: 0000000000000001 R11: 0000000000000001 R12: ffff90c64e4fb800
[   96.519749] R13: 0000000000000010 R14: 0000000000000020 R15: ffff90c64e352ce8
[   96.523455] FS:  0000000000000000(0000) GS:ffff90c96eec0000(0000) knlGS:0000000000000000
[   96.527171] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[   96.530900] CR2: 0000242556f18288 CR3: 0000000146a10002 CR4: 00000000003706e0
[   96.534678] Call Trace:
[   96.538418]  mt76x02u_tx_complete_skb+0x1f/0x50 [mt76x02_usb]
[   96.542231]  mt76_queue_tx_complete+0x23/0x50 [mt76]
[   96.546028]  mt76u_stop_tx.cold+0x71/0xa2 [mt76_usb]
[   96.549797]  mt76x0u_stop+0x2f/0x90 [mt76x0u]
[   96.553638]  drv_stop+0x33/0xd0 [mac80211]
[   96.557449]  ieee80211_do_stop+0x558/0x860 [mac80211]
[   96.561262]  ? dev_deactivate_many+0x298/0x2d0
[   96.565101]  ieee80211_stop+0x16/0x20 [mac80211]

Fix that by adding while loop again. We need loop, not just single
check, to clean all pending entries.

Additionally move mt76_worker_disable/enable after !mt76_has_tx_pending()
as we want to tx_worker to run to process tx queues, while we wait for
exactly that.

I was a bit worried about accessing q-&gt;queued without lock, but
mt76_worker_disable() -&gt; kthread_park() should assure this value will
be seen updated on other cpus.

Fixes: fe5b5ab52e9d ("mt76: unify queue tx cleanup code")
Signed-off-by: Stanislaw Gruszka &lt;stf_xl@wp.pl&gt;
Acked-by: Felix Fietkau &lt;nbd@nbd.name&gt;
Signed-off-by: Kalle Valo &lt;kvalo@codeaurora.org&gt;
Link: https://lore.kernel.org/r/20201126125520.72912-1-stf_xl@wp.pl
</pre>
</div>
</content>
</entry>
<entry>
<title>iwlwifi: pcie: add some missing entries for AX210</title>
<updated>2020-12-02T19:01:35+00:00</updated>
<author>
<name>Golan Ben Ami</name>
<email>golan.ben.ami@intel.com</email>
</author>
<published>2020-12-02T12:41:51+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=9b15596c5006d82b2f82810e8cbf80d8c6e7e7b4'/>
<id>9b15596c5006d82b2f82810e8cbf80d8c6e7e7b4</id>
<content type='text'>
Some subsytem device IDs were missing from the list, so some AX210
devices were not recognized.  Add them.

Signed-off-by: Golan Ben Ami &lt;golan.ben.ami@intel.com&gt;
Signed-off-by: Luca Coelho &lt;luciano.coelho@intel.com&gt;
Signed-off-by: Kalle Valo &lt;kvalo@codeaurora.org&gt;
Link: https://lore.kernel.org/r/iwlwifi.20201202143859.a06ba7540449.I7390305d088a49c1043c9b489154fe057989c18f@changeid
Link: https://lore.kernel.org/r/20201121003411.9450-1-ikegami.t@gmail.com
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Some subsytem device IDs were missing from the list, so some AX210
devices were not recognized.  Add them.

Signed-off-by: Golan Ben Ami &lt;golan.ben.ami@intel.com&gt;
Signed-off-by: Luca Coelho &lt;luciano.coelho@intel.com&gt;
Signed-off-by: Kalle Valo &lt;kvalo@codeaurora.org&gt;
Link: https://lore.kernel.org/r/iwlwifi.20201202143859.a06ba7540449.I7390305d088a49c1043c9b489154fe057989c18f@changeid
Link: https://lore.kernel.org/r/20201121003411.9450-1-ikegami.t@gmail.com
</pre>
</div>
</content>
</entry>
<entry>
<title>iwlwifi: pcie: invert values of NO_160 device config entries</title>
<updated>2020-12-02T19:01:33+00:00</updated>
<author>
<name>Luca Coelho</name>
<email>luciano.coelho@intel.com</email>
</author>
<published>2020-12-02T12:41:50+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=568d3434178b00274615190a19d29c3d235b4e6d'/>
<id>568d3434178b00274615190a19d29c3d235b4e6d</id>
<content type='text'>
The NO_160 flag specifies if the device doesn't have 160 MHz support,
but we errorneously assumed the opposite.  If the flag was set, we
were considering that 160 MHz was supported, but it's actually the
opposite.  Fix it by inverting the bits, i.e. NO_160 is 0x1 and 160
is 0x0.

Fixes: d6f2134a3831 ("iwlwifi: add mac/rf types and 160MHz to the device tables")
Signed-off-by: Luca Coelho &lt;luciano.coelho@intel.com&gt;
Signed-off-by: Kalle Valo &lt;kvalo@codeaurora.org&gt;
Link: https://lore.kernel.org/r/iwlwifi.20201202143859.375bec857ccb.I83884286b688965293e9810381808039bd7eedae@changeid
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The NO_160 flag specifies if the device doesn't have 160 MHz support,
but we errorneously assumed the opposite.  If the flag was set, we
were considering that 160 MHz was supported, but it's actually the
opposite.  Fix it by inverting the bits, i.e. NO_160 is 0x1 and 160
is 0x0.

Fixes: d6f2134a3831 ("iwlwifi: add mac/rf types and 160MHz to the device tables")
Signed-off-by: Luca Coelho &lt;luciano.coelho@intel.com&gt;
Signed-off-by: Kalle Valo &lt;kvalo@codeaurora.org&gt;
Link: https://lore.kernel.org/r/iwlwifi.20201202143859.375bec857ccb.I83884286b688965293e9810381808039bd7eedae@changeid
</pre>
</div>
</content>
</entry>
<entry>
<title>iwlwifi: pcie: add one missing entry for AX210</title>
<updated>2020-12-02T19:01:32+00:00</updated>
<author>
<name>Luca Coelho</name>
<email>luciano.coelho@intel.com</email>
</author>
<published>2020-12-02T12:41:49+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=5febcdef30902fa870128b9789b873199f13aff1'/>
<id>5febcdef30902fa870128b9789b873199f13aff1</id>
<content type='text'>
The 0x0024 subsytem device ID was missing from the list, so some AX210
devices were not recognized.  Add it.

Signed-off-by: Luca Coelho &lt;luciano.coelho@intel.com&gt;
Signed-off-by: Kalle Valo &lt;kvalo@codeaurora.org&gt;
Link: https://lore.kernel.org/r/iwlwifi.20201202143859.308eab4db42c.I3763196cd3f7bb36f3dcabf02ec4e7c4fe859c0f@changeid
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The 0x0024 subsytem device ID was missing from the list, so some AX210
devices were not recognized.  Add it.

Signed-off-by: Luca Coelho &lt;luciano.coelho@intel.com&gt;
Signed-off-by: Kalle Valo &lt;kvalo@codeaurora.org&gt;
Link: https://lore.kernel.org/r/iwlwifi.20201202143859.308eab4db42c.I3763196cd3f7bb36f3dcabf02ec4e7c4fe859c0f@changeid
</pre>
</div>
</content>
</entry>
<entry>
<title>iwlwifi: mvm: fix kernel panic in case of assert during CSA</title>
<updated>2020-11-10T18:45:36+00:00</updated>
<author>
<name>Sara Sharon</name>
<email>sara.sharon@intel.com</email>
</author>
<published>2020-11-07T08:50:11+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=fe56d05ee6c87f6a1a8c7267affd92c9438249cc'/>
<id>fe56d05ee6c87f6a1a8c7267affd92c9438249cc</id>
<content type='text'>
During CSA, we briefly nullify the phy context, in __iwl_mvm_unassign_vif_chanctx.
In case we have a FW assert right after it, it remains NULL though.
We end up running into endless loop due to mac80211 trying repeatedly to
move us to ASSOC state, and we keep returning -EINVAL. Later down the road
we hit a kernel panic.

Detect and avoid this endless loop.

Signed-off-by: Sara Sharon &lt;sara.sharon@intel.com&gt;
Signed-off-by: Luca Coelho &lt;luciano.coelho@intel.com&gt;
Signed-off-by: Kalle Valo &lt;kvalo@codeaurora.org&gt;
Link: https://lore.kernel.org/r/iwlwifi.20201107104557.d64de2c17bff.Iedd0d2afa20a2aacba5259a5cae31cb3a119a4eb@changeid
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
During CSA, we briefly nullify the phy context, in __iwl_mvm_unassign_vif_chanctx.
In case we have a FW assert right after it, it remains NULL though.
We end up running into endless loop due to mac80211 trying repeatedly to
move us to ASSOC state, and we keep returning -EINVAL. Later down the road
we hit a kernel panic.

Detect and avoid this endless loop.

Signed-off-by: Sara Sharon &lt;sara.sharon@intel.com&gt;
Signed-off-by: Luca Coelho &lt;luciano.coelho@intel.com&gt;
Signed-off-by: Kalle Valo &lt;kvalo@codeaurora.org&gt;
Link: https://lore.kernel.org/r/iwlwifi.20201107104557.d64de2c17bff.Iedd0d2afa20a2aacba5259a5cae31cb3a119a4eb@changeid
</pre>
</div>
</content>
</entry>
<entry>
<title>iwlwifi: pcie: set LTR to avoid completion timeout</title>
<updated>2020-11-10T18:45:35+00:00</updated>
<author>
<name>Johannes Berg</name>
<email>johannes.berg@intel.com</email>
</author>
<published>2020-11-07T08:50:10+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=edb625208d84aef179e3f16590c1c582fc5fdae6'/>
<id>edb625208d84aef179e3f16590c1c582fc5fdae6</id>
<content type='text'>
On some platforms, the preset values aren't correct and then we may
get a completion timeout in the firmware. Change the LTR configuration
to avoid that. The firmware will do some more complex reinit of this
later, but for the boot process we use ~250usec.

Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
Signed-off-by: Luca Coelho &lt;luciano.coelho@intel.com&gt;
Signed-off-by: Kalle Valo &lt;kvalo@codeaurora.org&gt;
Link: https://lore.kernel.org/r/iwlwifi.20201107104557.d83d591c05ba.I42885c9fb500bc08b9a4c07c4ff3d436cc7a3c84@changeid
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
On some platforms, the preset values aren't correct and then we may
get a completion timeout in the firmware. Change the LTR configuration
to avoid that. The firmware will do some more complex reinit of this
later, but for the boot process we use ~250usec.

Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
Signed-off-by: Luca Coelho &lt;luciano.coelho@intel.com&gt;
Signed-off-by: Kalle Valo &lt;kvalo@codeaurora.org&gt;
Link: https://lore.kernel.org/r/iwlwifi.20201107104557.d83d591c05ba.I42885c9fb500bc08b9a4c07c4ff3d436cc7a3c84@changeid
</pre>
</div>
</content>
</entry>
<entry>
<title>iwlwifi: mvm: write queue_sync_state only for sync</title>
<updated>2020-11-10T18:45:34+00:00</updated>
<author>
<name>Avraham Stern</name>
<email>avraham.stern@intel.com</email>
</author>
<published>2020-11-07T08:50:09+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=97cc16943f23078535fdbce4f6391b948b4ccc08'/>
<id>97cc16943f23078535fdbce4f6391b948b4ccc08</id>
<content type='text'>
We use mvm-&gt;queue_sync_state to wait for synchronous queue sync
messages, but if an async one happens inbetween we shouldn't
clear mvm-&gt;queue_sync_state after sending the async one, that
can run concurrently (at least from the CPU POV) with another
synchronous queue sync.

Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
Fixes: 3c514bf831ac ("iwlwifi: mvm: add a loose synchronization of the NSSN across Rx queues")
Signed-off-by: Luca Coelho &lt;luciano.coelho@intel.com&gt;
Signed-off-by: Kalle Valo &lt;kvalo@codeaurora.org&gt;
Link: https://lore.kernel.org/r/iwlwifi.20201107104557.51a3148f2c14.I0772171dbaec87433a11513e9586d98b5d920b5f@changeid
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
We use mvm-&gt;queue_sync_state to wait for synchronous queue sync
messages, but if an async one happens inbetween we shouldn't
clear mvm-&gt;queue_sync_state after sending the async one, that
can run concurrently (at least from the CPU POV) with another
synchronous queue sync.

Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
Fixes: 3c514bf831ac ("iwlwifi: mvm: add a loose synchronization of the NSSN across Rx queues")
Signed-off-by: Luca Coelho &lt;luciano.coelho@intel.com&gt;
Signed-off-by: Kalle Valo &lt;kvalo@codeaurora.org&gt;
Link: https://lore.kernel.org/r/iwlwifi.20201107104557.51a3148f2c14.I0772171dbaec87433a11513e9586d98b5d920b5f@changeid
</pre>
</div>
</content>
</entry>
<entry>
<title>iwlwifi: mvm: properly cancel a session protection for P2P</title>
<updated>2020-11-10T18:45:32+00:00</updated>
<author>
<name>Emmanuel Grumbach</name>
<email>emmanuel.grumbach@intel.com</email>
</author>
<published>2020-11-07T08:50:08+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=1cf260e3a75b87726ec609ad1b6b88f515749786'/>
<id>1cf260e3a75b87726ec609ad1b6b88f515749786</id>
<content type='text'>
We need to feed the configuration id to remove  session protection
properly.
Remember the conf_id when we add the session protection so that we
can give it back when we want to remove the session protection.
While at it, slightly improve the kernel doc for the conf_id
of the notification.

Signed-off-by: Emmanuel Grumbach &lt;emmanuel.grumbach@intel.com&gt;
Fixes: fe959c7b2049 ("iwlwifi: mvm: use the new session protection command")
Signed-off-by: Luca Coelho &lt;luciano.coelho@intel.com&gt;
Signed-off-by: Kalle Valo &lt;kvalo@codeaurora.org&gt;
Link: https://lore.kernel.org/r/iwlwifi.20201107104557.3642f730333d.I01a98ecde62096d00d171cf34ad775bf80cb0277@changeid
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
We need to feed the configuration id to remove  session protection
properly.
Remember the conf_id when we add the session protection so that we
can give it back when we want to remove the session protection.
While at it, slightly improve the kernel doc for the conf_id
of the notification.

Signed-off-by: Emmanuel Grumbach &lt;emmanuel.grumbach@intel.com&gt;
Fixes: fe959c7b2049 ("iwlwifi: mvm: use the new session protection command")
Signed-off-by: Luca Coelho &lt;luciano.coelho@intel.com&gt;
Signed-off-by: Kalle Valo &lt;kvalo@codeaurora.org&gt;
Link: https://lore.kernel.org/r/iwlwifi.20201107104557.3642f730333d.I01a98ecde62096d00d171cf34ad775bf80cb0277@changeid
</pre>
</div>
</content>
</entry>
<entry>
<title>iwlwifi: mvm: use the HOT_SPOT_CMD to cancel an AUX ROC</title>
<updated>2020-11-10T18:45:31+00:00</updated>
<author>
<name>Emmanuel Grumbach</name>
<email>emmanuel.grumbach@intel.com</email>
</author>
<published>2020-11-07T08:50:07+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=fb8d1b6e97980057b7ebed444b8950e57f268a67'/>
<id>fb8d1b6e97980057b7ebed444b8950e57f268a67</id>
<content type='text'>
The ROC that runs on the AUX ROC (meaning an ROC on the STA vif),
was added with the HOT_SPOT_CMD firmware command and must be
cancelled with that same command.

Signed-off-by: Emmanuel Grumbach &lt;emmanuel.grumbach@intel.com&gt;
Fixes: fe959c7b2049 ("iwlwifi: mvm: use the new session protection command")
Signed-off-by: Luca Coelho &lt;luciano.coelho@intel.com&gt;
Signed-off-by: Kalle Valo &lt;kvalo@codeaurora.org&gt;
Link: https://lore.kernel.org/r/iwlwifi.20201107104557.a317376154da.I44fa3637373ba4bd421cdff2cabc761bffc0735f@changeid
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The ROC that runs on the AUX ROC (meaning an ROC on the STA vif),
was added with the HOT_SPOT_CMD firmware command and must be
cancelled with that same command.

Signed-off-by: Emmanuel Grumbach &lt;emmanuel.grumbach@intel.com&gt;
Fixes: fe959c7b2049 ("iwlwifi: mvm: use the new session protection command")
Signed-off-by: Luca Coelho &lt;luciano.coelho@intel.com&gt;
Signed-off-by: Kalle Valo &lt;kvalo@codeaurora.org&gt;
Link: https://lore.kernel.org/r/iwlwifi.20201107104557.a317376154da.I44fa3637373ba4bd421cdff2cabc761bffc0735f@changeid
</pre>
</div>
</content>
</entry>
</feed>
