<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/drivers/net/wireless/realtek, branch v6.4</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=v6.4</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=v6.4'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2023-06-01T13:16:41+00:00</updated>
<entry>
<title>wifi: rtw89: remove redundant check of entering LPS</title>
<updated>2023-06-01T13:16:41+00:00</updated>
<author>
<name>Ping-Ke Shih</name>
<email>pkshih@realtek.com</email>
</author>
<published>2023-05-27T08:29:39+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=b408f33b35a4de606bfbd0de33b8f971bc5488ba'/>
<id>urn:sha1:b408f33b35a4de606bfbd0de33b8f971bc5488ba</id>
<content type='text'>
Originally, add this check rule to prevent entering LPS if more than one
vif (in station mode) connect to AP. Since we have checked this by previous
commit, remove this redundant check.

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/20230527082939.11206-4-pkshih@realtek.com
</content>
</entry>
<entry>
<title>wifi: rtw89: correct PS calculation for SUPPORTS_DYNAMIC_PS</title>
<updated>2023-06-01T13:16:41+00:00</updated>
<author>
<name>Ping-Ke Shih</name>
<email>pkshih@realtek.com</email>
</author>
<published>2023-05-27T08:29:38+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=26a125f550a3bf86ac91d38752f4d446426dfe1c'/>
<id>urn:sha1:26a125f550a3bf86ac91d38752f4d446426dfe1c</id>
<content type='text'>
This driver relies on IEEE80211_CONF_PS of hw-&gt;conf.flags to turn off PS or
turn on dynamic PS controlled by driver and firmware. Though this would be
incorrect, it did work before because the flag is always recalculated until
the commit 28977e790b5d ("wifi: mac80211: skip powersave recalc if driver SUPPORTS_DYNAMIC_PS")
is introduced by kernel 5.20 to skip to recalculate IEEE80211_CONF_PS
of hw-&gt;conf.flags if driver sets SUPPORTS_DYNAMIC_PS.

Correct this by doing recalculation while BSS_CHANGED_PS is changed and
interface is added or removed. For now, it is allowed to enter PS only if
single one station vif is working, and it could possible to have PS per
vif after firmware can support it. Without this fix, driver doesn't
enter PS anymore that causes higher power consumption.

Fixes: e3ec7017f6a2 ("rtw89: add Realtek 802.11ax driver")
Cc: stable@vger.kernel.org # 6.1+
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/20230527082939.11206-3-pkshih@realtek.com
</content>
</entry>
<entry>
<title>wifi: rtw88: correct PS calculation for SUPPORTS_DYNAMIC_PS</title>
<updated>2023-06-01T13:16:40+00:00</updated>
<author>
<name>Ping-Ke Shih</name>
<email>pkshih@realtek.com</email>
</author>
<published>2023-05-27T08:29:37+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=3918dd0177ee08970683a2c22a3388825d82fd79'/>
<id>urn:sha1:3918dd0177ee08970683a2c22a3388825d82fd79</id>
<content type='text'>
This driver relies on IEEE80211_CONF_PS of hw-&gt;conf.flags to turn off PS or
turn on dynamic PS controlled by driver and firmware. Though this would be
incorrect, it did work before because the flag is always recalculated until
the commit 28977e790b5d ("wifi: mac80211: skip powersave recalc if driver SUPPORTS_DYNAMIC_PS")
is introduced by kernel 5.20 to skip to recalculate IEEE80211_CONF_PS
of hw-&gt;conf.flags if driver sets SUPPORTS_DYNAMIC_PS.

Correct this by doing recalculation while BSS_CHANGED_PS is changed and
interface is added or removed. It is allowed to enter PS only if single
one station vif is working. Without this fix, driver doesn't enter PS
anymore that causes higher power consumption.

