<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-stable.git/net/wireless, branch v6.7.6</title>
<subtitle>Linux kernel stable tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/'/>
<entry>
<title>wifi: cfg80211: fix wiphy delayed work queueing</title>
<updated>2024-02-23T08:51:51+00:00</updated>
<author>
<name>Johannes Berg</name>
<email>johannes.berg@intel.com</email>
</author>
<published>2024-01-25T08:51:09+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=f1ff55b436e236c4919f158e1bb69f2db0b9af29'/>
<id>f1ff55b436e236c4919f158e1bb69f2db0b9af29</id>
<content type='text'>
commit b743287d7a0007493f5cada34ed2085d475050b4 upstream.

When a wiphy work is queued with timer, and then again
without a delay, it's started immediately but *also*
started again after the timer expires. This can lead,
for example, to warnings in mac80211's offchannel code
as reported by Jouni. Running the same work twice isn't
expected, of course. Fix this by deleting the timer at
this point, when queuing immediately due to delay=0.

Cc: stable@vger.kernel.org
Reported-by: Jouni Malinen &lt;j@w1.fi&gt;
Fixes: a3ee4dc84c4e ("wifi: cfg80211: add a work abstraction with special semantics")
Link: https://msgid.link/20240125095108.2feb0eaaa446.I4617f3210ed0e7f252290d5970dac6a876aa595b@changeid
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit b743287d7a0007493f5cada34ed2085d475050b4 upstream.

When a wiphy work is queued with timer, and then again
without a delay, it's started immediately but *also*
started again after the timer expires. This can lead,
for example, to warnings in mac80211's offchannel code
as reported by Jouni. Running the same work twice isn't
expected, of course. Fix this by deleting the timer at
this point, when queuing immediately due to delay=0.

Cc: stable@vger.kernel.org
Reported-by: Jouni Malinen &lt;j@w1.fi&gt;
Fixes: a3ee4dc84c4e ("wifi: cfg80211: add a work abstraction with special semantics")
Link: https://msgid.link/20240125095108.2feb0eaaa446.I4617f3210ed0e7f252290d5970dac6a876aa595b@changeid
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>wifi: cfg80211: detect stuck ECSA element in probe resp</title>
<updated>2024-02-16T18:14:19+00:00</updated>
<author>
<name>Johannes Berg</name>
<email>johannes.berg@intel.com</email>
</author>
<published>2024-01-29T12:14:13+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=ce112c941c2b172afba3e913a90c380647d53975'/>
<id>ce112c941c2b172afba3e913a90c380647d53975</id>
<content type='text'>
[ Upstream commit 177fbbcb4ed6b306c1626a277fac3fb1c495a4c7 ]

We recently added some validation that we don't try to
connect to an AP that is currently in a channel switch
process, since that might want the channel to be quiet
or we might not be able to connect in time to hear the
switching in a beacon. This was in commit c09c4f31998b
("wifi: mac80211: don't connect to an AP while it's in
a CSA process").

However, we promptly got a report that this caused new
connection failures, and it turns out that the AP that
we now cannot connect to is permanently advertising an
extended channel switch announcement, even with quiet.
The AP in question was an Asus RT-AC53, with firmware
3.0.0.4.380_10760-g21a5898.

As a first step, attempt to detect that we're dealing
with such a situation, so mac80211 can use this later.

Reported-by: coldolt &lt;andypalmadi@gmail.com&gt;
Closes: https://lore.kernel.org/linux-wireless/CAJvGw+DQhBk_mHXeu6RTOds5iramMW2FbMB01VbKRA4YbHHDTA@mail.gmail.com/
Fixes: c09c4f31998b ("wifi: mac80211: don't connect to an AP while it's in a CSA process")
Reviewed-by: Miriam Rachel Korenblit &lt;miriam.rachel.korenblit@intel.com&gt;
Link: https://msgid.link/20240129131413.246972c8775e.Ibf834d7f52f9951a353b6872383da710a7358338@changeid
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit 177fbbcb4ed6b306c1626a277fac3fb1c495a4c7 ]

