wifi: rtw88: usb: Further limit the TX aggregation

Currently the number of frames sent to the chip in a single USB Request
Block is limited only by the size of the TX buffer, which is 20 KiB.
Testing reveals that as many as 13 frames get aggregated. This is more
than what any of the chips would like to receive. RTL8822CU, RTL8822BU,
and RTL8821CU want at most 3 frames, and RTL8723DU wants only 1 frame
per URB.

RTL8723DU in particular reliably malfunctions during a speed test. All
traffic seems to stop. Pinging the AP no longer works.

Fix this problem by limiting the number of frames sent to the chip in a
single URB according to what each chip likes.

Also configure RTL8822CU, RTL8822BU, and RTL8821CU to expect 3 frames
per URB.

RTL8703B may or may not be found in USB devices. Declare that it wants
only 1 frame per URB, just in case.

Tested with RTL8723DU and RTL8811CU.

Cc: stable@vger.kernel.org
Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com>
---
 drivers/net/wireless/realtek/rtw88/mac.c      | 12 ++++++++++++
 drivers/net/wireless/realtek/rtw88/main.h     |  2 ++
 drivers/net/wireless/realtek/rtw88/reg.h      |  1 +
 drivers/net/wireless/realtek/rtw88/rtw8703b.c |  1 +
 drivers/net/wireless/realtek/rtw88/rtw8723d.c |  1 +
 drivers/net/wireless/realtek/rtw88/rtw8821c.c |  1 +
 drivers/net/wireless/realtek/rtw88/rtw8822b.c |  1 +
 drivers/net/wireless/realtek/rtw88/rtw8822c.c |  1 +
 drivers/net/wireless/realtek/rtw88/usb.c      |  4 +++-
 9 files changed, 23 insertions(+), 1 deletion(-)

Bitterblue Smith <rtl8821cerfe2@gmail.com> wrote:
> @@ -2065,25 +2066,26 @@ const struct rtw_chip_info rtw8703b_hw_spec = {
>         .bt_rssi_type = COEX_BTRSSI_RATIO,
>         .ant_isolation = 15,
>         .rssi_tolerance = 2,
> -       .bt_rssi_step = bt_rssi_step_8703b,
> -       .wl_rssi_step = wl_rssi_step_8703b,
>         /* sant -> shared antenna, nsant -> non-shared antenna
>          * Not sure if 8703b versions with non-shard antenna even exist.
>          */
>         .table_sant_num = ARRAY_SIZE(table_sant_8703b),
> -       .table_sant = table_sant_8703b,

Not sure why you move array and array size apart. 
No need to churn this as well as other similar stuffs. 

This patch can only change things required by what subject mention. Align these
fields by another patch, or do it later. Both are fine to me. 

>         .table_nsant_num = 0,
> -       .table_nsant = NULL,
>         .tdma_sant_num = ARRAY_SIZE(tdma_sant_8703b),
> -       .tdma_sant = tdma_sant_8703b,
>         .tdma_nsant_num = 0,
> -       .tdma_nsant = NULL,
> -       .wl_rf_para_num = ARRAY_SIZE(rf_para_tx_8703b),
> -       .wl_rf_para_tx = rf_para_tx_8703b,
> -       .wl_rf_para_rx = rf_para_rx_8703b,
>         .bt_afh_span_bw20 = 0x20,
>         .bt_afh_span_bw40 = 0x30,
>         .afh_5g_num = ARRAY_SIZE(afh_5g_8703b),
> +       .wl_rf_para_num = ARRAY_SIZE(rf_para_tx_8703b),
> +       .coex_info_hw_regs_num = 0,
> +       .bt_rssi_step = bt_rssi_step_8703b,
> +       .wl_rssi_step = wl_rssi_step_8703b,
> +       .table_nsant = NULL,
> +       .table_sant = table_sant_8703b,
> +       .tdma_sant = tdma_sant_8703b,
> +       .tdma_nsant = NULL,
> +       .wl_rf_para_tx = rf_para_tx_8703b,
> +       .wl_rf_para_rx = rf_para_rx_8703b,
>         .afh_5g = afh_5g_8703b,
>         /* REG_BTG_SEL doesn't seem to have a counterpart in the
>          * vendor driver. Mathematically it's REG_PAD_CTRL1 + 3.
> @@ -2096,7 +2098,6 @@ const struct rtw_chip_info rtw8703b_hw_spec = {
>         /* These registers are used to read (and print) from if
>          * CONFIG_RTW88_DEBUGFS is enabled.
>          */
> -       .coex_info_hw_regs_num = 0,
>         .coex_info_hw_regs = NULL,
>  };
>  EXPORT_SYMBOL(rtw8703b_hw_spec);

