RE: [PATCH] rtw88: add debugfs to fix tx rate

[Tony Chuang <yhchuang@realtek.com>]

Brian Norris <briannorris@chromium.org> writes:

> [ To be clear, I haven't asked for this debugfs knob, and as of now,
> there is no plan for Chrome OS to use $subject feature. Per some of
> Tony's descriptions, I suppose maybe this would be useful for certain
> debugging scenarios, but only that -- no intention of wiring this up
> "in production." IIUC, he CC'd me only because of the "measuring the
> TX power" portion of the commit message. ]
> 
> On Fri, Mar 20, 2020 at 6:06 AM Johannes Berg <johannes@sipsolutions.net>
> wrote:
> > Brian can probably comment on this - I think ChromeOS (used to) use(s)
> > some kind of fixed rate at the beginning of the connection to force low
> > rates? But I also remember this interacting badly with some APs that
> > just don't want to enable low rates at all...
> 

[...]

> 
> As Johannes noted, masking off these rates caused problems of its own,
> especially when APs (esp., guided by (mis?)guided I.T. admins who
> think that low bitrates are evil) removed these low bitrates from
> their SupportedRates field. Apparently these APs may start to reject
> clients if they don't obey.
> 
> Additionally, we found no evidence that forcing low bitrates like this
> was substantially helpful for anything other than older ath9k systems.
> So longer story shorter, Chrome OS does not use
> NL80211_CMD_SET_TX_BITRATE_MASK any more.
> 

We want to measure the TX power, and the equipment just cannot
detect the signal on some rates, unless we "fix" the rate exactly.
So NL80211_CMD_SET_TX_BITRATE_MASK is not so useful for us
sometimes. Also we wanted to see not only the TX power, but the
signal quality of certain modulations/coding rates, and the equipment
still tends to receive fixed rates.

[...]

> 
> One could also argue that, if iwlwifi already has a debugfs knob
> (looks like rs_sta_dbgfs_scale_table_write()?), rtw88 should be able
> to have one too ;)
> 
> Regards,
> Brian
> 

Yen-Hsuan