We recently added some validation that we don't try to
connect to an AP that is currently in a channel switch
process, since that might want the channel to be quiet
or we might not be able to connect in time to hear the
switching in a beacon. This was in commit c09c4f31998b
("wifi: mac80211: don't connect to an AP while it's in
a CSA process").

However, we promptly got a report that this caused new
connection failures, and it turns out that the AP that
we now cannot connect to is permanently advertising an
extended channel switch announcement, even with quiet.
The AP in question was an Asus RT-AC53, with firmware
3.0.0.4.380_10760-g21a5898.

As a first step, attempt to detect that we're dealing
with such a situation, so mac80211 can use this later.

Reported-by: coldolt &lt;andypalmadi@gmail.com&gt;
Closes: https://lore.kernel.org/linux-wireless/CAJvGw+DQhBk_mHXeu6RTOds5iramMW2FbMB01VbKRA4YbHHDTA@mail.gmail.com/
Fixes: c09c4f31998b ("wifi: mac80211: don't connect to an AP while it's in a CSA process")
Reviewed-by: Miriam Rachel Korenblit &lt;miriam.rachel.korenblit@intel.com&gt;
Link: https://msgid.link/20240129131413.246972c8775e.Ibf834d7f52f9951a353b6872383da710a7358338@changeid
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>wifi: cfg80211: consume both probe response and beacon IEs</title>
<updated>2024-02-16T18:14:19+00:00</updated>
<author>
<name>Benjamin Berg</name>
<email>benjamin.berg@intel.com</email>
</author>
<published>2023-12-11T07:05:28+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=7af9b4dc0bee19cf3559c24e753bb85c038118c8'/>
<id>7af9b4dc0bee19cf3559c24e753bb85c038118c8</id>
<content type='text'>
[ Upstream commit f510bcc21ed97911b811c5bf36ed43a0e94ab702 ]

When doing a channel switch, cfg80211_update_known_bss may be called
with a BSS where both proberesp_ies and beacon_ies is set. If that
happens, both need to be consumed.

Signed-off-by: Benjamin Berg &lt;benjamin.berg@intel.com&gt;
Signed-off-by: Miri Korenblit &lt;miriam.rachel.korenblit@intel.com&gt;
Link: https://msgid.link/20231211085121.07a88656d7df.I0fe9fc599382de0eccf96455617e377d9c231966@changeid
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
Stable-dep-of: 177fbbcb4ed6 ("wifi: cfg80211: detect stuck ECSA element in probe resp")
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit f510bcc21ed97911b811c5bf36ed43a0e94ab702 ]

When doing a channel switch, cfg80211_update_known_bss may be called
with a BSS where both proberesp_ies and beacon_ies is set. If that
happens, both need to be consumed.

Signed-off-by: Benjamin Berg &lt;benjamin.berg@intel.com&gt;
Signed-off-by: Miri Korenblit &lt;miriam.rachel.korenblit@intel.com&gt;
Link: https://msgid.link/20231211085121.07a88656d7df.I0fe9fc599382de0eccf96455617e377d9c231966@changeid
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
Stable-dep-of: 177fbbcb4ed6 ("wifi: cfg80211: detect stuck ECSA element in probe resp")
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>wifi: cfg80211: fix RCU dereference in __cfg80211_bss_update</title>
<updated>2024-02-05T20:17:06+00:00</updated>
<author>
<name>Edward Adam Davis</name>
<email>eadavis@qq.com</email>
</author>
<published>2024-01-03T12:13:51+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=171cd66ffd0a05082cb08e09f7037866c960179b'/>
<id>171cd66ffd0a05082cb08e09f7037866c960179b</id>
<content type='text'>
[ Upstream commit 1184950e341c11b6f82bc5b59564411d9537ab27 ]

