<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel.git/drivers/net/wireless/realtek, branch linux-5.16.y</title>
<subtitle>Hosts the 0x221E linux distro kernel.
</subtitle>
<id>https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-5.16.y</id>
<link rel='self' href='https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-5.16.y'/>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/'/>
<updated>2022-04-13T18:03:02Z</updated>
<entry>
<title>rtw89: fix RCU usage in rtw89_core_txq_push()</title>
<updated>2022-04-13T18:03:02Z</updated>
<author>
<name>Jiri Kosina</name>
</author>
<published>2022-02-15T19:37:51Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=6a2d29cb71d5d2e112a6f1cf479385135ede6384'/>
<id>urn:sha1:6a2d29cb71d5d2e112a6f1cf479385135ede6384</id>
<content type='text'>
[ Upstream commit f3d825a35920714fb7f73e4d4f36ea2328860660 ]

ieee80211_tx_h_select_key() is performing a series of RCU dereferences,
but rtw89_core_txq_push() is calling it (via ieee80211_tx_dequeue_ni())
without RCU read-side lock held; fix that.

This addresses the splat below.

 =============================
 WARNING: suspicious RCU usage
 5.17.0-rc4-00003-gccad664b7f14 #3 Tainted: G            E
 -----------------------------
 net/mac80211/tx.c:593 suspicious rcu_dereference_check() usage!

 other info that might help us debug this:

 rcu_scheduler_active = 2, debug_locks = 1
 2 locks held by kworker/u33:0/184:
  #0: ffff9c0b14811d38 ((wq_completion)rtw89_tx_wq){+.+.}-{0:0}, at: process_one_work+0x258/0x660
  #1: ffffb97380cf3e78 ((work_completion)(&amp;rtwdev-&gt;txq_work)){+.+.}-{0:0}, at: process_one_work+0x258/0x660

 stack backtrace:
 CPU: 8 PID: 184 Comm: kworker/u33:0 Tainted: G            E     5.17.0-rc4-00003-gccad664b7f14 #3 473b49ab0e7c2d6af2900c756bfd04efd7a9de13
 Hardware name: LENOVO 20UJS2B905/20UJS2B905, BIOS R1CET63W(1.32 ) 04/09/2021
 Workqueue: rtw89_tx_wq rtw89_core_txq_work [rtw89_core]
 Call Trace:
  &lt;TASK&gt;
  dump_stack_lvl+0x58/0x71
  ieee80211_tx_h_select_key+0x2c0/0x530 [mac80211 911c23e2351c0ae60b597a67b1204a5ea955e365]
  ieee80211_tx_dequeue+0x1a7/0x1260 [mac80211 911c23e2351c0ae60b597a67b1204a5ea955e365]
  rtw89_core_txq_work+0x1a6/0x420 [rtw89_core b39ba493f2e517ad75e0f8187ecc24edf58bbbea]
  process_one_work+0x2d8/0x660
  worker_thread+0x39/0x3e0
  ? process_one_work+0x660/0x660
  kthread+0xe5/0x110
  ? kthread_complete_and_exit+0x20/0x20
  ret_from_fork+0x22/0x30
  &lt;/TASK&gt;

 =============================
 WARNING: suspicious RCU usage
 5.17.0-rc4-00003-gccad664b7f14 #3 Tainted: G            E
 -----------------------------
 net/mac80211/tx.c:607 suspicious rcu_dereference_check() usage!

 other info that might help us debug this:

 rcu_scheduler_active = 2, debug_locks = 1
 2 locks held by kworker/u33:0/184:
  #0: ffff9c0b14811d38 ((wq_completion)rtw89_tx_wq){+.+.}-{0:0}, at: process_one_work+0x258/0x660
  #1: ffffb97380cf3e78 ((work_completion)(&amp;rtwdev-&gt;txq_work)){+.+.}-{0:0}, at: process_one_work+0x258/0x660

 stack backtrace:
 CPU: 8 PID: 184 Comm: kworker/u33:0 Tainted: G            E     5.17.0-rc4-00003-gccad664b7f14 #3 473b49ab0e7c2d6af2900c756bfd04efd7a9de13
 Hardware name: LENOVO 20UJS2B905/20UJS2B905, BIOS R1CET63W(1.32 ) 04/09/2021
 Workqueue: rtw89_tx_wq rtw89_core_txq_work [rtw89_core]
 Call Trace:
  &lt;TASK&gt;
  dump_stack_lvl+0x58/0x71
  ieee80211_tx_h_select_key+0x464/0x530 [mac80211 911c23e2351c0ae60b597a67b1204a5ea955e365]
  ieee80211_tx_dequeue+0x1a7/0x1260 [mac80211 911c23e2351c0ae60b597a67b1204a5ea955e365]
  rtw89_core_txq_work+0x1a6/0x420 [rtw89_core b39ba493f2e517ad75e0f8187ecc24edf58bbbea]
  process_one_work+0x2d8/0x660
  worker_thread+0x39/0x3e0
  ? process_one_work+0x660/0x660
  kthread+0xe5/0x110
  ? kthread_complete_and_exit+0x20/0x20
  ret_from_fork+0x22/0x30
  &lt;/TASK&gt;

