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

[Luka Gejak]

October 20, 2026 at 8:08 PM, "Bitterblue Smith" <rtl8821cerfe2@xxxxxxxxx> wrote:


> 
> 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.

You are right, we can just set it directly, no need to derive the value.
I have sent a patch for it.

Best regards,
Luka Gejak