<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-stable.git/drivers/net/wireless, branch v6.2.3</title>
<subtitle>Linux kernel stable tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/'/>
<entry>
<title>wifi: ath11k: allow system suspend to survive ath11k</title>
<updated>2023-03-10T08:29:43+00:00</updated>
<author>
<name>Len Brown</name>
<email>len.brown@intel.com</email>
</author>
<published>2023-02-01T18:32:01+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=2388cfc52822d23f9704a56f57b7ed45aa9c9051'/>
<id>2388cfc52822d23f9704a56f57b7ed45aa9c9051</id>
<content type='text'>
commit 7c15430822e71e90203d87e6d0cfe83fa058b0dc upstream.

When ath11k runs into internal errors upon suspend,
it returns an error code to pci_pm_suspend, which
aborts the entire system suspend.

The driver should not abort system suspend, but should
keep its internal errors to itself, and allow the system
to suspend.  Otherwise, a user can suspend a laptop
by closing the lid and sealing it into a case, assuming
that is will suspend, rather than heating up and draining
the battery when in transit.

In practice, the ath11k device seems to have plenty of transient
errors, and subsequent suspend cycles after this failure
often succeed.

https://bugzilla.kernel.org/show_bug.cgi?id=216968

Fixes: d1b0c33850d29 ("ath11k: implement suspend for QCA6390 PCI devices")

Signed-off-by: Len Brown &lt;len.brown@intel.com&gt;
Cc: stable@vger.kernel.org
Signed-off-by: Kalle Valo &lt;kvalo@kernel.org&gt;
Link: https://lore.kernel.org/r/20230201183201.14431-1-len.brown@intel.com
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 7c15430822e71e90203d87e6d0cfe83fa058b0dc upstream.

When ath11k runs into internal errors upon suspend,
it returns an error code to pci_pm_suspend, which
aborts the entire system suspend.

The driver should not abort system suspend, but should
keep its internal errors to itself, and allow the system
to suspend.  Otherwise, a user can suspend a laptop
by closing the lid and sealing it into a case, assuming
that is will suspend, rather than heating up and draining
the battery when in transit.

In practice, the ath11k device seems to have plenty of transient
errors, and subsequent suspend cycles after this failure
often succeed.

https://bugzilla.kernel.org/show_bug.cgi?id=216968

Fixes: d1b0c33850d29 ("ath11k: implement suspend for QCA6390 PCI devices")

Signed-off-by: Len Brown &lt;len.brown@intel.com&gt;
Cc: stable@vger.kernel.org
Signed-off-by: Kalle Valo &lt;kvalo@kernel.org&gt;
Link: https://lore.kernel.org/r/20230201183201.14431-1-len.brown@intel.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>wifi: rtl8xxxu: Use a longer retry limit of 48</title>
<updated>2023-03-10T08:29:43+00:00</updated>
<author>
<name>Bitterblue Smith</name>
<email>rtl8821cerfe2@gmail.com</email>
</author>
<published>2023-01-08T15:08:16+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=5368db4d7e0b65caf08929e5332d19d70186508a'/>
<id>5368db4d7e0b65caf08929e5332d19d70186508a</id>
<content type='text'>
commit 2a86aa9a1892d60ef2e3f310f5b42b8b05546d65 upstream.

The Realtek rate control algorithm goes back and forth a lot between
the highest and the lowest rate it's allowed to use. This is due to
a lot of frames being dropped because the retry limits set by
IEEE80211_CONF_CHANGE_RETRY_LIMITS are too low. (Experimentally, they
are 4 for long frames and 7 for short frames.)

The vendor drivers hardcode the value 48 for both retry limits (for
station mode), which makes dropped frames very rare and thus the rate
control is more stable.

Because most Realtek chips handle the rate control in the firmware,
which can't be modified, ignore the limits set by
IEEE80211_CONF_CHANGE_RETRY_LIMITS and use the value 48 (set during
chip initialisation), same as the vendor drivers.

Cc: stable@vger.kernel.org
Signed-off-by: Bitterblue Smith &lt;rtl8821cerfe2@gmail.com&gt;
Reviewed-by: Ping-Ke Shih &lt;pkshih@realtek.com&gt;
Signed-off-by: Kalle Valo &lt;kvalo@kernel.org&gt;
Link: https://lore.kernel.org/r/477d745b-6bac-111d-403c-487fc19aa30d@gmail.com
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 2a86aa9a1892d60ef2e3f310f5b42b8b05546d65 upstream.

The Realtek rate control algorithm goes back and forth a lot between
the highest and the lowest rate it's allowed to use. This is due to
a lot of frames being dropped because the retry limits set by
IEEE80211_CONF_CHANGE_RETRY_LIMITS are too low. (Experimentally, they
are 4 for long frames and 7 for short frames.)

The vendor drivers hardcode the value 48 for both retry limits (for
station mode), which makes dropped frames very rare and thus the rate
control is more stable.

Because most Realtek chips handle the rate control in the firmware,
which can't be modified, ignore the limits set by
IEEE80211_CONF_CHANGE_RETRY_LIMITS and use the value 48 (set during
chip initialisation), same as the vendor drivers.

Cc: stable@vger.kernel.org
Signed-off-by: Bitterblue Smith &lt;rtl8821cerfe2@gmail.com&gt;
Reviewed-by: Ping-Ke Shih &lt;pkshih@realtek.com&gt;
Signed-off-by: Kalle Valo &lt;kvalo@kernel.org&gt;
Link: https://lore.kernel.org/r/477d745b-6bac-111d-403c-487fc19aa30d@gmail.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>wifi: rtw88: use RTW_FLAG_POWERON flag to prevent to power on/off twice</title>
<updated>2023-03-10T08:29:43+00:00</updated>
<author>
<name>Ping-Ke Shih</name>
<email>pkshih@realtek.com</email>
</author>
<published>2023-02-16T05:36:33+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=976fe246a57db503d2a0841c8cb813f2f66b78af'/>
<id>976fe246a57db503d2a0841c8cb813f2f66b78af</id>
<content type='text'>
commit 4a267bc5ea8f159b614d0549030216d0434eccca upstream.

Use power state to decide whether we can enter or leave IPS accurately,
and then prevent to power on/off twice.