Signed-off-by: Jiri Kosina &lt;jkosina@suse.cz&gt;
Acked-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/nycvar.YFH.7.76.2202152037000.11721@cbobk.fhfr.pm
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>rtw88: 8822c: update rx settings to prevent potential hw deadlock</title>
<updated>2022-01-27T11:02:26Z</updated>
<author>
<name>Po-Hao Huang</name>
</author>
<published>2021-12-17T01:27:08Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=4b986bd6004cf07c28d6335b685f795cb94a81e1'/>
<id>urn:sha1:4b986bd6004cf07c28d6335b685f795cb94a81e1</id>
<content type='text'>
[ Upstream commit c1afb26727d9e507d3e17a9890e7aaf7fc85cd55 ]

These settings enables mac to detect and recover when rx fifo
circuit deadlock occurs. Previous version missed this, so we fix it.

Signed-off-by: Po-Hao Huang &lt;phhuang@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/20211217012708.8623-1-pkshih@realtek.com
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>rtw89: don't kick off TX DMA if failed to write skb</title>
<updated>2022-01-27T11:02:21Z</updated>
<author>
<name>Ping-Ke Shih</name>
</author>
<published>2021-12-01T09:38:16Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=ce7eff571f05a3ff4de91d84a79feb3a13c16c10'/>
<id>urn:sha1:ce7eff571f05a3ff4de91d84a79feb3a13c16c10</id>
<content type='text'>
[ Upstream commit a58fdb7c843a37d6598204c6513961feefdadc6a ]

This is found by Smatch static checker warning:
	drivers/net/wireless/realtek/rtw89/mac80211.c:31 rtw89_ops_tx()
	error: uninitialized symbol 'qsel'.

The warning is because 'qsel' isn't filled by rtw89_core_tx_write() due to
failed to write. The way to fix it is to avoid kicking off TX DMA, so add
'return' to the failure case.

Reported-by: Dan Carpenter &lt;dan.carpenter@oracle.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/20211201093816.13806-1-pkshih@realtek.com
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>rtw89: fix potentially access out of range of RF register array</title>
<updated>2022-01-27T11:02:17Z</updated>
<author>
<name>Ping-Ke Shih</name>
</author>
<published>2021-11-19T05:57:29Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=b888433c205225ee0c8debea55a6cfbe1413763b'/>
<id>urn:sha1:b888433c205225ee0c8debea55a6cfbe1413763b</id>
<content type='text'>
[ Upstream commit 30101812a09b37bc8aa409a83f603d4c072198f2 ]

The RF register array is used to help firmware to restore RF settings.
The original code can potentially access out of range, if the size is
between (RTW89_H2C_RF_PAGE_SIZE * RTW89_H2C_RF_PAGE_NUM + 1) to
((RTW89_H2C_RF_PAGE_SIZE + 1) * RTW89_H2C_RF_PAGE_NUM). Fortunately,
current used size doesn't fall into the wrong case, and the size will not
change if we don't update RF parameter.

