Re: [PATCH v4 3/6] wifi: rtw88: 8723b: add the RTL8723B chip driver

[Luka Gejak]

September 29, 2026 at 13:28, "Bitterblue Smith" <rtl8821cerfe2@xxxxxxxxx mailto:rtl8821cerfe2@xxxxxxxxx?to=%22Bitterblue%20Smith%22%20%3Crtl8821cerfe2%40gmail.com%3E > wrote:

> 
> On 29/09/2026 13:10, Luka Gejak wrote:
> 
>> 
>> 	static void rtw8723b_lck(struct rtw_dev *rtwdev)
>> 	{
>> 		...
>> 		rtw_write_rf(rtwdev, RF_PATH_A, 0xb0, RFREG_MASK, 0xdfbe0);
>> 		rtw_write_rf(rtwdev, RF_PATH_A, RF_CFGCH, MASK12BITS, lc_cal | BIT_LCK);
>> 		...
>> 		rtw_write_rf(rtwdev, RF_PATH_A, 0xb0, RFREG_MASK, 0xdffe0);
>> 	}
>
> Why drop this function? You don't know what RF_SYN_PFD is for.
> Maybe it's required every time it does LC calibration?

That is rtw8723b_lck(). You are right about the pair, and I had it
backwards. The vendor writes it inside the calibration itself, in
_phy_lc_calibrate_8723b(), which is what halrf_lck_trigger() calls for
this chip, at init and from the power tracking: 0xDFBE0 on RF reg 0xB0
before the LCK trigger and 0xDFFE0 after it. rtw8723x_lck() does not
touch 0xB0, so every calibration after the first one ran with the LDO
off.

The pair is back, and it is the whole function now:

	static void rtw8723b_lck(struct rtw_dev *rtwdev)
	{
		rtw_write_rf(rtwdev, RF_PATH_A, RF_SYN_PFD, RFREG_MASK, 0xdfbe0);

		rtw8723x_lck(rtwdev);

		rtw_write_rf(rtwdev, RF_PATH_A, RF_SYN_PFD, RFREG_MASK, 0xdffe0);
	}

The RF_MODE standby pair stays gone, it only runs in the continuous TX
branch of the vendor. On the card RF_SYN_PFD reads 0xdfbe0 at the LCK
now and 0xdffe0 before, and the LCK completes in both cases.

>> 	rtw8723b_reassert_rx_path(rtwdev);
>>
>> 	if (rtw_is_8723bs(rtwdev)) {
>> 		...
>> 		rtw_write_rf(rtwdev, RF_PATH_A, RF_WLINT, RFREG_MASK,
>> 			           0x0780);
>> 	}
>
> So the driver doesn't work if you delete this part?

It does, and I removed it, both the helper and the block. Its own record
is against it too: four of the five registers it checks already held
the value it was about to write, and the RF_WLINT write it depends on
did not take effect at the time. The stall it was added for was the
firmware dropping unicast management frames, so it can safely go out.

>> 	iqk:
>> 	if (do_iqk)
>> 		rtw8723b_phy_calibration(rtwdev);
>
> Different chips can have different needs...

You are right, and the vendor says it outright. Its power tracking
excludes this chip from the IQK rerun, and the LCK just above it is not
excluded, so the chip now redoes the LCK on a drift and leaves the IQK
alone. I forced iqk_threshold to 1 to exercise it: the LCK ran, no IQK,
link stayed up.

>> 	/* REG_CSRATIO does not exist on this chip generation. */
>> 	.cck_pd_set		= NULL,
>
> A better idea: move rtw88xxa_phy_cck_pd_set() to phy.c and don't depend
> on rtw88_88xxa. That can be a separate patch, of course.

Done, and it took the other two calls with it. It is
rtw_phy_cck_pd_set() in phy.c now, and the adaptive control and EDCA
init are rtw_mac_init_* in mac.c, so RTW88_8723B no longer selects
RTW88_88XXA. rtw88_8723b.ko depends on rtw88_core and rtw88_8723x only,
the same two modules as rtw8723d and rtw8703b, and the patch is the
first of the series.

Best regards,
Luka Gejak