The commit 6bf3a083407b ("wifi: rtw88: add flag check before enter or leave IPS")
would like to prevent this as well, but it still can't entirely handle all
cases. The exception is that WiFi gets connected and does suspend/resume,
it will power on twice and cause it failed to power on after resuming,
like:

  rtw_8723de 0000:03:00.0: failed to poll offset=0x6 mask=0x2 value=0x2
  rtw_8723de 0000:03:00.0: mac power on failed
  rtw_8723de 0000:03:00.0: failed to power on mac
  rtw_8723de 0000:03:00.0: leave idle state failed
  rtw_8723de 0000:03:00.0: failed to leave ips state
  rtw_8723de 0000:03:00.0: failed to leave idle state
  rtw_8723de 0000:03:00.0: failed to send h2c command

To fix this, introduce new flag RTW_FLAG_POWERON to reflect power state,
and call rtw_mac_pre_system_cfg() to configure registers properly between
power-off/-on.

Reported-by: Paul Gover &lt;pmw.gover@yahoo.co.uk&gt;
Link: https://bugzilla.kernel.org/show_bug.cgi?id=217016
Fixes: 6bf3a083407b ("wifi: rtw88: add flag check before enter or leave IPS")
Cc: &lt;Stable@vger.kernel.org&gt;
Signed-off-by: Ping-Ke Shih &lt;pkshih@realtek.com&gt;
Signed-off-by: Kalle Valo &lt;kvalo@kernel.org&gt;
Link: https://lore.kernel.org/r/20230216053633.20366-1-pkshih@realtek.com
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 4a267bc5ea8f159b614d0549030216d0434eccca upstream.

Use power state to decide whether we can enter or leave IPS accurately,
and then prevent to power on/off twice.

The commit 6bf3a083407b ("wifi: rtw88: add flag check before enter or leave IPS")
would like to prevent this as well, but it still can't entirely handle all
cases. The exception is that WiFi gets connected and does suspend/resume,
it will power on twice and cause it failed to power on after resuming,
like:

  rtw_8723de 0000:03:00.0: failed to poll offset=0x6 mask=0x2 value=0x2
  rtw_8723de 0000:03:00.0: mac power on failed
  rtw_8723de 0000:03:00.0: failed to power on mac
  rtw_8723de 0000:03:00.0: leave idle state failed
  rtw_8723de 0000:03:00.0: failed to leave ips state
  rtw_8723de 0000:03:00.0: failed to leave idle state
  rtw_8723de 0000:03:00.0: failed to send h2c command

To fix this, introduce new flag RTW_FLAG_POWERON to reflect power state,
and call rtw_mac_pre_system_cfg() to configure registers properly between
power-off/-on.

Reported-by: Paul Gover &lt;pmw.gover@yahoo.co.uk&gt;
Link: https://bugzilla.kernel.org/show_bug.cgi?id=217016
Fixes: 6bf3a083407b ("wifi: rtw88: add flag check before enter or leave IPS")
Cc: &lt;Stable@vger.kernel.org&gt;
Signed-off-by: Ping-Ke Shih &lt;pkshih@realtek.com&gt;
Signed-off-by: Kalle Valo &lt;kvalo@kernel.org&gt;
Link: https://lore.kernel.org/r/20230216053633.20366-1-pkshih@realtek.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>wifi: rtl8xxxu: fixing transmisison failure for rtl8192eu</title>
<updated>2023-03-10T08:29:22+00:00</updated>
<author>
<name>Jun ASAKA</name>
<email>JunASAKA@zzy040330.moe</email>
</author>
<published>2022-12-17T03:06:59+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=411590b87f0e5d483f6571c0bcb477cfad855c51'/>
<id>411590b87f0e5d483f6571c0bcb477cfad855c51</id>
<content type='text'>
commit c6015bf3ff1ffb3caa27eb913797438a0fc634a0 upstream.

Fixing transmission failure which results in
"authentication with ... timed out". This can be
fixed by disable the REG_TXPAUSE.

Signed-off-by: Jun ASAKA &lt;JunASAKA@zzy040330.moe&gt;
Reviewed-by: Ping-Ke Shih &lt;pkshih@realtek.com&gt;
Signed-off-by: Kalle Valo &lt;kvalo@kernel.org&gt;
Link: https://lore.kernel.org/r/20221217030659.12577-1-JunASAKA@zzy040330.moe
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 c6015bf3ff1ffb3caa27eb913797438a0fc634a0 upstream.

Fixing transmission failure which results in
"authentication with ... timed out". This can be
fixed by disable the REG_TXPAUSE.

Signed-off-by: Jun ASAKA &lt;JunASAKA@zzy040330.moe&gt;
Reviewed-by: Ping-Ke Shih &lt;pkshih@realtek.com&gt;
Signed-off-by: Kalle Valo &lt;kvalo@kernel.org&gt;
Link: https://lore.kernel.org/r/20221217030659.12577-1-JunASAKA@zzy040330.moe
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>wifi: rtw89: debug: avoid invalid access on RTW89_DBG_SEL_MAC_30</title>
<updated>2023-03-10T08:29:13+00:00</updated>
<author>
<name>Zong-Zhe Yang</name>
<email>kevin_yang@realtek.com</email>
</author>
<published>2023-01-19T06:35:28+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=ee9732c0650d339c5e50a0106e6f34873b9e9a50'/>
<id>ee9732c0650d339c5e50a0106e6f34873b9e9a50</id>
<content type='text'>
[ Upstream commit c074da21dd346e0cfef5d08b0715078d7aea7f8d ]

Only 8852C chip has valid pages on RTW89_DBG_SEL_MAC_30. To other chips,
this section is an address hole. It will lead to crash if trying to access
this section on chips except for 8852C. So, we avoid that.

Signed-off-by: Zong-Zhe Yang &lt;kevin_yang@realtek.com&gt;
Signed-off-by: Ping-Ke Shih &lt;pkshih@realtek.com&gt;
Signed-off-by: Kalle Valo &lt;kvalo@kernel.org&gt;
Link: https://lore.kernel.org/r/20230119063529.61563-2-pkshih@realtek.com
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 c074da21dd346e0cfef5d08b0715078d7aea7f8d ]

Only 8852C chip has valid pages on RTW89_DBG_SEL_MAC_30. To other chips,
this section is an address hole. It will lead to crash if trying to access
this section on chips except for 8852C. So, we avoid that.

