Received-SPF: pass (google.com: best guess record for domain of linux-wireless-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
MIME-Version: 1.0
References: <20200313065114.23433-1-yhchuang@realtek.com> <87eetwo87q.fsf@kamboji.qca.qualcomm.com>
 <2e492e530d744713871f885e324106ef@realtek.com> <87eetrlanb.fsf@kamboji.qca.qualcomm.com>
 <ce990869ebf0478d98cd7e8416b36289@realtek.com> <875zf3kn05.fsf@kamboji.qca.qualcomm.com>
 <f4e7401c-c86b-8b2f-9e93-865322f71945@candelatech.com> <fbab3328d183406c923b30381389841f@realtek.com>
 <d45e2002e97c28acc1f9c7b9c41b5a3ba1d69452.camel@sipsolutions.net>
 <CA+ASDXM5tSmeE72+fn5K2vgR6kPE3OUbHJ_T_DVV63rFrPzv2w@mail.gmail.com> <3894907ca6bf4566b8716731492a869b@realtek.com>
In-Reply-To: <3894907ca6bf4566b8716731492a869b@realtek.com>
From:   Brian Norris <briannorris@chromium.org>
Date:   Tue, 24 Mar 2020 22:16:27 -0700
Message-ID: <CA+ASDXMi8BqccHdVXVXb0JOj4y0vcFBGdL6BB0YuzB78qzgQuQ@mail.gmail.com>
Subject: Re: [PATCH] rtw88: add debugfs to fix tx rate
To:     Tony Chuang <yhchuang@realtek.com>
Cc:     Johannes Berg <johannes@sipsolutions.net>,
        Ben Greear <greearb@candelatech.com>,
        Kalle Valo <kvalo@codeaurora.org>,
        "linux-wireless@vger.kernel.org" <linux-wireless@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Sender: linux-wireless-owner@vger.kernel.org
Precedence: bulk

On Tue, Mar 24, 2020 at 7:55 PM Tony Chuang <yhchuang@realtek.com> wrote:
> Brian Norris <briannorris@chromium.org> writes:
> We want to measure the TX power, and the equipment just cannot
> detect the signal on some rates, unless we "fix" the rate exactly.

I think we all understand this now.

> So NL80211_CMD_SET_TX_BITRATE_MASK is not so useful for us
> sometimes.

I'm not sure if you have directly explained why this is the case. See
your comment earlier:

"This command just mask out some of rates that are not allowed."

Sure, but if you mask out all but 1 bitrate...voila! A fixed rate!

And this:

"But actually the firmware has its own rate
adaptive mechanism, so mask out the other rates does not mean the rate
left will be chosen."

That's entirely your fault, not the fault of the API. If your firmware
doesn't listen to your driver, then that's either your firmware or
your driver's fault. If you set a mask that has exactly 1 bitrate in
it... well, that's exactly what you should tell your firmware to do.
Not, "use this 1 bitrate, but try something else if you feel like it."

Now, there are other problems, like the others that Ben mentioned: the
rest of the mac80211 framework doesn't like it too much if you really
disable all but 1 rate (arguably a mac80211 bug -- but not a nl80211
bug); or maybe you want to differentiate management frames and data
frames (and that's not what the current
NL80211_CMD_SET_TX_BITRATE_MASK allows for).

I'm still not (personally) expecting that you *must* do this all via
the existing CMD_SET_TX_BITRATE_MASK, but to satisfy everyone involved
here, you at least need to be clear about why you aren't.

Regards,
Brian