On 11/06/2024 06:26, Ping-Ke Shih wrote:
> Bitterblue Smith <rtl8821cerfe2@gmail.com> wrote:
>> @@ -2065,25 +2066,26 @@ const struct rtw_chip_info rtw8703b_hw_spec = {
>>         .bt_rssi_type = COEX_BTRSSI_RATIO,
>>         .ant_isolation = 15,
>>         .rssi_tolerance = 2,
>> -       .bt_rssi_step = bt_rssi_step_8703b,
>> -       .wl_rssi_step = wl_rssi_step_8703b,
>>         /* sant -> shared antenna, nsant -> non-shared antenna
>>          * Not sure if 8703b versions with non-shard antenna even exist.
>>          */
>>         .table_sant_num = ARRAY_SIZE(table_sant_8703b),
>> -       .table_sant = table_sant_8703b,
> 
> Not sure why you move array and array size apart. 
> No need to churn this as well as other similar stuffs. 
> 

I thought you wanted the members initialised in the same order
they appear in struct rtw_chip_info in main.h. Maybe I misunderstood.

> This patch can only change things required by what subject mention. Align these
> fields by another patch, or do it later. Both are fine to me. 
> 

Ah, it should be done in a different patch, okay.

I'm still not sure what you meant here:

>> diff --git a/drivers/net/wireless/realtek/rtw88/main.h b/drivers/net/wireless/realtek/rtw88/main.h
>> index 49894331f7b4..49a3fd4fb7dc 100644
>> --- a/drivers/net/wireless/realtek/rtw88/main.h
>> +++ b/drivers/net/wireless/realtek/rtw88/main.h
>> @@ -1197,6 +1197,8 @@ struct rtw_chip_info {
>>         u16 fw_fifo_addr[RTW_FW_FIFO_MAX];
>>         const struct rtw_fwcd_segs *fwcd_segs;
>>
>> +       u8 usb_tx_agg_desc_num;
>> +
>
> Please keep order of field and instance declaration, like rtw8703b_hw_spec.

and here:

>>  #define REG_DWBCN0_CTRL                0x0208
>>  #define BIT_BCN_VALID          BIT(16)
>>  #define REG_TXDMA_OFFSET_CHK   0x020C
>> diff --git a/drivers/net/wireless/realtek/rtw88/rtw8703b.c
>> b/drivers/net/wireless/realtek/rtw88/rtw8703b.c
>> index 8919f9e11f03..222608de33cd 100644
>> --- a/drivers/net/wireless/realtek/rtw88/rtw8703b.c
>> +++ b/drivers/net/wireless/realtek/rtw88/rtw8703b.c
>> @@ -2013,6 +2013,7 @@ const struct rtw_chip_info rtw8703b_hw_spec = {
>>         .tx_stbc = false,
>>         .max_power_index = 0x3f,
>>         .ampdu_density = IEEE80211_HT_MPDU_DENSITY_16,
>> +       .usb_tx_agg_desc_num = 1, /* Not sure if this chip has USB interface */
>
> The position to declare this field is very different from others. 
> 
> Not sure when we messed up the order, but please don't feel free to add one,
> keep the order.

Bitterblue Smith <rtl8821cerfe2@gmail.com> wrote:
> On 11/06/2024 06:26, Ping-Ke Shih wrote:
> > Bitterblue Smith <rtl8821cerfe2@gmail.com> wrote:
> >> @@ -2065,25 +2066,26 @@ const struct rtw_chip_info rtw8703b_hw_spec = {
> >>         .bt_rssi_type = COEX_BTRSSI_RATIO,
> >>         .ant_isolation = 15,
> >>         .rssi_tolerance = 2,
> >> -       .bt_rssi_step = bt_rssi_step_8703b,
> >> -       .wl_rssi_step = wl_rssi_step_8703b,
> >>         /* sant -> shared antenna, nsant -> non-shared antenna
> >>          * Not sure if 8703b versions with non-shard antenna even exist.
> >>          */
> >>         .table_sant_num = ARRAY_SIZE(table_sant_8703b),
> >> -       .table_sant = table_sant_8703b,
> >
> > Not sure why you move array and array size apart.
> > No need to churn this as well as other similar stuffs.
> >
> 
> I thought you wanted the members initialised in the same order
> they appear in struct rtw_chip_info in main.h. Maybe I misunderstood.

My bad, you didn't misunderstand. I didn't look into definition of
struct rtw_chip_info, which put the same data type together to save some space
because compiler can align fields:

	u8 table_sant_num;
	u8 table_nsant_num;
	u8 tdma_sant_num;
	u8 tdma_nsant_num;
	u8 afh_5g_num;
	u8 wl_rf_para_num;
	u8 coex_info_hw_regs_num;
	const u8 *bt_rssi_step;
	const u8 *wl_rssi_step;
	const struct coex_table_para *table_nsant;
	const struct coex_table_para *table_sant;
	const struct coex_tdma_para *tdma_sant;
	const struct coex_tdma_para *tdma_nsant;
	const struct coex_rf_para *wl_rf_para_tx;
	const struct coex_rf_para *wl_rf_para_rx;
	const struct coex_5g_afh_map *afh_5g;
	const struct rtw_hw_reg *btg_reg;
	const struct rtw_reg_domain *coex_info_hw_regs;

But in this table I would like to treat these as exceptions putting them together,
because each of them are related.
	.table_sant_num = ARRAY_SIZE(table_sant_8703b),
	.table_sant = table_sant_8703b,

Or if members of BT-coexistence part in tables across chips are in the same order,
just keep it as it was.

What do you think?

> 
> > This patch can only change things required by what subject mention. Align these
> > fields by another patch, or do it later. Both are fine to me.
> >
> 
> Ah, it should be done in a different patch, okay.

Yes. One patch is like v1, and the other one just changes the order, no logic change.