Signed-off-by: Zong-Zhe Yang &lt;kevin_yang@realtek.com&gt;
Signed-off-by: Ping-Ke Shih &lt;pkshih@realtek.com&gt;
Signed-off-by: Kalle Valo &lt;kvalo@kernel.org&gt;
Link: https://lore.kernel.org/r/20230119063529.61563-2-pkshih@realtek.com
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>wifi: mt76: dma: free rx_head in mt76_dma_rx_cleanup</title>
<updated>2023-03-10T08:29:11+00:00</updated>
<author>
<name>Lorenzo Bianconi</name>
<email>lorenzo@kernel.org</email>
</author>
<published>2023-01-01T11:47:57+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=44e8c429f81c126f0531f2000d8656e349962ff6'/>
<id>44e8c429f81c126f0531f2000d8656e349962ff6</id>
<content type='text'>
[ Upstream commit 1b88b47e898edef0e56e3a2f4e49f052a136153d ]

Free rx_head skb in mt76_dma_rx_cleanup routine in order to avoid
possible memory leak at module unload.

Signed-off-by: Lorenzo Bianconi &lt;lorenzo@kernel.org&gt;
Signed-off-by: Felix Fietkau &lt;nbd@nbd.name&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 1b88b47e898edef0e56e3a2f4e49f052a136153d ]

Free rx_head skb in mt76_dma_rx_cleanup routine in order to avoid
possible memory leak at module unload.

Signed-off-by: Lorenzo Bianconi &lt;lorenzo@kernel.org&gt;
Signed-off-by: Felix Fietkau &lt;nbd@nbd.name&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>wifi: mt7601u: fix an integer underflow</title>
<updated>2023-03-10T08:29:09+00:00</updated>
<author>
<name>Jisoo Jang</name>
<email>jisoo.jang@yonsei.ac.kr</email>
</author>
<published>2022-12-29T09:29:06+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=d0db59e2f718d1e2f1d2a2d8092168fdd2f3add0'/>
<id>d0db59e2f718d1e2f1d2a2d8092168fdd2f3add0</id>
<content type='text'>
[ Upstream commit 803f3176c5df3b5582c27ea690f204abb60b19b9 ]

Fix an integer underflow that leads to a null pointer dereference in
'mt7601u_rx_skb_from_seg()'. The variable 'dma_len' in the URB packet
could be manipulated, which could trigger an integer underflow of
'seg_len' in 'mt7601u_rx_process_seg()'. This underflow subsequently
causes the 'bad_frame' checks in 'mt7601u_rx_skb_from_seg()' to be
bypassed, eventually leading to a dereference of the pointer 'p', which
is a null pointer.

Ensure that 'dma_len' is greater than 'min_seg_len'.

Found by a modified version of syzkaller.

KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f]
CPU: 0 PID: 12 Comm: ksoftirqd/0 Tainted: G        W  O      5.14.0+
#139
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
rel-1.12.1-0-ga5cab58e9a3f-prebuilt.qemu.org 04/01/2014
RIP: 0010:skb_add_rx_frag+0x143/0x370
Code: e2 07 83 c2 03 38 ca 7c 08 84 c9 0f 85 86 01 00 00 4c 8d 7d 08 44
89 68 08 48 b8 00 00 00 00 00 fc ff df 4c 89 fa 48 c1 ea 03 &lt;80&gt; 3c 02
00 0f 85 cd 01 00 00 48 8b 45 08 a8 01 0f 85 3d 01 00 00
RSP: 0018:ffffc900000cfc90 EFLAGS: 00010202
RAX: dffffc0000000000 RBX: ffff888115520dc0 RCX: 0000000000000000
RDX: 0000000000000001 RSI: ffff8881118430c0 RDI: ffff8881118430f8
RBP: 0000000000000000 R08: 0000000000000e09 R09: 0000000000000010
R10: ffff888111843017 R11: ffffed1022308602 R12: 0000000000000000
R13: 0000000000000e09 R14: 0000000000000010 R15: 0000000000000008
FS:  0000000000000000(0000) GS:ffff88811a800000(0000)
knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 000000004035af40 CR3: 00000001157f2000 CR4: 0000000000750ef0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
PKRU: 55555554
Call Trace:
 mt7601u_rx_tasklet+0xc73/0x1270
 ? mt7601u_submit_rx_buf.isra.0+0x510/0x510
 ? tasklet_action_common.isra.0+0x79/0x2f0
 tasklet_action_common.isra.0+0x206/0x2f0
 __do_softirq+0x1b5/0x880
 ? tasklet_unlock+0x30/0x30
 run_ksoftirqd+0x26/0x50
 smpboot_thread_fn+0x34f/0x7d0
 ? smpboot_register_percpu_thread+0x370/0x370
 kthread+0x3a1/0x480
 ? set_kthread_struct+0x120/0x120
 ret_from_fork+0x1f/0x30
Modules linked in: 88XXau(O) 88x2bu(O)
---[ end trace 57f34f93b4da0f9b ]---
RIP: 0010:skb_add_rx_frag+0x143/0x370
Code: e2 07 83 c2 03 38 ca 7c 08 84 c9 0f 85 86 01 00 00 4c 8d 7d 08 44
89 68 08 48 b8 00 00 00 00 00 fc ff df 4c 89 fa 48 c1 ea 03 &lt;80&gt; 3c 02
00 0f 85 cd 01 00 00 48 8b 45 08 a8 01 0f 85 3d 01 00 00
RSP: 0018:ffffc900000cfc90 EFLAGS: 00010202
RAX: dffffc0000000000 RBX: ffff888115520dc0 RCX: 0000000000000000
RDX: 0000000000000001 RSI: ffff8881118430c0 RDI: ffff8881118430f8
RBP: 0000000000000000 R08: 0000000000000e09 R09: 0000000000000010
R10: ffff888111843017 R11: ffffed1022308602 R12: 0000000000000000
R13: 0000000000000e09 R14: 0000000000000010 R15: 0000000000000008
FS:  0000000000000000(0000) GS:ffff88811a800000(0000)
knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 000000004035af40 CR3: 00000001157f2000 CR4: 0000000000750ef0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
PKRU: 55555554

Signed-off-by: Jisoo Jang &lt;jisoo.jang@yonsei.ac.kr&gt;
Acked-by: Jakub Kicinski &lt;kuba@kernel.org&gt;
Signed-off-by: Kalle Valo &lt;kvalo@kernel.org&gt;
Link: https://lore.kernel.org/r/20221229092906.2328282-1-jisoo.jang@yonsei.ac.kr
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 803f3176c5df3b5582c27ea690f204abb60b19b9 ]

