RE: [PATCH rtw-next 5/5] wifi: rtlwifi: rtl8192d: let the firmware use all rates

[Ping-Ke Shih]

Jie Feng <hjf3108@xxxxxxxxx> wrote:
> On Mon, 9 Nov 2026 at 08:56, Ping-Ke Shih <pkshih@xxxxxxxxxxx> wrote:
> >
> > Ho Jie Feng <hjf3108@xxxxxxxxx> wrote:
> > > The rate mask is chosen based on rssi_level, however rssi_level
> > > is always 0,
> >
> > Should we fix it ?
> The vendor driver for rtl8192du also doesn't do the rssi_level update
> It is not compiled due to the #if 0
> https://github.com/lwfinger/rtl8192du/blob/master/hal/rtl8192d_dm.c#L2624
> Therefore, I'm not sure if it is okay to port it over.

Add to your todo list. To fine tune throughput, you need a set of plan to
verify to ensure your implementation is good.

> 
> > > since:
> > > - for rtl8192de, call to rtl92d_dm_refresh_rate_adaptive_mask is
> > >   commented out and function is not implemented
> > > - for rtl8192du, it is also not called.
> > >
> > > This makes the branch always choose less than optimal allowed MCS rates.
> > > Enable all the rates.
> > >
> > > Test results (2.4 GHz):
> > >    before after
> > > TX 6.4    12.6
> >
> > How about the rate before/after? I think the highest rate will be similar
> > or the same?
> Highest rate will be similar, but I saw it using more intermediate rates.

With longer test time (e.g. 10 minutes), will throughput become similar?

> 
> > > RX 32.0   39.1
> >
> > You change many rate masks for different wireless modes, so please provide
> > more experiments. Especially you need tests for a clean & noisy environments.
> So this patch by itself is more of an RFC, and I might drop it in v2
> if it changes
> behaviour too much in different circumstances.

Yes, I think so. 

If you can make plans to verify it fully, I can accept the change.