Re: [PATCH rtw-next v4 3/7] wifi: rtw88: correctly expose beamformee capabilities

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

Hi Jie Feng,

Thanks for the update. One comment below.

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

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

[ ... ]

> @@ -1624,10 +1625,13 @@ static void rtw_init_vht_cap(struct rtw_dev *rtwdev,

[ ... ]

> +     if (rtw_bf_support && chip->bfer_su_max_num) {
> +             vht_cap->cap |= IEEE80211_VHT_CAP_SU_BEAMFORMEE_CAPABLE;
> +             vht_cap->cap |= rtwdev->hal.bfee_sts_cap <<
> +                             IEEE80211_VHT_CAP_BEAMFORMEE_STS_SHIFT;
> +     }
> +     if (rtw_bf_support && chip->bfer_mu_max_num)
> +             vht_cap->cap |= IEEE80211_VHT_CAP_MU_BEAMFORMEE_CAPABLE;

As far as I can see, this also changes whether support_bf can be enabled
at runtime. It is still writable, but if it is false when the adapter
probes, writing Y later and reconnecting leaves these capabilities clear.
rtw_set_supported_band() only runs from rtw_register_hw(), and the bool
setter does not update the bands.

rtw_bf_assoc() checks these cached capabilities too, so neither SU nor MU
setup can run. Before this patch, enabling the parameter before the next
association worked on chips that already supported beamforming.

Could we keep that runtime enable working? If the setting now needs to be
fixed at probe, maybe the parameter should be read only instead.

Best regards,
Luka Gejak