Fix an integer underflow that leads to a null pointer dereference in
'mt7601u_rx_skb_from_seg()'. The variable 'dma_len' in the URB packet
could be manipulated, which could trigger an integer underflow of
'seg_len' in 'mt7601u_rx_process_seg()'. This underflow subsequently
causes the 'bad_frame' checks in 'mt7601u_rx_skb_from_seg()' to be
bypassed, eventually leading to a dereference of the pointer 'p', which
is a null pointer.

Ensure that 'dma_len' is greater than 'min_seg_len'.

Found by a modified version of syzkaller.

KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f]
CPU: 0 PID: 12 Comm: ksoftirqd/0 Tainted: G        W  O      5.14.0+
#139
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
rel-1.12.1-0-ga5cab58e9a3f-prebuilt.qemu.org 04/01/2014
RIP: 0010:skb_add_rx_frag+0x143/0x370
Code: e2 07 83 c2 03 38 ca 7c 08 84 c9 0f 85 86 01 00 00 4c 8d 7d 08 44
89 68 08 48 b8 00 00 00 00 00 fc ff df 4c 89 fa 48 c1 ea 03 &lt;80&gt; 3c 02
00 0f 85 cd 01 00 00 48 8b 45 08 a8 01 0f 85 3d 01 00 00
RSP: 0018:ffffc900000cfc90 EFLAGS: 00010202
RAX: dffffc0000000000 RBX: ffff888115520dc0 RCX: 0000000000000000
RDX: 0000000000000001 RSI: ffff8881118430c0 RDI: ffff8881118430f8
RBP: 0000000000000000 R08: 0000000000000e09 R09: 0000000000000010
R10: ffff888111843017 R11: ffffed1022308602 R12: 0000000000000000
R13: 0000000000000e09 R14: 0000000000000010 R15: 0000000000000008
FS:  0000000000000000(0000) GS:ffff88811a800000(0000)
knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 000000004035af40 CR3: 00000001157f2000 CR4: 0000000000750ef0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
PKRU: 55555554
Call Trace:
 mt7601u_rx_tasklet+0xc73/0x1270
 ? mt7601u_submit_rx_buf.isra.0+0x510/0x510
 ? tasklet_action_common.isra.0+0x79/0x2f0
 tasklet_action_common.isra.0+0x206/0x2f0
 __do_softirq+0x1b5/0x880
 ? tasklet_unlock+0x30/0x30
 run_ksoftirqd+0x26/0x50
 smpboot_thread_fn+0x34f/0x7d0
 ? smpboot_register_percpu_thread+0x370/0x370
 kthread+0x3a1/0x480
 ? set_kthread_struct+0x120/0x120
 ret_from_fork+0x1f/0x30
Modules linked in: 88XXau(O) 88x2bu(O)
---[ end trace 57f34f93b4da0f9b ]---
RIP: 0010:skb_add_rx_frag+0x143/0x370
Code: e2 07 83 c2 03 38 ca 7c 08 84 c9 0f 85 86 01 00 00 4c 8d 7d 08 44
89 68 08 48 b8 00 00 00 00 00 fc ff df 4c 89 fa 48 c1 ea 03 &lt;80&gt; 3c 02
00 0f 85 cd 01 00 00 48 8b 45 08 a8 01 0f 85 3d 01 00 00
RSP: 0018:ffffc900000cfc90 EFLAGS: 00010202
RAX: dffffc0000000000 RBX: ffff888115520dc0 RCX: 0000000000000000
RDX: 0000000000000001 RSI: ffff8881118430c0 RDI: ffff8881118430f8
RBP: 0000000000000000 R08: 0000000000000e09 R09: 0000000000000010
R10: ffff888111843017 R11: ffffed1022308602 R12: 0000000000000000
R13: 0000000000000e09 R14: 0000000000000010 R15: 0000000000000008
FS:  0000000000000000(0000) GS:ffff88811a800000(0000)
knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 000000004035af40 CR3: 00000001157f2000 CR4: 0000000000750ef0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
PKRU: 55555554

Signed-off-by: Jisoo Jang &lt;jisoo.jang@yonsei.ac.kr&gt;
Acked-by: Jakub Kicinski &lt;kuba@kernel.org&gt;
Signed-off-by: Kalle Valo &lt;kvalo@kernel.org&gt;
Link: https://lore.kernel.org/r/20221229092906.2328282-1-jisoo.jang@yonsei.ac.kr
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>wifi: rtw89: fix assignation of TX BD RAM table</title>
<updated>2023-03-10T08:29:09+00:00</updated>
<author>
<name>Zong-Zhe Yang</name>
<email>kevin_yang@realtek.com</email>
</author>
<published>2023-01-13T09:06:31+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=81ccbdffc9b040175dee8b9a21c32bc50dc0e364'/>
<id>81ccbdffc9b040175dee8b9a21c32bc50dc0e364</id>
<content type='text'>
[ Upstream commit 7f495de6ae7d31f098970fb45a038c9f69b1bf75 ]

TX BD's RAM table describes how HW allocates usable buffer section
for each TX channel at fetch time. The total RAM size for TX BD is
chip-dependent. For 8852BE, it has only half size (32) for TX channels
of single band. Original table arrange total size (64) for dual band.
It will overflow on 8852BE circuit and cause section conflicts between
different TX channels.

So, we do the changes below.
* add another table for single band chip and export both kind of tables
* point to the expected one in rtw89_pci_info by chip

Signed-off-by: Zong-Zhe Yang &lt;kevin_yang@realtek.com&gt;
Signed-off-by: Ping-Ke Shih &lt;pkshih@realtek.com&gt;
Signed-off-by: Kalle Valo &lt;kvalo@kernel.org&gt;
Link: https://lore.kernel.org/r/20230113090632.60957-4-pkshih@realtek.com
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 7f495de6ae7d31f098970fb45a038c9f69b1bf75 ]

TX BD's RAM table describes how HW allocates usable buffer section
for each TX channel at fetch time. The total RAM size for TX BD is
chip-dependent. For 8852BE, it has only half size (32) for TX channels
of single band. Original table arrange total size (64) for dual band.
It will overflow on 8852BE circuit and cause section conflicts between
different TX channels.

So, we do the changes below.
* add another table for single band chip and export both kind of tables
* point to the expected one in rtw89_pci_info by chip