Replace rcu_dereference() with rcu_access_pointer() since we hold
the lock here (and aren't in an RCU critical section).

Fixes: 32af9a9e1069 ("wifi: cfg80211: free beacon_ies when overridden from hidden BSS")
Reported-and-tested-by: syzbot+864a269c27ee06b58374@syzkaller.appspotmail.com
Signed-off-by: Edward Adam Davis &lt;eadavis@qq.com&gt;
Link: https://msgid.link/tencent_BF8F0DF0258C8DBF124CDDE4DD8D992DCF07@qq.com
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit 1184950e341c11b6f82bc5b59564411d9537ab27 ]

Replace rcu_dereference() with rcu_access_pointer() since we hold
the lock here (and aren't in an RCU critical section).

Fixes: 32af9a9e1069 ("wifi: cfg80211: free beacon_ies when overridden from hidden BSS")
Reported-and-tested-by: syzbot+864a269c27ee06b58374@syzkaller.appspotmail.com
Signed-off-by: Edward Adam Davis &lt;eadavis@qq.com&gt;
Link: https://msgid.link/tencent_BF8F0DF0258C8DBF124CDDE4DD8D992DCF07@qq.com
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>wifi: cfg80211: free beacon_ies when overridden from hidden BSS</title>
<updated>2024-02-05T20:16:55+00:00</updated>
<author>
<name>Benjamin Berg</name>
<email>benjamin.berg@intel.com</email>
</author>
<published>2023-12-20T11:41:41+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=357c371dfd06f0fda3c690de84ed4bceff43e1f7'/>
<id>357c371dfd06f0fda3c690de84ed4bceff43e1f7</id>
<content type='text'>
[ Upstream commit 32af9a9e1069e55bc02741fb00ac9d0ca1a2eaef ]

This is a more of a cosmetic fix. The branch will only be taken if
proberesp_ies is set, which implies that beacon_ies is not set unless we
are connected to an AP that just did a channel switch. And, in that case
we should have found the BSS in the internal storage to begin with.

Signed-off-by: Benjamin Berg &lt;benjamin.berg@intel.com&gt;
Reviewed-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
Signed-off-by: Miri Korenblit &lt;miriam.rachel.korenblit@intel.com&gt;
Link: https://msgid.link/20231220133549.b898e22dadff.Id8c4c10aedd176ef2e18a4cad747b299f150f9df@changeid
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit 32af9a9e1069e55bc02741fb00ac9d0ca1a2eaef ]

This is a more of a cosmetic fix. The branch will only be taken if
proberesp_ies is set, which implies that beacon_ies is not set unless we
are connected to an AP that just did a channel switch. And, in that case
we should have found the BSS in the internal storage to begin with.

Signed-off-by: Benjamin Berg &lt;benjamin.berg@intel.com&gt;
Reviewed-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
Signed-off-by: Miri Korenblit &lt;miriam.rachel.korenblit@intel.com&gt;
Link: https://msgid.link/20231220133549.b898e22dadff.Id8c4c10aedd176ef2e18a4cad747b299f150f9df@changeid
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>wifi: cfg80211: parse all ML elements in an ML probe response</title>
<updated>2024-01-25T23:44:56+00:00</updated>
<author>
<name>Benjamin Berg</name>
<email>benjamin.berg@intel.com</email>
</author>
<published>2024-01-02T19:35:31+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=d4924d21f6bc4f50ad1b8ffee9b73886244eb981'/>
<id>d4924d21f6bc4f50ad1b8ffee9b73886244eb981</id>
<content type='text'>
[ Upstream commit d18125b640309e925441ce49559be33867ae6b29 ]

A probe response from a transmitting AP in an Multi-BSSID setup will
contain more than one Multi-Link element. Most likely, only one of these
elements contains per-STA profiles.

Fixes: 2481b5da9c6b ("wifi: cfg80211: handle BSS data contained in ML probe responses")
Signed-off-by: Benjamin Berg &lt;benjamin.berg@intel.com&gt;
Signed-off-by: Miri Korenblit &lt;miriam.rachel.korenblit@intel.com&gt;
Link: https://msgid.link/20240102213313.6635eb152735.I94289002d4a2f7b6b44dfa428344854e37b0b29c@changeid
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit d18125b640309e925441ce49559be33867ae6b29 ]

