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

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

[Lucas Tanure]

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

   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}

   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.

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?
   Is there a problem using vendor firmware (not released at
linux-firmware) with the mainline driver?

Thanks,
Lucas Tanure
Neat

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

[Ping-Ke Shih]

Hi,

Lucas Tanure <lucas.tanure@neat.no> 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. 

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

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

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@realtek.com> wrote:
>
> Hi,
>
> Lucas Tanure <lucas.tanure@neat.no> 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

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

[Ping-Ke Shih]

Lucas Tanure <lucas.tanure@neat.no> wrote:
> Hi Ping-Ke,
> 
> On Tue, Jun 16, 2026 at 4:30 AM Ping-Ke Shih <pkshih@realtek.com> wrote:
> >
> > Hi,
> >
> > Lucas Tanure <lucas.tanure@neat.no> 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 better way is to check how vendor driver convert .txt into driver, and
what it writes to registers.

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

I don't remember the exact units these chips use. By the rtw88 driver,
  .txgi_factor = 1 / 2 for RTL8822B and RTL8822C
So I think the units are correct. 

For TX power unit, I remember it is not dBm, but with an offset, so you can
find function names of driver calling *_power_index_*. But treating it in
unit of dBm would be easier to understand.


I think the built-in tables in driver are very similar to the tables you
converted from .txt. I'd suggest using AI to compare their difference as
a validation -- the difference (TX power in dB) will be small (about 1
or 2 dB. I guess).