Signed-off-by: Zong-Zhe Yang &lt;kevin_yang@realtek.com&gt;
Signed-off-by: Ping-Ke Shih &lt;pkshih@realtek.com&gt;
Signed-off-by: Kalle Valo &lt;kvalo@kernel.org&gt;
Link: https://lore.kernel.org/r/20230113090632.60957-4-pkshih@realtek.com
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>wifi: brcmfmac: ensure CLM version is null-terminated to prevent stack-out-of-bounds</title>
<updated>2023-03-10T08:29:08+00:00</updated>
<author>
<name>Jisoo Jang</name>
<email>jisoo.jang@yonsei.ac.kr</email>
</author>
<published>2022-12-30T07:51:39+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=c02f733024d70105f22de8dd0a1252a0350cd516'/>
<id>c02f733024d70105f22de8dd0a1252a0350cd516</id>
<content type='text'>
[ Upstream commit 660145d708be52f946a82e5b633c020f58f996de ]

Fix a stack-out-of-bounds read in brcmfmac that occurs
when 'buf' that is not null-terminated is passed as an argument of
strreplace() in brcmf_c_preinit_dcmds(). This buffer is filled with
a CLM version string by memcpy() in brcmf_fil_iovar_data_get().
Ensure buf is null-terminated.

Found by a modified version of syzkaller.

[   33.004414][ T1896] brcmfmac: brcmf_c_process_clm_blob: no clm_blob available (err=-2), device may have limited channels available
[   33.013486][ T1896] brcmfmac: brcmf_c_preinit_dcmds: Firmware: BCM43236/3 wl0: Nov 30 2011 17:33:42 version 5.90.188.22
[   33.021554][ T1896] ==================================================================
[   33.022379][ T1896] BUG: KASAN: stack-out-of-bounds in strreplace+0xf2/0x110
[   33.023122][ T1896] Read of size 1 at addr ffffc90001d6efc8 by task kworker/0:2/1896
[   33.023852][ T1896]
[   33.024096][ T1896] CPU: 0 PID: 1896 Comm: kworker/0:2 Tainted: G           O      5.14.0+ #132
[   33.024927][ T1896] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.1-0-ga5cab58e9a3f-prebuilt.qemu.org 04/01/2014
[   33.026065][ T1896] Workqueue: usb_hub_wq hub_event
[   33.026581][ T1896] Call Trace:
[   33.026896][ T1896]  dump_stack_lvl+0x57/0x7d
[   33.027372][ T1896]  print_address_description.constprop.0.cold+0xf/0x334
[   33.028037][ T1896]  ? strreplace+0xf2/0x110
[   33.028403][ T1896]  ? strreplace+0xf2/0x110
[   33.028807][ T1896]  kasan_report.cold+0x83/0xdf
[   33.029283][ T1896]  ? strreplace+0xf2/0x110
[   33.029666][ T1896]  strreplace+0xf2/0x110
[   33.029966][ T1896]  brcmf_c_preinit_dcmds+0xab1/0xc40
[   33.030351][ T1896]  ? brcmf_c_set_joinpref_default+0x100/0x100
[   33.030787][ T1896]  ? rcu_read_lock_sched_held+0xa1/0xd0
[   33.031223][ T1896]  ? rcu_read_lock_bh_held+0xb0/0xb0
[   33.031661][ T1896]  ? lock_acquire+0x19d/0x4e0
[   33.032091][ T1896]  ? find_held_lock+0x2d/0x110
[   33.032605][ T1896]  ? brcmf_usb_deq+0x1a7/0x260
[   33.033087][ T1896]  ? brcmf_usb_rx_fill_all+0x5a/0xf0
[   33.033582][ T1896]  brcmf_attach+0x246/0xd40
[   33.034022][ T1896]  ? wiphy_new_nm+0x1476/0x1d50
[   33.034383][ T1896]  ? kmemdup+0x30/0x40
[   33.034722][ T1896]  brcmf_usb_probe+0x12de/0x1690
[   33.035223][ T1896]  ? brcmf_usbdev_qinit.constprop.0+0x470/0x470
[   33.035833][ T1896]  usb_probe_interface+0x25f/0x710
[   33.036315][ T1896]  really_probe+0x1be/0xa90
[   33.036656][ T1896]  __driver_probe_device+0x2ab/0x460
[   33.037026][ T1896]  ? usb_match_id.part.0+0x88/0xc0
[   33.037383][ T1896]  driver_probe_device+0x49/0x120
[   33.037790][ T1896]  __device_attach_driver+0x18a/0x250
[   33.038300][ T1896]  ? driver_allows_async_probing+0x120/0x120
[   33.038986][ T1896]  bus_for_each_drv+0x123/0x1a0
[   33.039906][ T1896]  ? bus_rescan_devices+0x20/0x20
[   33.041412][ T1896]  ? lockdep_hardirqs_on_prepare+0x273/0x3e0
[   33.041861][ T1896]  ? trace_hardirqs_on+0x1c/0x120
[   33.042330][ T1896]  __device_attach+0x207/0x330
[   33.042664][ T1896]  ? device_bind_driver+0xb0/0xb0
[   33.043026][ T1896]  ? kobject_uevent_env+0x230/0x12c0
[   33.043515][ T1896]  bus_probe_device+0x1a2/0x260
[   33.043914][ T1896]  device_add+0xa61/0x1ce0
[   33.044227][ T1896]  ? __mutex_unlock_slowpath+0xe7/0x660
[   33.044891][ T1896]  ? __fw_devlink_link_to_suppliers+0x550/0x550
[   33.045531][ T1896]  usb_set_configuration+0x984/0x1770
[   33.046051][ T1896]  ? kernfs_create_link+0x175/0x230
[   33.046548][ T1896]  usb_generic_driver_probe+0x69/0x90
[   33.046931][ T1896]  usb_probe_device+0x9c/0x220
[   33.047434][ T1896]  really_probe+0x1be/0xa90
[   33.047760][ T1896]  __driver_probe_device+0x2ab/0x460
[   33.048134][ T1896]  driver_probe_device+0x49/0x120
[   33.048516][ T1896]  __device_attach_driver+0x18a/0x250
[   33.048910][ T1896]  ? driver_allows_async_probing+0x120/0x120
[   33.049437][ T1896]  bus_for_each_drv+0x123/0x1a0
[   33.049814][ T1896]  ? bus_rescan_devices+0x20/0x20
[   33.050164][ T1896]  ? lockdep_hardirqs_on_prepare+0x273/0x3e0
[   33.050579][ T1896]  ? trace_hardirqs_on+0x1c/0x120
[   33.050936][ T1896]  __device_attach+0x207/0x330
[   33.051399][ T1896]  ? device_bind_driver+0xb0/0xb0
[   33.051888][ T1896]  ? kobject_uevent_env+0x230/0x12c0
[   33.052314][ T1896]  bus_probe_device+0x1a2/0x260
[   33.052688][ T1896]  device_add+0xa61/0x1ce0
[   33.053121][ T1896]  ? __fw_devlink_link_to_suppliers+0x550/0x550
[   33.053568][ T1896]  usb_new_device.cold+0x463/0xf66
[   33.053953][ T1896]  ? hub_disconnect+0x400/0x400
[   33.054313][ T1896]  ? rwlock_bug.part.0+0x90/0x90
[   33.054661][ T1896]  ? lockdep_hardirqs_on_prepare+0x273/0x3e0
[   33.055094][ T1896]  hub_event+0x10d5/0x3330
[   33.055530][ T1896]  ? hub_port_debounce+0x280/0x280
[   33.055934][ T1896]  ? __lock_acquire+0x1671/0x5790
[   33.056387][ T1896]  ? wq_calc_node_cpumask+0x170/0x2a0
[   33.056924][ T1896]  ? lock_release+0x640/0x640
[   33.057383][ T1896]  ? rcu_read_lock_sched_held+0xa1/0xd0
[   33.057916][ T1896]  ? rcu_read_lock_bh_held+0xb0/0xb0
[   33.058402][ T1896]  ? lockdep_hardirqs_on_prepare+0x273/0x3e0
[   33.059019][ T1896]  process_one_work+0x873/0x13e0
[   33.059488][ T1896]  ? lock_release+0x640/0x640
[   33.059932][ T1896]  ? pwq_dec_nr_in_flight+0x320/0x320
[   33.060446][ T1896]  ? rwlock_bug.part.0+0x90/0x90
[   33.060898][ T1896]  worker_thread+0x8b/0xd10
[   33.061348][ T1896]  ? __kthread_parkme+0xd9/0x1d0
[   33.061810][ T1896]  ? process_one_work+0x13e0/0x13e0
[   33.062288][ T1896]  kthread+0x379/0x450
[   33.062660][ T1896]  ? _raw_spin_unlock_irq+0x24/0x30
[   33.063148][ T1896]  ? set_kthread_struct+0x100/0x100
[   33.063606][ T1896]  ret_from_fork+0x1f/0x30
[   33.064070][ T1896]
[   33.064313][ T1896]
[   33.064545][ T1896] addr ffffc90001d6efc8 is located in stack of task kworker/0:2/1896 at offset 512 in frame:
[   33.065478][ T1896]  brcmf_c_preinit_dcmds+0x0/0xc40
[   33.065973][ T1896]
[   33.066191][ T1896] this frame has 4 objects:
[   33.066614][ T1896]  [48, 56) 'ptr'
[   33.066618][ T1896]  [80, 148) 'revinfo'
[   33.066957][ T1896]  [192, 210) 'eventmask'
[   33.067338][ T1896]  [256, 512) 'buf'
[   33.067742][ T1896]
[   33.068304][ T1896] Memory state around the buggy address:
[   33.068838][ T1896]  ffffc90001d6ee80: f2 00 00 02 f2 f2 f2 f2 f2 00 00 00 00 00 00 00
[   33.069545][ T1896]  ffffc90001d6ef00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[   33.070626][ T1896] &gt;ffffc90001d6ef80: 00 00 00 00 00 00 00 00 00 f3 f3 f3 f3 f3 f3 f3
[   33.072052][ T1896]                                               ^
[   33.073043][ T1896]  ffffc90001d6f000: f3 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[   33.074230][ T1896]  ffffc90001d6f080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[   33.074914][ T1896] ==================================================================
[   33.075713][ T1896] Disabling lock debugging due to kernel taint

