Re: wifi: rtw88: 8822cs/bs: Issues migrating RTL8822CS/BS from downstream to upstream driver

[Lucas Tanure]

Hi Ping-Ke,

On Tue, Jun 16, 2026 at 4:30 AM Ping-Ke Shih <pkshih@xxxxxxxxxxx> wrote:
>
> Hi,
>
> Lucas Tanure <lucas.tanure@xxxxxxx> wrote:
> > Hi Ping-Ke,
> >
> > We are bringing up an RTL8822BS / RTL8822CS combo on a Rockchip PX30
> > board (kernel 6.1.118), Wi-Fi over SDIO, BT on the same die over UART
> > via btrtl + hci_h5.
> >
> > We're deliberately migrating off Realtek's out-of-tree SDIO vendor
> > driver to mainline rtw88: the vendor driver hits memory-corruption
> > bugs we've been unable to get support on, and mainline is the better
> > long-term path.
> > That migration leaves us two gaps I'd appreciate your guidance on:
> >
> > 1) Power-parameter tables. Mainline carries the TX-power data as generated
> >    C arrays in rtw88xxc_table.c, while the vendor driver ships the same
> >    data as text files.
> >
> >    The TX-power limits look like this (TXPWR_LMT.txt):
> >
> >        ##  2.4G, 20M, 1T, CCK, //(1M;2M;5.5M;11M)
> >        ##  START
> >        ##  #3#  FCC  ETSI  MKK
> >        CH01  16  15  15
> >        CH02  16  15  15
> >        ##  END
>
> The tool from .txt to C arrays for vendor driver is not maintained by my team,
> but I think it isn't too hard to use AI tool to convert the format.

If Realtek has an internal .txt -> C conversion tool, could you share it?
Otherwise, could you put us in contact with the team that can verify
our converted tables?

>
> The C array from vendor driver to rtw88 struct is also a simple conversion
> you can use AI to assist this.
>
> If you have traced rtw88, the struct for TX power limit is:
>
> struct rtw_txpwr_lmt_cfg_pair {
>         u8 regd;
>         u8 band;
>         u8 bw;
>         u8 rs;
>         u8 ch;
>         s8 txpwr_lmt;
> };
>
> >
> >    and the power-by-rate like this (PHY_REG_PG.txt):
> >
> >        #[2.4G][A]#
> >        [1Tx] 0xc20  0xffffffff  18 19 19 19  // {11M 5.5M 2M 1M}
> >        [1Tx] 0xc24  0xffffffff  18 18 18 18  // {18M 12M 9M 6M}
>
> TX power by rate is:
>
> struct rtw_phy_pg_cfg_pair {
>         u32 band;
>         u32 rf_path;
>         u32 tx_num;
>         u32 addr;
>         u32 bitmask;
>         u32 data;
> };
>
> >
> >    Is there any way to convert these .TXT files into the C tables? It
> > seems the vendor driver and the mainline driver power configuration
> > don't have anything in common.
>
> The purpose is different. The .TXT is from human point of view to be easier
> to fill calibration data one by one. The design of C arrays is to look up table
> quickly (it isn't so quickly though).

I used Claude, and it converted our vendor TXPWR_LMT.txt /
PHY_REG_PG.txt into the rtw88 C arrays.
Here is exactly how Claude did it - please tell us if any step is wrong.

Row mapping (one TXPWR_LMT.txt line -> rtw_txpwr_lmt_cfg_pair rows):
  header "## 2.4G, 20M, 1T, CCK"  +  "CH01  16  15  15"   (columns FCC ETSI MKK)
    ->  { 0, 0, 0, 0, 1, 64 }    FCC  (regd 0)
        { 2, 0, 0, 0, 1, 60 }    ETSI (regd 2)
        { 1, 0, 0, 0, 1, 60 }    MKK  (regd 1)
  One line -> 3 rows (one per regulatory column). Fields {regd, band,
bw, rs, ch,
  value}: regd FCC/MKK/ETSI = 0/1/2; band/bw/rs come from the header;
value = dBm*U.

Unit (value = real_dBm * U):
  8822c, U=4 (max_power_index 0x7f):
      bb_pg 0xc20 = 0x484c5054 = {18,19,20,21}      (0x48=72=18*4)
      txpwr_lmt ETSI/CCK/ch1 = 60 = 15 dBm
  8822b, U=2 (max_power_index 0x3f):
      txpwr_lmt FCC/CCK/ch1 = 32 = 16 dBm
  Both equal our vendor .txt (real dBm), so txpwr_lmt = dBm * U and
  bb_pg byte = codeword * U (packed high->low).

Is this correct?

>
> >
> > 2) Is there an upstream (linux-firmware) RTL8822BS firmware that
> > supports the UART transport (rtl_bt/rtl8822bs_fw.bin + config), or
> > does the 8822BS firmware still have to come from the vendor BSP?
>
> Currently, no.
>
> >    Is there a problem using vendor firmware (not released at
> > linux-firmware) with the mainline driver?
>
> For BT part, I think it can work. But to work with WiFi, it needs
> BT-coexistence implemented in WiFi driver to support UART BT. Unfortunately
> current is only partially support UART BT.
>
> Ping-Ke
>
Thanks,
Lucas