Fixes: bcde60e599fb ("rtw88: remove misleading module parameter rtw_fw_support_lps")
Cc: stable@vger.kernel.org # 6.1+
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/20230527082939.11206-2-pkshih@realtek.com
</content>
</entry>
<entry>
<title>wifi: rtw88: sdio: Always use two consecutive bytes for word operations</title>
<updated>2023-05-17T06:09:41+00:00</updated>
<author>
<name>Martin Blumenstingl</name>
<email>martin.blumenstingl@googlemail.com</email>
</author>
<published>2023-05-15T19:50:43+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=cb0ddaaa5db09d7d216fcbf0e68779be223a1128'/>
<id>urn:sha1:cb0ddaaa5db09d7d216fcbf0e68779be223a1128</id>
<content type='text'>
The Allwinner sunxi-mmc controller cannot handle word (16 bit)
transfers. So and sdio_{read,write}w fails with messages like the
following example using an RTL8822BS (but the same problems were also
observed with RTL8822CS and RTL8723DS chips):
  rtw_8822bs mmc1:0001:1: Firmware version 27.2.0, H2C version 13
  sunxi-mmc 4021000.mmc: unaligned scatterlist: os f80 length 2
  sunxi-mmc 4021000.mmc: map DMA failed
  rtw_8822bs mmc1:0001:1: sdio read16 failed (0x10230): -22

Use two consecutive single byte accesses for word operations instead. It
turns out that upon closer inspection this is also what the vendor
driver does, even though it does have support for sdio_{read,write}w. So
we can conclude that the rtw88 chips do support word access but only on
SDIO controllers that also support it. Since there's no way to detect if
the controller supports word access or not the rtw88 sdio driver
switches to the easiest approach: avoiding word access.

Reported-by: Larry Finger &lt;Larry.Finger@lwfinger.net&gt;
Closes: https://lore.kernel.org/linux-wireless/527585e5-9cdd-66ed-c3af-6da162f4b720@lwfinger.net/
Reported-by: Rudi Heitbaum &lt;rudi@heitbaum.com&gt;
Link: https://github.com/LibreELEC/LibreELEC.tv/pull/7837#issue-1708469467
Fixes: 65371a3f14e7 ("wifi: rtw88: sdio: Add HCI implementation for SDIO based chipsets")
Reviewed-by: Ping-Ke Shih &lt;pkshih@realtek.com&gt;
Signed-off-by: Martin Blumenstingl &lt;martin.blumenstingl@googlemail.com&gt;
Signed-off-by: Kalle Valo &lt;kvalo@kernel.org&gt;
Link: https://lore.kernel.org/r/20230515195043.572375-1-martin.blumenstingl@googlemail.com
</content>
</entry>
<entry>
<title>wifi: rtl8xxxu: fix authentication timeout due to incorrect RCR value</title>
<updated>2023-05-15T18:19:21+00:00</updated>
<author>
<name>Yun Lu</name>
<email>luyun@kylinos.cn</email>
</author>
<published>2023-05-12T01:20:55+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=20429444e653ee8242dfbf815c0c37866beb371b'/>
<id>urn:sha1:20429444e653ee8242dfbf815c0c37866beb371b</id>
<content type='text'>
When using rtl8192cu with rtl8xxxu driver to connect wifi, there is a
probability of failure, which shows "authentication with ... timed out".
Through debugging, it was found that the RCR register has been inexplicably
modified to an incorrect value, resulting in the nic not being able to
receive authenticated frames.

To fix this problem, add regrcr in rtl8xxxu_priv struct, and store
the RCR value every time the register is written, and use it the next
time the register need to be modified.

