kernel/drivers/net/wireless/realtek/rtw88, branch linux-6.2.y

wifi: rtw88: rtw8821c: Fix rfe_option field width

2023-05-11T14:11:34Z

commit 14705f969d98187a1cc2682e0c9bd2e230b8098f upstream. On my RTW8821CU chipset rfe_option reads as 0x22. Looking at the vendor driver suggests that the field width of rfe_option is 5 bit, so rfe_option should be masked with 0x1f. Without this the rfe_option comparisons with 2 further down the driver evaluate as false when they should really evaluate as true. The effect is that 2G channels do not work. rfe_option is also used as an array index into rtw8821c_rfe_defs[]. rtw8821c_rfe_defs[34] (0x22) was added as part of adding USB support, likely because rfe_option reads as 0x22. As this now becomes 0x2, rtw8821c_rfe_defs[34] is no longer used and can be removed. Note that this might not be the whole truth. In the vendor driver there are indeed places where the unmasked rfe_option value is used. However, the driver has several places where rfe_option is tested with the pattern if (rfe_option == 2 || rfe_option == 0x22) or if (rfe_option == 4 || rfe_option == 0x24), so that rfe_option BIT(5) has no influence on the code path taken. We therefore mask BIT(5) out from rfe_option entirely until this assumption is proved wrong by some chip variant we do not know yet. Signed-off-by: Sascha Hauer Tested-by: Alexandru gagniuc Tested-by: Larry Finger Tested-by: ValdikSS Cc: stable@vger.kernel.org Reviewed-by: Ping-Ke Shih Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20230417140358.2240429-3-s.hauer@pengutronix.de Signed-off-by: Greg Kroah-Hartman

wifi: rtw88: mac: Return the original error from rtw_mac_power_switch()

2023-05-11T14:11:08Z

[ Upstream commit 15c8e267dfa62f207ee1db666c822324e3362b84 ] rtw_mac_power_switch() calls rtw_pwr_seq_parser() which can return -EINVAL, -EBUSY or 0. Propagate the original error code instead of unconditionally returning -EINVAL in case of an error. Fixes: e3037485c68e ("rtw88: new Realtek 802.11ac driver") Signed-off-by: Martin Blumenstingl Reviewed-by: Ping-Ke Shih Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20230226221004.138331-3-martin.blumenstingl@googlemail.com Signed-off-by: Sasha Levin

wifi: rtw88: mac: Return the original error from rtw_pwr_seq_parser()

2023-05-11T14:11:08Z

[ Upstream commit b7ed9fa2cb76ca7a3c3cd4a6d35748fe1fbda9f6 ] rtw_pwr_seq_parser() calls rtw_sub_pwr_seq_parser() which can either return -EBUSY, -EINVAL or 0. Propagate the original error code instead of unconditionally returning -EBUSY in case of an error. Fixes: e3037485c68e ("rtw88: new Realtek 802.11ac driver") Signed-off-by: Martin Blumenstingl Reviewed-by: Ping-Ke Shih Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20230226221004.138331-2-martin.blumenstingl@googlemail.com Signed-off-by: Sasha Levin

wifi: rtw88: usb: fix priority queue to endpoint mapping

2023-05-11T14:10:49Z

commit a6f187f92bcc2b17821538b4a11d61764e68b091 upstream. The RTW88 chipsets have four different priority queues in hardware. For the USB type chipsets the packets destined for a specific priority queue must be sent through the endpoint corresponding to the queue. This was not fully understood when porting from the RTW88 USB out of tree driver and thus violated. This patch implements the qsel to endpoint mapping as in get_usb_bulkout_id_88xx() in the downstream driver. Without this the driver often issues "timed out to flush queue 3" warnings and often TX stalls completely. Signed-off-by: Sascha Hauer Tested-by: ValdikSS Tested-by: Alexandru gagniuc Tested-by: Larry Finger Cc: stable@vger.kernel.org Reviewed-by: Ping-Ke Shih Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20230417140358.2240429-2-s.hauer@pengutronix.de Signed-off-by: Greg Kroah-Hartman

wifi: rtw88: use RTW_FLAG_POWERON flag to prevent to power on/off twice