Reviewed-by: Arend van Spriel&lt;arend.vanspriel@broadcom.com&gt;
Signed-off-by: Jisoo Jang &lt;jisoo.jang@yonsei.ac.kr&gt;
Signed-off-by: Kalle Valo &lt;kvalo@kernel.org&gt;
Link: https://lore.kernel.org/r/20221230075139.56591-1-jisoo.jang@yonsei.ac.kr
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 660145d708be52f946a82e5b633c020f58f996de ]

Fix a stack-out-of-bounds read in brcmfmac that occurs
when 'buf' that is not null-terminated is passed as an argument of
strreplace() in brcmf_c_preinit_dcmds(). This buffer is filled with
a CLM version string by memcpy() in brcmf_fil_iovar_data_get().
Ensure buf is null-terminated.

Found by a modified version of syzkaller.

[   33.004414][ T1896] brcmfmac: brcmf_c_process_clm_blob: no clm_blob available (err=-2), device may have limited channels available
[   33.013486][ T1896] brcmfmac: brcmf_c_preinit_dcmds: Firmware: BCM43236/3 wl0: Nov 30 2011 17:33:42 version 5.90.188.22
[   33.021554][ T1896] ==================================================================
[   33.022379][ T1896] BUG: KASAN: stack-out-of-bounds in strreplace+0xf2/0x110
[   33.023122][ T1896] Read of size 1 at addr ffffc90001d6efc8 by task kworker/0:2/1896
[   33.023852][ T1896]
[   33.024096][ T1896] CPU: 0 PID: 1896 Comm: kworker/0:2 Tainted: G           O      5.14.0+ #132
[   33.024927][ T1896] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.1-0-ga5cab58e9a3f-prebuilt.qemu.org 04/01/2014
[   33.026065][ T1896] Workqueue: usb_hub_wq hub_event
[   33.026581][ T1896] Call Trace:
[   33.026896][ T1896]  dump_stack_lvl+0x57/0x7d
[   33.027372][ T1896]  print_address_description.constprop.0.cold+0xf/0x334
[   33.028037][ T1896]  ? strreplace+0xf2/0x110
[   33.028403][ T1896]  ? strreplace+0xf2/0x110
[   33.028807][ T1896]  kasan_report.cold+0x83/0xdf
[   33.029283][ T1896]  ? strreplace+0xf2/0x110
[   33.029666][ T1896]  strreplace+0xf2/0x110
[   33.029966][ T1896]  brcmf_c_preinit_dcmds+0xab1/0xc40
[   33.030351][ T1896]  ? brcmf_c_set_joinpref_default+0x100/0x100
[   33.030787][ T1896]  ? rcu_read_lock_sched_held+0xa1/0xd0
[   33.031223][ T1896]  ? rcu_read_lock_bh_held+0xb0/0xb0
[   33.031661][ T1896]  ? lock_acquire+0x19d/0x4e0
[   33.032091][ T1896]  ? find_held_lock+0x2d/0x110
[   33.032605][ T1896]  ? brcmf_usb_deq+0x1a7/0x260
[   33.033087][ T1896]  ? brcmf_usb_rx_fill_all+0x5a/0xf0
[   33.033582][ T1896]  brcmf_attach+0x246/0xd40
[   33.034022][ T1896]  ? wiphy_new_nm+0x1476/0x1d50
[   33.034383][ T1896]  ? kmemdup+0x30/0x40
[   33.034722][ T1896]  brcmf_usb_probe+0x12de/0x1690
[   33.035223][ T1896]  ? brcmf_usbdev_qinit.constprop.0+0x470/0x470
[   33.035833][ T1896]  usb_probe_interface+0x25f/0x710
[   33.036315][ T1896]  really_probe+0x1be/0xa90
[   33.036656][ T1896]  __driver_probe_device+0x2ab/0x460
[   33.037026][ T1896]  ? usb_match_id.part.0+0x88/0xc0
[   33.037383][ T1896]  driver_probe_device+0x49/0x120
[   33.037790][ T1896]  __device_attach_driver+0x18a/0x250
[   33.038300][ T1896]  ? driver_allows_async_probing+0x120/0x120
[   33.038986][ T1896]  bus_for_each_drv+0x123/0x1a0
[   33.039906][ T1896]  ? bus_rescan_devices+0x20/0x20
[   33.041412][ T1896]  ? lockdep_hardirqs_on_prepare+0x273/0x3e0
[   33.041861][ T1896]  ? trace_hardirqs_on+0x1c/0x120
[   33.042330][ T1896]  __device_attach+0x207/0x330
[   33.042664][ T1896]  ? device_bind_driver+0xb0/0xb0
[   33.043026][ T1896]  ? kobject_uevent_env+0x230/0x12c0
[   33.043515][ T1896]  bus_probe_device+0x1a2/0x260
[   33.043914][ T1896]  device_add+0xa61/0x1ce0
[   33.044227][ T1896]  ? __mutex_unlock_slowpath+0xe7/0x660
[   33.044891][ T1896]  ? __fw_devlink_link_to_suppliers+0x550/0x550
[   33.045531][ T1896]  usb_set_configuration+0x984/0x1770
[   33.046051][ T1896]  ? kernfs_create_link+0x175/0x230
[   33.046548][ T1896]  usb_generic_driver_probe+0x69/0x90
[   33.046931][ T1896]  usb_probe_device+0x9c/0x220
[   33.047434][ T1896]  really_probe+0x1be/0xa90
[   33.047760][ T1896]  __driver_probe_device+0x2ab/0x460
[   33.048134][ T1896]  driver_probe_device+0x49/0x120
[   33.048516][ T1896]  __device_attach_driver+0x18a/0x250
[   33.048910][ T1896]  ? driver_allows_async_probing+0x120/0x120
[   33.049437][ T1896]  bus_for_each_drv+0x123/0x1a0
[   33.049814][ T1896]  ? bus_rescan_devices+0x20/0x20
[   33.050164][ T1896]  ? lockdep_hardirqs_on_prepare+0x273/0x3e0
[   33.050579][ T1896]  ? trace_hardirqs_on+0x1c/0x120
[   33.050936][ T1896]  __device_attach+0x207/0x330
[   33.051399][ T1896]  ? device_bind_driver+0xb0/0xb0
[   33.051888][ T1896]  ? kobject_uevent_env+0x230/0x12c0
[   33.052314][ T1896]  bus_probe_device+0x1a2/0x260
[   33.052688][ T1896]  device_add+0xa61/0x1ce0
[   33.053121][ T1896]  ? __fw_devlink_link_to_suppliers+0x550/0x550
[   33.053568][ T1896]  usb_new_device.cold+0x463/0xf66
[   33.053953][ T1896]  ? hub_disconnect+0x400/0x400
[   33.054313][ T1896]  ? rwlock_bug.part.0+0x90/0x90
[   33.054661][ T1896]  ? lockdep_hardirqs_on_prepare+0x273/0x3e0
[   33.055094][ T1896]  hub_event+0x10d5/0x3330
[   33.055530][ T1896]  ? hub_port_debounce+0x280/0x280
[   33.055934][ T1896]  ? __lock_acquire+0x1671/0x5790
[   33.056387][ T1896]  ? wq_calc_node_cpumask+0x170/0x2a0
[   33.056924][ T1896]  ? lock_release+0x640/0x640
[   33.057383][ T1896]  ? rcu_read_lock_sched_held+0xa1/0xd0
[   33.057916][ T1896]  ? rcu_read_lock_bh_held+0xb0/0xb0
[   33.058402][ T1896]  ? lockdep_hardirqs_on_prepare+0x273/0x3e0
[   33.059019][ T1896]  process_one_work+0x873/0x13e0
[   33.059488][ T1896]  ? lock_release+0x640/0x640
[   33.059932][ T1896]  ? pwq_dec_nr_in_flight+0x320/0x320
[   33.060446][ T1896]  ? rwlock_bug.part.0+0x90/0x90
[   33.060898][ T1896]  worker_thread+0x8b/0xd10
[   33.061348][ T1896]  ? __kthread_parkme+0xd9/0x1d0
[   33.061810][ T1896]  ? process_one_work+0x13e0/0x13e0
[   33.062288][ T1896]  kthread+0x379/0x450
[   33.062660][ T1896]  ? _raw_spin_unlock_irq+0x24/0x30
[   33.063148][ T1896]  ? set_kthread_struct+0x100/0x100
[   33.063606][ T1896]  ret_from_fork+0x1f/0x30
[   33.064070][ T1896]
[   33.064313][ T1896]
[   33.064545][ T1896] addr ffffc90001d6efc8 is located in stack of task kworker/0:2/1896 at offset 512 in frame:
[   33.065478][ T1896]  brcmf_c_preinit_dcmds+0x0/0xc40
[   33.065973][ T1896]
[   33.066191][ T1896] this frame has 4 objects:
[   33.066614][ T1896]  [48, 56) 'ptr'
[   33.066618][ T1896]  [80, 148) 'revinfo'
[   33.066957][ T1896]  [192, 210) 'eventmask'
[   33.067338][ T1896]  [256, 512) 'buf'
[   33.067742][ T1896]
[   33.068304][ T1896] Memory state around the buggy address:
[   33.068838][ T1896]  ffffc90001d6ee80: f2 00 00 02 f2 f2 f2 f2 f2 00 00 00 00 00 00 00
[   33.069545][ T1896]  ffffc90001d6ef00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[   33.070626][ T1896] &gt;ffffc90001d6ef80: 00 00 00 00 00 00 00 00 00 f3 f3 f3 f3 f3 f3 f3
[   33.072052][ T1896]                                               ^
[   33.073043][ T1896]  ffffc90001d6f000: f3 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[   33.074230][ T1896]  ffffc90001d6f080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[   33.074914][ T1896] ==================================================================
[   33.075713][ T1896] Disabling lock debugging due to kernel taint