A probe response from a transmitting AP in an Multi-BSSID setup will
contain more than one Multi-Link element. Most likely, only one of these
elements contains per-STA profiles.

Fixes: 2481b5da9c6b ("wifi: cfg80211: handle BSS data contained in ML probe responses")
Signed-off-by: Benjamin Berg &lt;benjamin.berg@intel.com&gt;
Signed-off-by: Miri Korenblit &lt;miriam.rachel.korenblit@intel.com&gt;
Link: https://msgid.link/20240102213313.6635eb152735.I94289002d4a2f7b6b44dfa428344854e37b0b29c@changeid
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>wifi: cfg80211: correct comment about MLD ID</title>
<updated>2024-01-25T23:44:56+00:00</updated>
<author>
<name>Benjamin Berg</name>
<email>benjamin.berg@intel.com</email>
</author>
<published>2024-01-02T19:35:30+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=38344519bee6b5d3c21b57683bc2c01f8802c358'/>
<id>38344519bee6b5d3c21b57683bc2c01f8802c358</id>
<content type='text'>
[ Upstream commit 2a0698f86d4dfc43cc0c1703efb7ba6b1506a4e2 ]

The comment was referencing the wrong section of the documentation and
was also subtly wrong as it assumed the rules that apply when sending
probe requests directly to a nontransmitted AP. However, in that case
the response comes from the transmitting AP and the AP MLD ID will be
included.

Fixes: 2481b5da9c6b ("wifi: cfg80211: handle BSS data contained in ML probe responses")
Signed-off-by: Benjamin Berg &lt;benjamin.berg@intel.com&gt;
Signed-off-by: Miri Korenblit &lt;miriam.rachel.korenblit@intel.com&gt;
Link: https://msgid.link/20240102213313.0917ab4b5d7f.I76aff0e261a5de44ffb467e591a46597a30d7c0a@changeid
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit 2a0698f86d4dfc43cc0c1703efb7ba6b1506a4e2 ]

The comment was referencing the wrong section of the documentation and
was also subtly wrong as it assumed the rules that apply when sending
probe requests directly to a nontransmitted AP. However, in that case
the response comes from the transmitting AP and the AP MLD ID will be
included.

