RE: [PATCH] wifi: rtw89: Don't return default channel from disabled bands

[Ping-Ke Shih]

Nícolas F. R. A. Prado <nfraprado@xxxxxxxxxxxxx> wrote:
> On Thu, 2026-08-13 at 00:52 +0000, Ping-Ke Shih wrote:
> > Nícolas F. R. A. Prado <nfraprado@xxxxxxxxxxxxx> wrote:
> > > rtw89_get_default_chandef() assumes the lowest frequency channel in
> > > the
> > > 2GHz band is available on all hardware, and always returns that as
> > > the
> > > default channel. This is no longer the case after commit
> > > 355626a2c232
> > > ("wifi: rtw89: 8852cu: add quirk to disable 2.4 GHz band"), and the
> > > current logic results in kernel WARNs and null pointer dereferences
> > > on
> > > boards with that quirk set.
> >
> > Could you share the kernel WARN?
> 
> Sure, here are the details for those issues:
> 
> Warn:
>   Origin:
> https://github.com/pkshih/rtw/blob/38c58d541cfe286880cdadebc5d726fe18e3b615/net/mac80211/rx.c#L554
> 2
>   dmesg:
> 
>     WARNING: CPU: 0 PID: 0 at net/mac80211/rx.c:5376
> ieee80211_rx_list+0x759/0xda0 [mac80211]

That is the initial channel on 2GHz band, and receive packets there.

> 
> Null pointer dereference:
>   Triggered when running 'iw dev wlan1 set bitrates'
>   Origin:
> https://github.com/pkshih/rtw/blob/38c58d541cfe286880cdadebc5d726fe18e3b615/drivers/net/wireless/r
> ealtek/rtw89/phy.c#L672
>   dmesg:
[...]
>      rtw89_ops_set_bitrate_mask+0x30/0x80 [rtw89_core
> cc2978209104e6e9870df546aa63c2dfe663dabd]

This is user space to bitrate mask on this unexpected band.

Could you please give short brief in commit message about these two points?
(I think no need full call trace)

[...]

> >
> >
> > > +               default_channel = &rtw89_channels_2ghz[0];
> > > +       } else if (support_bands & BIT(NL80211_BAND_5GHZ)) {
> > > +               default_channel = &rtw89_channels_5ghz[0];
> > > +       } else if (support_bands & BIT(NL80211_BAND_6GHZ)) {
> > > +               default_channel = &rtw89_channels_6ghz[0];
> > > +       } else {
> > > +               rtw89_err(rtwdev, "Failed to get default channel,
> > > no band supported\n");
> > > +               return;
> >
> > If it somehow falls into this case, won't it warn or null-
> > dereference?
> 
> I suppose it could, but I'm not sure what would be a better option
> here, do you have any suggestions?
> 
> In any case all of the hardware variants currently defined have at
> least one of those flags set, so this branch could never be reached.
> But if something ever changes, then this error would help noticing it.

Indeed. I think we can return an error in rtw89_core_set_supported_band()
if support_bands is 0. We can stop it when probing. 

Out of curiosity, how did you have one this kind of devices already?
I'm thinking this product isn't shipping yet.

Ping-Ke