Reviewed-by: Arend van Spriel&lt;arend.vanspriel@broadcom.com&gt;
Signed-off-by: Jisoo Jang &lt;jisoo.jang@yonsei.ac.kr&gt;
Signed-off-by: Kalle Valo &lt;kvalo@kernel.org&gt;
Link: https://lore.kernel.org/r/20221230075139.56591-1-jisoo.jang@yonsei.ac.kr
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>wifi: ath11k: debugfs: fix to work with multiple PCI devices</title>
<updated>2023-03-10T08:29:08+00:00</updated>
<author>
<name>Kalle Valo</name>
<email>quic_kvalo@quicinc.com</email>
</author>
<published>2022-12-22T17:15:59+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=8ec481e85e05665d133d679b7d36e4adcb4fb836'/>
<id>8ec481e85e05665d133d679b7d36e4adcb4fb836</id>
<content type='text'>
[ Upstream commit 323d91d4684d238f6bc3693fed93caf795378fe0 ]

ath11k fails to load if there are multiple ath11k PCI devices with same name:

 ath11k_pci 0000:01:00.0: Hardware name qcn9074 hw1.0
 debugfs: Directory 'ath11k' with parent '/' already present!
 ath11k_pci 0000:01:00.0: failed to create ath11k debugfs
 ath11k_pci 0000:01:00.0: failed to create soc core: -17
 ath11k_pci 0000:01:00.0: failed to init core: -17
 ath11k_pci: probe of 0000:01:00.0 failed with error -17