Reported-by: Dan Carpenter &lt;dan.carpenter@oracle.com&gt;
Signed-off-by: Ping-Ke Shih &lt;pkshih@realtek.com&gt;
Signed-off-by: Kalle Valo &lt;kvalo@codeaurora.org&gt;
Link: https://lore.kernel.org/r/20211119055729.12826-1-pkshih@realtek.com
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>rtw88: Disable PCIe ASPM while doing NAPI poll on 8821CE</title>
<updated>2022-01-27T11:01:50Z</updated>
<author>
<name>Kai-Heng Feng</name>
</author>
<published>2021-12-15T11:46:34Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=f21e8cb927fa9da49490b74ddda3856a828b82d6'/>
<id>urn:sha1:f21e8cb927fa9da49490b74ddda3856a828b82d6</id>
<content type='text'>
[ Upstream commit 24f5e38a13b5ae2b6105cda8bb47c19108e62a9a ]

Many Intel based platforms face system random freeze after commit
9e2fd29864c5 ("rtw88: add napi support").

The commit itself shouldn't be the culprit. My guess is that the 8821CE
only leaves ASPM L1 for a short period when IRQ is raised. Since IRQ is
masked during NAPI polling, the PCIe link stays at L1 and makes RX DMA
extremely slow. Eventually the RX ring becomes messed up:
[ 1133.194697] rtw_8821ce 0000:02:00.0: pci bus timeout, check dma status

Since the 8821CE hardware may fail to leave ASPM L1, manually do it in
the driver to resolve the issue.

Fixes: 9e2fd29864c5 ("rtw88: add napi support")
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=215131
BugLink: https://bugs.launchpad.net/bugs/1927808
Signed-off-by: Kai-Heng Feng &lt;kai.heng.feng@canonical.com&gt;
Acked-by: Jian-Hong Pan &lt;jhp@endlessos.org&gt;
Signed-off-by: Kalle Valo &lt;kvalo@kernel.org&gt;
Link: https://lore.kernel.org/r/20211215114635.333767-1-kai.heng.feng@canonical.com
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>rtw88: add quirk to disable pci caps on HP 250 G7 Notebook PC</title>
<updated>2022-01-27T11:01:50Z</updated>
<author>
<name>Ping-Ke Shih</name>
</author>
<published>2021-11-19T05:24:37Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=db7e4381c811fe372946cd5636cbca66ccfde9d3'/>
<id>urn:sha1:db7e4381c811fe372946cd5636cbca66ccfde9d3</id>
<content type='text'>
[ Upstream commit c81edb8dddaa36c4defa26240cc19127f147283f ]

8821CE causes random freezes on HP 250 G7 Notebook PC. Add a quirk
to disable pci ASPM capability.

Reported-by: rtl8821cerfe2 &lt;rtl8821cerfe2@protonmail.com&gt;
Signed-off-by: Ping-Ke Shih &lt;pkshih@realtek.com&gt;
Signed-off-by: Kalle Valo &lt;kvalo@codeaurora.org&gt;
Link: https://lore.kernel.org/r/20211119052437.8671-1-pkshih@realtek.com
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>rtlwifi: rtl8192cu: Fix WARNING when calling local_irq_restore() with interrupts enabled</title>
<updated>2022-01-20T08:12:21Z</updated>
<author>
<name>Larry Finger</name>
</author>
<published>2021-12-15T17:11:05Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=105ee59fc79edf9f2297eeb5cb539cdd174186c0'/>
<id>urn:sha1:105ee59fc79edf9f2297eeb5cb539cdd174186c0</id>
<content type='text'>
commit 8b144dedb928e4e2f433a328d58f44c3c098d63e upstream.

Syzbot reports the following WARNING:

[200~raw_local_irq_restore() called with IRQs enabled
WARNING: CPU: 1 PID: 1206 at kernel/locking/irqflag-debug.c:10
   warn_bogus_irq_restore+0x1d/0x20 kernel/locking/irqflag-debug.c:10

Hardware initialization for the rtl8188cu can run for as long as 350 ms,
and the routine may be called with interrupts disabled. To avoid locking
the machine for this long, the current routine saves the interrupt flags
and enables local interrupts. The problem is that it restores the flags
at the end without disabling local interrupts first.

This patch fixes commit a53268be0cb9 ("rtlwifi: rtl8192cu: Fix too long
disable of IRQs").

Reported-by: syzbot+cce1ee31614c171f5595@syzkaller.appspotmail.com
Cc: stable@vger.kernel.org
Fixes: a53268be0cb9 ("rtlwifi: rtl8192cu: Fix too long disable of IRQs")
Signed-off-by: Larry Finger &lt;Larry.Finger@lwfinger.net&gt;
Signed-off-by: Kalle Valo &lt;kvalo@kernel.org&gt;
Link: https://lore.kernel.org/r/20211215171105.20623-1-Larry.Finger@lwfinger.net
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>rtw89: update partition size of firmware header on skb-&gt;data</title>
<updated>2021-11-22T18:42:15Z</updated>
<author>
<name>Ping-Ke Shih</name>
</author>
<published>2021-11-19T05:45:10Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=5737b4515deea0829c138ab5201160345ec67d49'/>
<id>urn:sha1:5737b4515deea0829c138ab5201160345ec67d49</id>
<content type='text'>
The partition size is used to tell hardware the size of piece we are going
to send a firmware. The old code updates the size in constant buffer of
firmware, and leads system crash.

To fix this, update the size on skb-&gt;data after we copy the firmware data
into skb.

Buglink: https://bugzilla.opensuse.org/show_bug.cgi?id=1188303
Fixes: e3ec7017f6a2 ("rtw89: add Realtek 802.11ax driver")
Reported-by: Takashi Iwai &lt;tiwai@suse.de&gt;
Signed-off-by: Ping-Ke Shih &lt;pkshih@realtek.com&gt;
Tested-by: Takashi Iwai &lt;tiwai@suse.de&gt;
Tested-by: Larry Finger &lt;Larry.Finger@lwfinger.net&gt;
Signed-off-by: Kalle Valo &lt;kvalo@codeaurora.org&gt;
Link: https://lore.kernel.org/r/20211119054512.10620-2-pkshih@realtek.com
</content>
</entry>
<entry>
<title>rtl8187: fix control-message timeouts</title>
<updated>2021-10-28T13:26:18Z</updated>
<author>
<name>Johan Hovold</name>
</author>
<published>2021-10-25T12:05:21Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=2e9be536a213e838daed6ba42024dd68954ac061'/>
<id>urn:sha1:2e9be536a213e838daed6ba42024dd68954ac061</id>
<content type='text'>
USB control-message timeouts are specified in milliseconds and should
specifically not vary with CONFIG_HZ.

Fixes: 605bebe23bf6 ("[PATCH] Add rtl8187 wireless driver")
Cc: stable@vger.kernel.org      # 2.6.23
Signed-off-by: Johan Hovold &lt;johan@kernel.org&gt;
Signed-off-by: Kalle Valo &lt;kvalo@codeaurora.org&gt;
Link: https://lore.kernel.org/r/20211025120522.6045-4-johan@kernel.org
</content>
</entry>
<entry>
<title>rtw89: Fix variable dereferenced before check 'sta'</title>
<updated>2021-10-27T07:37:59Z</updated>
<author>
<name>Ping-Ke Shih</name>
</author>
<published>2021-10-22T06:12:42Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=5d44f0672319c19a41ff0e0e4f0d64164cf9752b'/>
<id>urn:sha1:5d44f0672319c19a41ff0e0e4f0d64164cf9752b</id>
<content type='text'>
The pointer rtwsta is dereferencing pointer sta before sta is being null
checked. Fix this by assigning sta-&gt;drv_priv to rtwsta only if sta is not
NULL, otherwise just NULL.

Fixes: e3ec7017f6a2 ("rtw89: add Realtek 802.11ax driver")
Reported-by: Colin Ian King &lt;colin.king@canonical.com&gt;
Signed-off-by: Ping-Ke Shih &lt;pkshih@realtek.com&gt;
Signed-off-by: Kalle Valo &lt;kvalo@codeaurora.org&gt;
Link: https://lore.kernel.org/r/20211022061242.8383-1-pkshih@realtek.com
</content>
</entry>
</feed>
