* [PATCH 0/2] wifi: rtw88: 8703b: repair the card-disable transition
@ 2026-09-11 15:38 Cristian Deluxe
2026-09-11 15:38 ` [PATCH 1/2] wifi: rtw88: 8703b: complete the card-disable to card-emulation transition Cristian Deluxe
2026-09-11 15:38 ` [PATCH 2/2] wifi: rtw88: 8703b: stop the PCIe DMA write reaching SDIO Cristian Deluxe
0 siblings, 2 replies; 5+ messages in thread
From: Cristian Deluxe @ 2026-09-11 15:38 UTC (permalink / raw)
To: Ping-Ke Shih; +Cc: linux-wireless, linux-kernel
Two fixes to rtw8703b's power sequence tables, both found by comparing
them against trans_*_8723d and against Realtek's own 8703b sequence
header, and both tested on an RTL8723CS over SDIO.
The first is the one that matters. trans_carddis_to_cardemu_8703b has a
single entry where its sibling has seven, so the SDIO suspend request
and the 12H LDO sleep that trans_cardemu_to_carddis_8703b sets are never
undone. On a board where WL_REG_ON is the host's only reset and the
chip's rail cannot be switched, the part then comes back from every warm
reboot with its MAC unpowered while the SDIO function still enumerates,
and the driver waits forever for power ready. Nothing short of
disconnecting the battery cleared it; the vendor driver recovered it
every time, which is what pointed at the tables.
The second is small: the first entry of trans_act_to_lps_8703b writes to
the PCIe DMA control on every interface, where both 8723d and Realtek's
header restrict it to PCI.
Tested on a Denver TAQ-102 tablet (RK3126C, RTL8723CS on SDIO) against
7.3.0-rc2: recovers a chip left wedged by a previous boot, survives
repeated warm reboots and loader-mode flash cycles, and 35 hours of
continuous association across the pair.
Cristian Deluxe (2):
wifi: rtw88: 8703b: complete the card-disable to card-emulation
transition
wifi: rtw88: 8703b: stop the PCIe DMA write reaching SDIO
drivers/net/wireless/realtek/rtw88/rtw8703b.c | 34 ++++++++++++++++++-
1 file changed, 33 insertions(+), 1 deletion(-)
--
2.51.0
^ permalink raw reply [flat|nested] 5+ messages in thread
* [PATCH 1/2] wifi: rtw88: 8703b: complete the card-disable to card-emulation transition
2026-09-11 15:38 [PATCH 0/2] wifi: rtw88: 8703b: repair the card-disable transition Cristian Deluxe
@ 2026-09-11 15:38 ` Cristian Deluxe
2026-09-13 2:44 ` Ping-Ke Shih
2026-09-11 15:38 ` [PATCH 2/2] wifi: rtw88: 8703b: stop the PCIe DMA write reaching SDIO Cristian Deluxe
1 sibling, 1 reply; 5+ messages in thread
From: Cristian Deluxe @ 2026-09-11 15:38 UTC (permalink / raw)
To: Ping-Ke Shih; +Cc: linux-wireless, linux-kernel
On an RTL8723CS the driver cannot power the MAC on after a warm reboot:
the power-on sequence waits forever for power ready and probe fails.
rtw88_8723cs mmc2:0001:1: failed to poll offset=0x6 mask=0x2 value=0x2
rtw88_8723cs mmc2:0001:1: mac power on failed
trans_carddis_to_cardemu_8703b has a single entry, clearing the hardware
power-down bit. Its sibling trans_carddis_to_cardemu_8723d has six more,
and 8822b and 8822c carry the same SDIO pair: withdraw the SDIO suspend
request on local register 0x86 and wait for the interface to leave the
suspended state, clear the WL suspend bit alongside the power-down bit,
and take the 12H LDO out of sleep mode. The transition is the reverse of
trans_cardemu_to_carddis_8703b, which sets 0x23[4] and asks the
interface to suspend, so with those operations missing neither is ever
undone.
The chip then comes back with the WLAN MAC unpowered while the SDIO
function still enumerates and CMD52 still works, and nothing in the
sequence wakes it. rtw_mac_pre_system_cfg() does not cover it either: it
returns early for 8051 wcpu chips, of which this is one.
It survives a reboot on any board where WL_REG_ON is the only reset the
host has and the chip's rail is not switchable. On the Denver TAQ-102
the pwrseq reset line, the BT enable line, the 32.768 kHz clock and
every switchable PMIC rail were each toggled against a wedged chip and
none of them cleared it, while the vendor driver recovered it every
time.
Take the operations 8723d has and this table lacks. That table's USB-only
and PCI-only entries are left out: this chip has no such variant.
Tested on an RTL8723CS over SDIO: recovers a chip left wedged by a
previous boot, and survives repeated warm reboots and loader-mode flash
cycles.
Signed-off-by: Cristian Deluxe <me@cristiandeluxe.dev>
---
drivers/net/wireless/realtek/rtw88/rtw8703b.c | 33 ++++++++++++++++++-
1 file changed, 32 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/realtek/rtw88/rtw8703b.c b/drivers/net/wireless/realtek/rtw88/rtw8703b.c
index b5e7ae7eb..67bbd70f4 100644
--- a/drivers/net/wireless/realtek/rtw88/rtw8703b.c
+++ b/drivers/net/wireless/realtek/rtw88/rtw8703b.c
@@ -187,11 +187,38 @@ static const struct rtw_pwr_seq_cmd trans_pre_enable_8703b[] = {
};
static const struct rtw_pwr_seq_cmd trans_carddis_to_cardemu_8703b[] = {
+ /* clear WL suspend enable and HW power down enable */
{0x0005,
RTW_PWR_CUT_ALL_MSK,
RTW_PWR_INTF_ALL_MSK,
RTW_PWR_ADDR_MAC,
- RTW_PWR_CMD_WRITE, BIT(7), 0},
+ RTW_PWR_CMD_WRITE, BIT(3) | BIT(7), 0},
+ /* withdraw the SDIO suspend request */
+ {0x0086,
+ RTW_PWR_CUT_ALL_MSK,
+ RTW_PWR_INTF_SDIO_MSK,
+ RTW_PWR_ADDR_SDIO,
+ RTW_PWR_CMD_WRITE, BIT(0), 0},
+ /* and wait for the interface to leave the suspended state */
+ {0x0086,
+ RTW_PWR_CUT_ALL_MSK,
+ RTW_PWR_INTF_SDIO_MSK,
+ RTW_PWR_ADDR_SDIO,
+ RTW_PWR_CMD_POLLING, BIT(1), BIT(1)},
+ /* disable WL suspend */
+ {0x0005,
+ RTW_PWR_CUT_ALL_MSK,
+ RTW_PWR_INTF_ALL_MSK,
+ RTW_PWR_ADDR_MAC,
+ RTW_PWR_CMD_WRITE, BIT(3) | BIT(4), 0},
+ /* take the 12H LDO back out of sleep mode, which the card-disable
+ * transition put it into
+ */
+ {0x0023,
+ RTW_PWR_CUT_ALL_MSK,
+ RTW_PWR_INTF_SDIO_MSK,
+ RTW_PWR_ADDR_MAC,
+ RTW_PWR_CMD_WRITE, BIT(4), 0},
{TRANS_SEQ_END},
};
--
2.51.0
^ permalink raw reply related [flat|nested] 5+ messages in thread
* [PATCH 2/2] wifi: rtw88: 8703b: stop the PCIe DMA write reaching SDIO
2026-09-11 15:38 [PATCH 0/2] wifi: rtw88: 8703b: repair the card-disable transition Cristian Deluxe
2026-09-11 15:38 ` [PATCH 1/2] wifi: rtw88: 8703b: complete the card-disable to card-emulation transition Cristian Deluxe
@ 2026-09-11 15:38 ` Cristian Deluxe
2026-09-13 2:49 ` Ping-Ke Shih
1 sibling, 1 reply; 5+ messages in thread
From: Cristian Deluxe @ 2026-09-11 15:38 UTC (permalink / raw)
To: Ping-Ke Shih; +Cc: linux-wireless, linux-kernel
The first entry of trans_act_to_lps_8703b writes 0xff to MAC register
0x301 on every interface. That register is the PCIe DMA control, and
both trans_act_to_lps_8723d and Realtek's own 8703b sequence header
restrict the same entry to PCI, where it is commented "PCIe DMA stop".
So on an RTL8723CS, which is SDIO only, every transition into low power
poked a PCIe register for no reason. Restrict it the way the sibling
chip and the vendor both do.
Tested on an RTL8723CS over SDIO: the interface goes down and back up,
reassociates and takes an address, and a warm reboot brings Wi-Fi back
with no change in behaviour.
Signed-off-by: Cristian Deluxe <me@cristiandeluxe.dev>
---
drivers/net/wireless/realtek/rtw88/rtw8703b.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/realtek/rtw88/rtw8703b.c b/drivers/net/wireless/realtek/rtw88/rtw8703b.c
--- a/drivers/net/wireless/realtek/rtw88/rtw8703b.c
+++ b/drivers/net/wireless/realtek/rtw88/rtw8703b.c
@@ -412,7 +412,7 @@ static const struct rtw_pwr_seq_cmd trans_act_to_reset_mcu_8703b[] = {
static const struct rtw_pwr_seq_cmd trans_act_to_lps_8703b[] = {
{0x0301,
RTW_PWR_CUT_ALL_MSK,
- RTW_PWR_INTF_ALL_MSK,
+ RTW_PWR_INTF_PCI_MSK,
RTW_PWR_ADDR_MAC,
RTW_PWR_CMD_WRITE, 0xff, 0xff},
{0x0522,
--
2.51.0
^ permalink raw reply [flat|nested] 5+ messages in thread
* RE: [PATCH 1/2] wifi: rtw88: 8703b: complete the card-disable to card-emulation transition
2026-09-11 15:38 ` [PATCH 1/2] wifi: rtw88: 8703b: complete the card-disable to card-emulation transition Cristian Deluxe
@ 2026-09-13 2:44 ` Ping-Ke Shih
0 siblings, 0 replies; 5+ messages in thread
From: Ping-Ke Shih @ 2026-09-13 2:44 UTC (permalink / raw)
To: Cristian Deluxe
Cc: linux-wireless@vger.kernel.org, linux-kernel@vger.kernel.org
Cristian Deluxe <me@cristiandeluxe.dev> wrote:
> Sent: Friday, September 11, 2026 11:38 PM
> On an RTL8723CS the driver cannot power the MAC on after a warm reboot:
> the power-on sequence waits forever for power ready and probe fails.
>
> rtw88_8723cs mmc2:0001:1: failed to poll offset=0x6 mask=0x2 value=0x2
> rtw88_8723cs mmc2:0001:1: mac power on failed
>
> trans_carddis_to_cardemu_8703b has a single entry, clearing the hardware
> power-down bit. Its sibling trans_carddis_to_cardemu_8723d has six more,
> and 8822b and 8822c carry the same SDIO pair: withdraw the SDIO suspend
> request on local register 0x86 and wait for the interface to leave the
> suspended state, clear the WL suspend bit alongside the power-down bit,
> and take the 12H LDO out of sleep mode. The transition is the reverse of
> trans_cardemu_to_carddis_8703b, which sets 0x23[4] and asks the
> interface to suspend, so with those operations missing neither is ever
> undone.
I feel you can just describe you sync the setting from vendor driver.
>
> The chip then comes back with the WLAN MAC unpowered while the SDIO
> function still enumerates and CMD52 still works, and nothing in the
> sequence wakes it. rtw_mac_pre_system_cfg() does not cover it either: it
> returns early for 8051 wcpu chips, of which this is one.
>
> It survives a reboot on any board where WL_REG_ON is the only reset the
> host has and the chip's rail is not switchable. On the Denver TAQ-102
> the pwrseq reset line, the BT enable line, the 32.768 kHz clock and
> every switchable PMIC rail were each toggled against a wedged chip and
> none of them cleared it, while the vendor driver recovered it every
> time.
>
> Take the operations 8723d has and this table lacks. That table's USB-only
> and PCI-only entries are left out: this chip has no such variant.
I see. Others are the same as vendor driver does.
>
> Tested on an RTL8723CS over SDIO: recovers a chip left wedged by a
> previous boot, and survives repeated warm reboots and loader-mode flash
> cycles.
>
> Signed-off-by: Cristian Deluxe <me@cristiandeluxe.dev>
Acked-by: Ping-Ke Shih <pkshih@realtek.com>
^ permalink raw reply [flat|nested] 5+ messages in thread
* RE: [PATCH 2/2] wifi: rtw88: 8703b: stop the PCIe DMA write reaching SDIO
2026-09-11 15:38 ` [PATCH 2/2] wifi: rtw88: 8703b: stop the PCIe DMA write reaching SDIO Cristian Deluxe
@ 2026-09-13 2:49 ` Ping-Ke Shih
0 siblings, 0 replies; 5+ messages in thread
From: Ping-Ke Shih @ 2026-09-13 2:49 UTC (permalink / raw)
To: Cristian Deluxe
Cc: linux-wireless@vger.kernel.org, linux-kernel@vger.kernel.org
Cristian Deluxe <me@cristiandeluxe.dev> wrote:
> The first entry of trans_act_to_lps_8703b writes 0xff to MAC register
> 0x301 on every interface. That register is the PCIe DMA control, and
> both trans_act_to_lps_8723d and Realtek's own 8703b sequence header
> restrict the same entry to PCI, where it is commented "PCIe DMA stop".
>
> So on an RTL8723CS, which is SDIO only, every transition into low power
> poked a PCIe register for no reason. Restrict it the way the sibling
> chip and the vendor both do.
>
> Tested on an RTL8723CS over SDIO: the interface goes down and back up,
> reassociates and takes an address, and a warm reboot brings Wi-Fi back
> with no change in behaviour.
>
> Signed-off-by: Cristian Deluxe <me@cristiandeluxe.dev>
Checked. The settings are identical to vendor driver.
Acked-by: Ping-Ke Shih <pkshih@realtek.com>
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2026-09-13 2:49 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-09-11 15:38 [PATCH 0/2] wifi: rtw88: 8703b: repair the card-disable transition Cristian Deluxe
2026-09-11 15:38 ` [PATCH 1/2] wifi: rtw88: 8703b: complete the card-disable to card-emulation transition Cristian Deluxe
2026-09-13 2:44 ` Ping-Ke Shih
2026-09-11 15:38 ` [PATCH 2/2] wifi: rtw88: 8703b: stop the PCIe DMA write reaching SDIO Cristian Deluxe
2026-09-13 2:49 ` Ping-Ke Shih
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox