Re: [PATCH rtw-next v8 5/7] wifi: rtw88: 8723b: add the RTL8723B chip driver

[Bitterblue Smith]

On 06/10/2026 16:06, Luka Gejak wrote:
> Add the Realtek RTL8723B 802.11n chip driver: the chip operations, the
> power sequences, the efuse layout, the RF and IQ calibration, and the
> chip specific coexistence handling.
> 
> The RTL8723B chip support is based on the initial work by
> Michael Straube <straube.linux@xxxxxxxxx>.
> Link: https://github.com/mistraube/rtw88/tree/rtl8723bs
> 
> Co-developed-by: Michael Straube <straube.linux@xxxxxxxxx>
> Signed-off-by: Michael Straube <straube.linux@xxxxxxxxx>
> Signed-off-by: Luka Gejak <luka.gejak@xxxxxxxxx>
> Reviewed-by: Bitterblue Smith <rtl8821cerfe2@xxxxxxxxx>
> ---
>  drivers/net/wireless/realtek/rtw88/rtw8723b.c | 2534 +++++++++++++++++
>  drivers/net/wireless/realtek/rtw88/rtw8723b.h |   14 +
>  2 files changed, 2548 insertions(+)
>  create mode 100644 drivers/net/wireless/realtek/rtw88/rtw8723b.c
>  create mode 100644 drivers/net/wireless/realtek/rtw88/rtw8723b.h
> 
> diff --git a/drivers/net/wireless/realtek/rtw88/rtw8723b.c b/drivers/net/wireless/realtek/rtw88/rtw8723b.c
> new file mode 100644
> index 000000000000..8bb9c03d769c
> --- /dev/null
> +++ b/drivers/net/wireless/realtek/rtw88/rtw8723b.c

[...]

> +static int rtw8723b_read_efuse(struct rtw_dev *rtwdev, u8 *log_map)
> +{
> +	struct rtw_efuse *efuse = &rtwdev->efuse;
> +	int ret;
> +
> +	ret = rtw8723x_read_efuse(rtwdev, log_map);
> +	if (ret)
> +		return ret;
> +
> +	/*
> +	 * Report a power track type this driver does not implement once,
> +	 * here, rather than on every two second pwr_track() tick.
> +	 */
> +	if (efuse->power_track_type != 0)
> +		rtw_warn(rtwdev, "unsupported power track type\n");
> +
> +	/*
> +	 * No firmware hardware feature report exists, so fill the hardware
> +	 * capability here; a zero stream count kills the HT MCS set.
> +	 */
> +	efuse->hw_cap.nss = max_t(u8, rtwdev->hal.rf_path_num, 1);

Another thing I noticed too late: this chip always supports only one
spatial stream. rf_path_num happens to be 1, so no harm done.

> +	efuse->hw_cap.ant_num = efuse->hw_cap.nss;
> +	efuse->hw_cap.bw = BIT(RTW_CHANNEL_WIDTH_20) |
> +			   BIT(RTW_CHANNEL_WIDTH_40);
> +
> +	return 0;
> +}