Re: [PATCH rtw-next v4 6/7] wifi: rtw88: 88xxa: correct carrier-frequency offset

[Luka Gejak <luka.gejak@linux.dev>]

Hi Jie Feng,

Thanks for the patch. One comment below.

On November 15, 2026 12:43:32 PM GMT+01:00, Ho Jie Feng <hjf3108@gmail.com>
wrote:

> diff --git a/drivers/net/wireless/realtek/rtw88/rtw88xxa.c b/drivers/net/wireless/realtek/rtw88/rtw88xxa.c
> --- a/drivers/net/wireless/realtek/rtw88/rtw88xxa.c
> +++ b/drivers/net/wireless/realtek/rtw88/rtw88xxa.c

[ ... ]

> @@ -1632,6 +1637,17 @@ void rtw88xxa_query_phy_status(struct rtw_dev *rtwdev, u8 *phy_status,

[ ... ]

> +             rtw_phy_parsing_cfo(rtwdev, pkt_stat);

[ ... ]

> @@ -2020,6 +2036,21 @@ void rtw88xxa_phy_pwrtrack(struct rtw_dev *rtwdev,

[ ... ]

> +     crystal_cap = rtw_phy_cfo_xcap_track(rtwdev, RTW_XCAP_MASK, bt_hold);
> +     if (crystal_cap == cfo->crystal_cap)
> +             return;
> +
> +     cfo->crystal_cap = crystal_cap;
> +     rtw88xxa_set_crystal_cap(rtwdev, crystal_cap);

Could the shared helper discard the samples while sta_cnt != 1? In AP
mode, frames from both clients match the interface BSSID, so these new
calls keep adding their CFO samples. But rtw_phy_cfo_xcap_track() returns
through rtw_phy_cfo_tracking_reset() before clearing the sums or counts.

So if I read it right, when one client leaves, the first adjustment still
includes samples from that client. For example, on each reporting path,
a +12 sample from the remaining client and a -48 sample from the other,
followed by another +12, give an average of -20 kHz. The remaining client
alone gives +30 kHz, so the first correction goes the wrong way.

This was already present on 8822c, and this patch makes it reachable on
88xxa too. I think the fix belongs in rtw_phy_cfo_xcap_track(), before
these new callers start using it. Could the sums and counts be reset
there when there is no single peer to track?

Best regards,
Luka Gejak