Bitterblue Smith <rtl8821cerfe2@xxxxxxxxx> wrote: >On 29/01/2025 04:43, Ping-Ke Shih wrote: >> Bitterblue Smith <rtl8821cerfe2@xxxxxxxxx> wrote: >>> On 28/01/2025 07:52, Ping-Ke Shih wrote: >>>> Bitterblue Smith <rtl8821cerfe2@xxxxxxxxx> wrote: >>>>> On 27/01/2025 08:36, Ping-Ke Shih wrote: >>>>>> Bitterblue Smith <rtl8821cerfe2@xxxxxxxxx> wrote: >>>>>>> The existing code is suitable for chips with up to 2 spatial streams. >>>>>>> Inform the firmware about the rates it's allowed to use when >>>>>>> transmitting 3 spatial streams. >>>>>>> >>>>>>> Signed-off-by: Bitterblue Smith <rtl8821cerfe2@xxxxxxxxx> >>>>>>> --- >>>>>>> drivers/net/wireless/realtek/rtw88/fw.c | 14 ++++++++++++++ >>>>>>> drivers/net/wireless/realtek/rtw88/fw.h | 1 + >>>>>>> 2 files changed, 15 insertions(+) >>>>>>> >>>>>>> diff --git a/drivers/net/wireless/realtek/rtw88/fw.c b/drivers/net/wireless/realtek/rtw88/fw.c >>>>>>> index 02389b7c6876..0ca1b139110d 100644 >>>>>>> --- a/drivers/net/wireless/realtek/rtw88/fw.c >>>>>>> +++ b/drivers/net/wireless/realtek/rtw88/fw.c >>>>>>> @@ -735,6 +735,7 @@ void rtw_fw_send_ra_info(struct rtw_dev *rtwdev, struct rtw_sta_info *si, >>>>>>> { >>>>>>> u8 h2c_pkt[H2C_PKT_SIZE] = {0}; >>>>>>> bool disable_pt = true; >>>>>>> + u32 mask_hi; >>>>>>> >>>>>>> SET_H2C_CMD_ID_CLASS(h2c_pkt, H2C_CMD_RA_INFO); >>>>>>> >>>>>>> @@ -755,6 +756,19 @@ void rtw_fw_send_ra_info(struct rtw_dev *rtwdev, struct rtw_sta_info *si, >>>>>>> si->init_ra_lv = 0; >>>>>>> >>>>>>> rtw_fw_send_h2c_command(rtwdev, h2c_pkt); >>>>>>> + >>>>>>> + if (rtwdev->chip->rf_tbl[RF_PATH_C]) { >>>>>> >>>>>> Using `efuse->hw_cap.nss >= 3` would be consistent with latter patch. >>>>>> >>>>> >>>>> I would like that, but nss is 2 when RTL8814AU is in USB 2 mode. >>>>> I assume this is to keep the current draw under the 500 mA limit >>>>> of USB 2. >>>>> >>>>> What about rtwdev->hal.rf_path_num >= 3 ? I don't remember why >>>>> I didn't do that. >>>> >>>> I think `rtwdev->hal.rf_path_num >= 3` is suitable to initialize/configure >>>> hardware registers, because no matter USB 2 or 3 mode should be the same. >>>> >>>> For this case (RA info), this is related to protocol, so I feel >>>> `efuse->hw_cap.nss >= 3` is suitable, but I have not seen a patch to declare >>>> supported NSS in register_hw(), or I missed it? Or, without RA_INFO_HI, >>>> it gets abnormal rate to RTL8814AU in your test? >>>> >>> >>> You didn't miss it, that will be in part 3. You can see the code here: >>> >>> https://github.com/lwfinger/rtw88/blob/21a3fa7ec11a0cbb3be14145f45cdca35c3d3217/rtw8814a.c#L82 >>> >> >> I feel we should clearly define the meaning. What I thought for 8814AU are: >> - hal->rf_type: hardware capability. Should be RF_3T3R no matter USB 2 or 3. >> - hal->antenna_tx: the antenna for current TX. Can be 2 antenna. >> - hal->antenna_rx: the antenna for current RX. Can be 2 antenna. >> - efuse->hw_cap.nss: read from efuse. So this will be 3SS for USB 2/3. >> If you have better defnitiion, please share your ideas. >> > > If efuse->hw_cap.nss is always 3, how to limit the spatial streams > to 2 in USB 2 mode? That's a proposal only, because I felt `efuse->hw_cap.nss` read from efuse should be persistent, but it is fine to define desired meaning. I would like to confirm if USB devices will not switch USB 2/3 mode after USB probe? If so, `efuse->hw_cap.nss` is also a kind of persistent. Then, using `efuse->hw_cap.nss` seems fine.