2023-03-10T08:29:43Z

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 Link: https://bugzilla.kernel.org/show_bug.cgi?id=217016 Fixes: 6bf3a083407b ("wifi: rtw88: add flag check before enter or leave IPS") Cc: Signed-off-by: Ping-Ke Shih Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20230216053633.20366-1-pkshih@realtek.com Signed-off-by: Greg Kroah-Hartman

wifi: rtw88: Use non-atomic sta iterator in rtw_ra_mask_info_update()

2023-03-10T08:28:08Z

[ Upstream commit 2931978cd74f4a643deeea5b211523001d95aa44 ] USB and (upcoming) SDIO support may sleep in the read/write handlers. Use non-atomic rtw_iterate_stas() in rtw_ra_mask_info_update() because the iterator function rtw_ra_mask_info_update_iter() needs to read and write registers from within rtw_update_sta_info(). Using the non-atomic iterator ensures that we can sleep during USB and SDIO register reads and writes. This fixes "scheduling while atomic" or "Voluntary context switch within RCU read-side critical section!" warnings as seen by SDIO card users (but it also affects USB cards). Fixes: 78d5bf925f30 ("wifi: rtw88: iterate over vif/sta list non-atomically") Suggested-by: Ping-Ke Shih Reviewed-by: Ping-Ke Shih Tested-by: Sascha Hauer Signed-off-by: Martin Blumenstingl Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20230108211324.442823-4-martin.blumenstingl@googlemail.com Signed-off-by: Sasha Levin

wifi: rtw88: Use rtw_iterate_vifs() for rtw_vif_watch_dog_iter()

2023-03-10T08:28:08Z

[ Upstream commit 313f6dc7c5ed723d0c5691553eff4c0090f16bb8 ] USB and (upcoming) SDIO support may sleep in the read/write handlers. Make rtw_watch_dog_work() use rtw_iterate_vifs() to prevent "scheduling while atomic" or "Voluntary context switch within RCU read-side critical section!" warnings when accessing the registers using an SDIO card (which is where this issue has been spotted in the real world but it also affects USB cards). Fixes: 78d5bf925f30 ("wifi: rtw88: iterate over vif/sta list non-atomically") Suggested-by: Ping-Ke Shih Reviewed-by: Ping-Ke Shih Tested-by: Sascha Hauer Signed-off-by: Martin Blumenstingl Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20230108211324.442823-3-martin.blumenstingl@googlemail.com Signed-off-by: Sasha Levin

wifi: rtw88: usb: drop now unnecessary URB size check

2023-03-03T10:56:17Z

commit 462c8db6a01160836c68e262d25566f2447148d9 upstream. Now that we send URBs with the URB_ZERO_PACKET flag set we no longer need to make sure that the URB sizes are not multiple of the bulkout_size. Drop the check. Signed-off-by: Sascha Hauer Reviewed-by: Ping-Ke Shih Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20230210111632.1985205-4-s.hauer@pengutronix.de Signed-off-by: Greg Kroah-Hartman

wifi: rtw88: usb: send Zero length packets if necessary

2023-03-03T10:56:17Z

commit 07ce9fa6ab0e5e4cb5516a1f7c754ab2758fe5cd upstream. Zero length packets are necessary when sending URBs with size multiple of bulkout_size, otherwise the hardware just stalls. Fixes: a82dfd33d1237 ("wifi: rtw88: Add common USB chip support") Signed-off-by: Sascha Hauer Reviewed-by: Ping-Ke Shih Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20230210111632.1985205-3-s.hauer@pengutronix.de Signed-off-by: Greg Kroah-Hartman

wifi: rtw88: usb: Set qsel correctly

2023-03-03T10:56:17Z

commit 7869b834fb07c79933229840c98b02bbb7bd0d75 upstream. We have to extract qsel from the skb before doing skb_push() on it, otherwise qsel will always be 0. Fixes: a82dfd33d1237 ("wifi: rtw88: Add common USB chip support") Signed-off-by: Sascha Hauer Reviewed-by: Ping-Ke Shih Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20230210111632.1985205-2-s.hauer@pengutronix.de Signed-off-by: Greg Kroah-Hartman