Fix this by creating a directory for each ath11k device using schema
&lt;bus&gt;-&lt;devname&gt;, for example "pci-0000:06:00.0". This directory created under
the top-level ath11k directory, for example /sys/kernel/debug/ath11k.

The reference to the toplevel ath11k directory is not stored anymore within ath11k, instead
it's retrieved using debugfs_lookup(). If the directory does not exist it will
be created. After the last directory from the ath11k directory is removed, for
example when doing rmmod ath11k, the empty ath11k directory is left in place,
it's a minor cosmetic issue anyway.

Here's an example hierarchy with one WCN6855:

ath11k
`-- pci-0000:06:00.0
    |-- mac0
    |   |-- dfs_block_radar_events
    |   |-- dfs_simulate_radar
    |   |-- ext_rx_stats
    |   |-- ext_tx_stats
    |   |-- fw_dbglog_config
    |   |-- fw_stats
    |   |   |-- beacon_stats
    |   |   |-- pdev_stats
    |   |   `-- vdev_stats
    |   |-- htt_stats
    |   |-- htt_stats_reset
    |   |-- htt_stats_type
    |   `-- pktlog_filter
    |-- simulate_fw_crash
    `-- soc_dp_stats

I didn't have a test setup where I could connect multiple ath11k devices to the
same the host, so I have only tested this with one device.

Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.9
Tested-on: IPQ8074 hw2.0 AHB WLAN.HK.2.5.0.1-01208-QCAHKSWPL_SILICONZ-1
Tested-on: QCN9074 hw1.0 PCI WLAN.HK.2.5.0.1-01208-QCAHKSWPL_SILICONZ-1

Tested-by: Robert Marko &lt;robert.marko@sartura.hr&gt;
Signed-off-by: Kalle Valo &lt;quic_kvalo@quicinc.com&gt;
Link: https://lore.kernel.org/r/20221220121231.20120-1-kvalo@kernel.org
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 323d91d4684d238f6bc3693fed93caf795378fe0 ]

ath11k fails to load if there are multiple ath11k PCI devices with same name:

 ath11k_pci 0000:01:00.0: Hardware name qcn9074 hw1.0
 debugfs: Directory 'ath11k' with parent '/' already present!
 ath11k_pci 0000:01:00.0: failed to create ath11k debugfs
 ath11k_pci 0000:01:00.0: failed to create soc core: -17
 ath11k_pci 0000:01:00.0: failed to init core: -17
 ath11k_pci: probe of 0000:01:00.0 failed with error -17

Fix this by creating a directory for each ath11k device using schema
&lt;bus&gt;-&lt;devname&gt;, for example "pci-0000:06:00.0". This directory created under
the top-level ath11k directory, for example /sys/kernel/debug/ath11k.

The reference to the toplevel ath11k directory is not stored anymore within ath11k, instead
it's retrieved using debugfs_lookup(). If the directory does not exist it will
be created. After the last directory from the ath11k directory is removed, for
example when doing rmmod ath11k, the empty ath11k directory is left in place,
it's a minor cosmetic issue anyway.

Here's an example hierarchy with one WCN6855:

ath11k
`-- pci-0000:06:00.0
    |-- mac0
    |   |-- dfs_block_radar_events
    |   |-- dfs_simulate_radar
    |   |-- ext_rx_stats
    |   |-- ext_tx_stats
    |   |-- fw_dbglog_config
    |   |-- fw_stats
    |   |   |-- beacon_stats
    |   |   |-- pdev_stats
    |   |   `-- vdev_stats
    |   |-- htt_stats
    |   |-- htt_stats_reset
    |   |-- htt_stats_type
    |   `-- pktlog_filter
    |-- simulate_fw_crash
    `-- soc_dp_stats

I didn't have a test setup where I could connect multiple ath11k devices to the
same the host, so I have only tested this with one device.

Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.9
Tested-on: IPQ8074 hw2.0 AHB WLAN.HK.2.5.0.1-01208-QCAHKSWPL_SILICONZ-1
Tested-on: QCN9074 hw1.0 PCI WLAN.HK.2.5.0.1-01208-QCAHKSWPL_SILICONZ-1

Tested-by: Robert Marko &lt;robert.marko@sartura.hr&gt;
Signed-off-by: Kalle Valo &lt;quic_kvalo@quicinc.com&gt;
Link: https://lore.kernel.org/r/20221220121231.20120-1-kvalo@kernel.org
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</pre>
</div>
</content>
</entry>
</feed>
