From: Tony Chuang <yhchuang@realtek.com>
To: Justin Capella <justincapella@gmail.com>,
Kalle Valo <kvalo@codeaurora.org>
Cc: Brian Norris <briannorris@chromium.org>,
Chris Chiu <chiu@endlessm.com>,
linux-wireless <linux-wireless@vger.kernel.org>
Subject: RE: [PATCH] rtw88: disable TX-AMSDU on 2.4G band
Date: Wed, 12 Feb 2020 02:55:56 +0000 [thread overview]
Message-ID: <2c91e4e7b36d42a8abad6ae356c2869c@realtek.com> (raw)
In-Reply-To: <CAMrEMU-nM1O_iJPVgGg2pL6JYWMdRKdPGe5N2rkfOihdmTeMaw@mail.gmail.com>
> Would some other piece of the stack could decide to use or not use aggregation for a given band/vif/sta? Maybe just semantics but my thought was the driver returning false makes it seem incapable of it.
> I agree about not polluting the module parameters. I'll have a look at the out of tree stuff. Thoughts on debugfs knobs, not necessarily patch specific just in general?
> On Sat, Feb 8, 2020, 2:09 AM Kalle Valo <kvalo@codeaurora.org> wrote:
>> Brian Norris <briannorris@chromium.org> writes:
>>> On Fri, Feb 7, 2020 at 12:48 PM Justin Capella <justincapella@gmail.com> wrote:
>>>> I understand, I'm suggesting disable by default but option to re-enable
>>>
>>> Ah, OK. Seems reasonable, I suppose, although I don't recall Kalle
>>> having a particularly-high opinion of module parameters for tweaking
>>> core 802.11 protocol behaviors.
>> Yeah, exactly. And the number of module parameters a driver has should
>> be minimised. I know out-of-tree vendor drivers have ini files with 100
>> different knobs, but I don't think module parameters should be
>> equivalent to ini files.
Module parameters are really good for me, too. But we've had discussion
before with Kalle and Brian, they both were trying hard to avoid module
parameters.
So, I think Kalle and Brian don't recommend using module parameters.
And I think just disable it on 2.4G is OK, there's no need to enable it for
those supported 2x2 devices, unless we are going to support 3x3/4x4
devices. If that happens, we can add conditions for those 3x3/4x4.
Yan-Hsuan
next prev parent reply other threads:[~2020-02-12 2:56 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-02-04 12:06 [PATCH] rtw88: disable TX-AMSDU on 2.4G band yhchuang
2020-02-07 2:21 ` Chris Chiu
2020-02-07 19:40 ` Justin Capella
2020-02-07 20:41 ` Brian Norris
[not found] ` <CAMrEMU93LScySw4mpidAC5pVHV_NOShP1_GMMsvsAk1QBhdJjQ@mail.gmail.com>
2020-02-07 20:53 ` Brian Norris
2020-02-08 10:09 ` Kalle Valo
[not found] ` <CAMrEMU-nM1O_iJPVgGg2pL6JYWMdRKdPGe5N2rkfOihdmTeMaw@mail.gmail.com>
2020-02-12 2:55 ` Tony Chuang [this message]
2020-02-20 19:04 ` Brian Norris
2020-03-02 13:43 ` Kalle Valo
2020-02-12 16:22 ` Kalle Valo
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2c91e4e7b36d42a8abad6ae356c2869c@realtek.com \
--to=yhchuang@realtek.com \
--cc=briannorris@chromium.org \
--cc=chiu@endlessm.com \
--cc=justincapella@gmail.com \
--cc=kvalo@codeaurora.org \
--cc=linux-wireless@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).