Signed-off-by: Yun Lu &lt;luyun@kylinos.cn&gt;
Link: https://lore.kernel.org/all/20230427020512.1221062-1-luyun_611@163.com
Signed-off-by: Kalle Valo &lt;kvalo@kernel.org&gt;
Link: https://lore.kernel.org/r/20230512012055.2990472-1-luyun_611@163.com
</content>
</entry>
<entry>
<title>wifi: rtw88: correct qsel_to_ep[] type as int</title>
<updated>2023-05-15T18:16:19+00:00</updated>
<author>
<name>Ping-Ke Shih</name>
<email>pkshih@realtek.com</email>
</author>
<published>2023-05-08T08:55:39+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=8e4942db5f5ed7b7d9690d93235b3ca49c5c59ce'/>
<id>urn:sha1:8e4942db5f5ed7b7d9690d93235b3ca49c5c59ce</id>
<content type='text'>
qsel_to_ep[] can be assigned negative value, so change type from 'u8' to
'int'. Otherwise, Smatch static checker warns:
  drivers/net/wireless/realtek/rtw88/usb.c:219 rtw_usb_parse() warn:
  assigning (-22) to unsigned variable 'rtwusb-&gt;qsel_to_ep[8]'

Cc: stable@vger.kernel.org
Fixes: a6f187f92bcc ("wifi: rtw88: usb: fix priority queue to endpoint mapping")
Reported-by: Dan Carpenter &lt;dan.carpenter@linaro.org&gt;
Link: https://lore.kernel.org/linux-wireless/c3f70197-829d-48ed-ae15-66a9de80fa90@kili.mountain/
Cc: Sascha Hauer &lt;s.hauer@pengutronix.de&gt;
Signed-off-by: Ping-Ke Shih &lt;pkshih@realtek.com&gt;
Acked-by: Sascha Hauer &lt;s.hauer@pengutronix.de&gt;
Tested-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/20230508085539.46795-1-pkshih@realtek.com
</content>
</entry>
<entry>
<title>wifi: rtw88: use work to update rate to avoid RCU warning</title>
<updated>2023-05-12T08:23:15+00:00</updated>
<author>
<name>Ping-Ke Shih</name>
<email>pkshih@realtek.com</email>
</author>
<published>2023-05-08T08:54:29+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=bcafcb959a57a6890e900199690c5fc47da1a304'/>
<id>urn:sha1:bcafcb959a57a6890e900199690c5fc47da1a304</id>
<content type='text'>
The ieee80211_ops::sta_rc_update must be atomic, because
ieee80211_chan_bw_change() holds rcu_read lock while calling
drv_sta_rc_update(), so create a work to do original things.

 Voluntary context switch within RCU read-side critical section!
 WARNING: CPU: 0 PID: 4621 at kernel/rcu/tree_plugin.h:318
 rcu_note_context_switch+0x571/0x5d0
 CPU: 0 PID: 4621 Comm: kworker/u16:2 Tainted: G        W  OE
 Workqueue: phy3 ieee80211_chswitch_work [mac80211]
 RIP: 0010:rcu_note_context_switch+0x571/0x5d0
 Call Trace:
  &lt;TASK&gt;
  __schedule+0xb0/0x1460
  ? __mod_timer+0x116/0x360
  schedule+0x5a/0xc0
  schedule_timeout+0x87/0x150
  ? trace_raw_output_tick_stop+0x60/0x60
  wait_for_completion_timeout+0x7b/0x140
  usb_start_wait_urb+0x82/0x160 [usbcore
  usb_control_msg+0xe3/0x140 [usbcore
  rtw_usb_read+0x88/0xe0 [rtw_usb
  rtw_usb_read8+0xf/0x10 [rtw_usb
  rtw_fw_send_h2c_command+0xa0/0x170 [rtw_core
  rtw_fw_send_ra_info+0xc9/0xf0 [rtw_core
  drv_sta_rc_update+0x7c/0x160 [mac80211
  ieee80211_chan_bw_change+0xfb/0x110 [mac80211
  ieee80211_change_chanctx+0x38/0x130 [mac80211
  ieee80211_vif_use_reserved_switch+0x34e/0x900 [mac80211
  ieee80211_link_use_reserved_context+0x88/0xe0 [mac80211
  ieee80211_chswitch_work+0x95/0x170 [mac80211
  process_one_work+0x201/0x410
  worker_thread+0x4a/0x3b0
  ? process_one_work+0x410/0x410
  kthread+0xe1/0x110
  ? kthread_complete_and_exit+0x20/0x20
  ret_from_fork+0x1f/0x30
  &lt;/TASK&gt;

Cc: stable@vger.kernel.org
Fixes: c1edc86472fc ("rtw88: add ieee80211:sta_rc_update ops")
Reported-by: Larry Finger &lt;Larry.Finger@lwfinger.net&gt;
Link: https://lore.kernel.org/linux-wireless/f1e31e8e-f84e-3791-50fb-663a83c5c6e9@lwfinger.net/T/#t
Signed-off-by: Ping-Ke Shih &lt;pkshih@realtek.com&gt;
Tested-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/20230508085429.46653-1-pkshih@realtek.com
</content>
</entry>
<entry>
<title>wifi: rtw89: 8852b: adjust quota to avoid SER L1 caused by access null page</title>
<updated>2023-05-12T08:22:21+00:00</updated>
<author>
<name>Ping-Ke Shih</name>
<email>pkshih@realtek.com</email>
</author>
<published>2023-04-26T03:47:37+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=c0426c446d92023d344131d01d929bc25db7a24e'/>
<id>urn:sha1:c0426c446d92023d344131d01d929bc25db7a24e</id>
<content type='text'>
Though SER can recover this case, traffic can get stuck for a while. Fix it
by adjusting page quota to avoid hardware access null page of CMAC/DMAC.

Fixes: a1cb097168fa ("wifi: rtw89: 8852b: configure DLE mem")
Fixes: 3e870b481733 ("wifi: rtw89: 8852b: add HFC quota arrays")
Cc: stable@vger.kernel.org
Tested-by: Larry Finger &lt;Larry.Finger@lwfinger.net&gt;
Link: https://github.com/lwfinger/rtw89/issues/226#issuecomment-1520776761
Link: https://github.com/lwfinger/rtw89/issues/240
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/20230426034737.24870-1-pkshih@realtek.com
</content>
</entry>
<entry>
<title>wifi: rtw88: Update spelling in main.h</title>
<updated>2023-04-20T12:39:57+00:00</updated>
<author>
<name>Simon Horman</name>
<email>horms@kernel.org</email>
</author>
<published>2023-04-18T11:29:22+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=6c6d62ae8271bd4b55dd2ba4b7ed552162823880'/>
<id>urn:sha1:6c6d62ae8271bd4b55dd2ba4b7ed552162823880</id>
<content type='text'>
Update spelling in comments in main.h

Found by inspection.

Signed-off-by: Simon Horman &lt;horms@kernel.org&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/20230418-rtw88-starspell-v1-1-70e52a23979b@kernel.org
</content>
</entry>
<entry>
<title>wifi: rtl8xxxu: Simplify setting the initial gain</title>
<updated>2023-04-20T12:35:38+00:00</updated>
<author>
<name>Bitterblue Smith</name>
<email>rtl8821cerfe2@gmail.com</email>
</author>
<published>2023-04-17T17:08:20+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=c8bc3760277965c8eaa90155acea2b16215ebb8a'/>
<id>urn:sha1:c8bc3760277965c8eaa90155acea2b16215ebb8a</id>
<content type='text'>
The goal of writing 0x6954341e / 0x6955341e to REG_OFDM0_XA_AGC_CORE1
appears to be setting the initial gain, which is stored in bits 0..6.
Bits 7..31 are the same as what the phy init tables write.

Modify only bits 0..6 so that we don't have to care about the values
of the others. This way we don't have to add another "else if" for the
RTL8192FU.

Why we need to change the initial gain from the default 0x20 to 0x1e?
Not sure. Some of the vendor drivers change it to 0x1e before scanning
and then restore it to the original value after.

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/cf91ca69-70e3-4c20-c0b1-e59d452356a1@gmail.com
</content>
</entry>
</feed>