Fixes: 2481b5da9c6b ("wifi: cfg80211: handle BSS data contained in ML probe responses")
Signed-off-by: Benjamin Berg &lt;benjamin.berg@intel.com&gt;
Signed-off-by: Miri Korenblit &lt;miriam.rachel.korenblit@intel.com&gt;
Link: https://msgid.link/20240102213313.0917ab4b5d7f.I76aff0e261a5de44ffb467e591a46597a30d7c0a@changeid
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>wifi: cfg80211: fix certs build to not depend on file order</title>
<updated>2023-12-14T08:11:51+00:00</updated>
<author>
<name>Johannes Berg</name>
<email>johannes.berg@intel.com</email>
</author>
<published>2023-12-14T08:08:16+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=3c2a8ebe3fe66a5f77d4c164a0bea8e2ff37b455'/>
<id>3c2a8ebe3fe66a5f77d4c164a0bea8e2ff37b455</id>
<content type='text'>
The file for the new certificate (Chen-Yu Tsai's) didn't
end with a comma, so depending on the file order in the
build rule, we'd end up with invalid C when concatenating
the (now two) certificates. Fix that.

Cc: stable@vger.kernel.org
Reported-by: Biju Das &lt;biju.das.jz@bp.renesas.com&gt;
Reported-by: Naresh Kamboju &lt;naresh.kamboju@linaro.org&gt;
Fixes: fb768d3b13ff ("wifi: cfg80211: Add my certificate")
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The file for the new certificate (Chen-Yu Tsai's) didn't
end with a comma, so depending on the file order in the
build rule, we'd end up with invalid C when concatenating
the (now two) certificates. Fix that.

Cc: stable@vger.kernel.org
Reported-by: Biju Das &lt;biju.das.jz@bp.renesas.com&gt;
Reported-by: Naresh Kamboju &lt;naresh.kamboju@linaro.org&gt;
Fixes: fb768d3b13ff ("wifi: cfg80211: Add my certificate")
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>wifi: cfg80211: Add my certificate</title>
<updated>2023-12-12T09:14:57+00:00</updated>
<author>
<name>Chen-Yu Tsai</name>
<email>wens@kernel.org</email>
</author>
<published>2023-12-07T13:20:50+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=fb768d3b13ffa325b7e84480d488ac799c9d2cd7'/>
<id>fb768d3b13ffa325b7e84480d488ac799c9d2cd7</id>
<content type='text'>
As announced [1][2], I have taken over maintainership of the
wireless-regdb project.

Add my certificate so that newer releases are valid to the kernel.
Seth's certificate should be kept around for awhile, at least until
a few new releases by me happen.

This should also be applied to stable trees so that stable kernels
can utilize newly released database binaries.

[1] https://lore.kernel.org/linux-wireless/CAGb2v657baNMPKU3QADijx7hZa=GUcSv2LEDdn6N=QQaFX8r-g@mail.gmail.com/
[2] https://lore.kernel.org/linux-wireless/ZWmRR5ul7EDfxCan@wens.tw/

Cc: stable@vger.kernel.org
Signed-off-by: Chen-Yu Tsai &lt;wens@kernel.org&gt;
Acked-by: Seth Forshee &lt;sforshee@kernel.org&gt;
Link: https://msgid.link/ZXHGsqs34qZyzZng@wens.tw
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
As announced [1][2], I have taken over maintainership of the
wireless-regdb project.

Add my certificate so that newer releases are valid to the kernel.
Seth's certificate should be kept around for awhile, at least until
a few new releases by me happen.

This should also be applied to stable trees so that stable kernels
can utilize newly released database binaries.

[1] https://lore.kernel.org/linux-wireless/CAGb2v657baNMPKU3QADijx7hZa=GUcSv2LEDdn6N=QQaFX8r-g@mail.gmail.com/
[2] https://lore.kernel.org/linux-wireless/ZWmRR5ul7EDfxCan@wens.tw/

Cc: stable@vger.kernel.org
Signed-off-by: Chen-Yu Tsai &lt;wens@kernel.org&gt;
Acked-by: Seth Forshee &lt;sforshee@kernel.org&gt;
Link: https://msgid.link/ZXHGsqs34qZyzZng@wens.tw
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>wifi: cfg80211: add locked debugfs wrappers</title>
<updated>2023-11-27T10:24:58+00:00</updated>
<author>
<name>Johannes Berg</name>
<email>johannes.berg@intel.com</email>
</author>
<published>2023-11-24T16:25:27+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=b590b9ae1efc30e52f81d95cdb2519a4c248b965'/>
<id>b590b9ae1efc30e52f81d95cdb2519a4c248b965</id>
<content type='text'>
Add wrappers for debugfs files that should be called with
the wiphy mutex held, while the file is also to be removed
under the wiphy mutex. This could otherwise deadlock when
a file is trying to acquire the wiphy mutex while the code
removing it holds the mutex but waits for the removal.

This actually works by pushing the execution of the read
or write handler to a wiphy work that can be cancelled
using the debugfs cancellation API.

Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Add wrappers for debugfs files that should be called with
the wiphy mutex held, while the file is also to be removed
under the wiphy mutex. This could otherwise deadlock when
a file is trying to acquire the wiphy mutex while the code
removing it holds the mutex but waits for the removal.

This actually works by pushing the execution of the read
or write handler to a wiphy work that can be cancelled
using the debugfs cancellation API.

Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
</pre>
</div>
</content>
</entry>
</feed>
