From: Kalle Valo <kvalo@codeaurora.org>
To: <yhchuang@realtek.com>
Cc: <linux-wireless@vger.kernel.org>, <briannorris@chromium.org>,
<g.schlmm@googlemail.com>
Subject: Re: [PATCH 3/6] rtw88: use a module parameter to control LPS enter
Date: Thu, 31 Oct 2019 07:59:11 +0000 (UTC) [thread overview]
Message-ID: <20191031075911.24E1D60930@smtp.codeaurora.org> (raw)
In-Reply-To: <20191025093345.22643-4-yhchuang@realtek.com>
<yhchuang@realtek.com> wrote:
> From: Yan-Hsuan Chuang <yhchuang@realtek.com>
>
> If the number of packets is less than the LPS threshold, driver
> can then enter LPS mode.
> And driver used to take RTW_LPS_THRESHOLD as the threshold. As
> the macro can not be changed after compiled, use a parameter
> instead.
>
> The larger of the threshold, the more traffic required to leave
> power save mode, responsive time could be longer, but also the
> power consumption could be lower.
>
> Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com>
> Reviewed-by: Chris Chiu <chiu@endlessm.com>
I don't think a module parameter should be used to control power save
level, instead there should be a generic interface for that. Also the commit
log does not give any explanation why this needs to be a module parameter.
Tony, there's a high barrier for adding new module parameters. It's a common
phrase for me to say "module parameters are not windows .ini files". And to make it
easier for everyone always submit controversial patches separately, do not hide
within a bigger patchset.
--
https://patchwork.kernel.org/patch/11211881/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
next prev parent reply other threads:[~2019-10-31 7:59 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-10-25 9:33 [PATCH 0/6] rtw88: minor driver updates yhchuang
2019-10-25 9:33 ` [PATCH 1/6] rtw88: 8822b: add RFE type 3 support yhchuang
2019-10-31 8:04 ` Kalle Valo
2019-10-25 9:33 ` [PATCH 2/6] rtw88: use rtw_phy_pg_cfg_pair struct, not arrays yhchuang
2019-10-25 9:33 ` [PATCH 3/6] rtw88: use a module parameter to control LPS enter yhchuang
2019-10-25 10:51 ` Chris Chiu
2019-10-28 3:12 ` Tony Chuang
2019-10-29 4:01 ` Chris Chiu
2019-10-31 7:59 ` Kalle Valo [this message]
[not found] ` <20191031075911.3CCB86079C@smtp.codeaurora.org>
2019-10-31 8:17 ` Tony Chuang
2019-10-31 20:01 ` Brian Norris
2019-11-01 3:13 ` Tony Chuang
2019-11-01 8:35 ` Kalle Valo
2019-11-01 8:30 ` Kalle Valo
2019-10-25 9:33 ` [PATCH 4/6] rtw88: rearrange if..else statements for rx rate indexes yhchuang
2019-10-25 9:33 ` [PATCH 5/6] rtw88: fix potential read outside array boundary yhchuang
2019-10-25 9:33 ` [PATCH 6/6] rtw88: avoid FW info flood yhchuang
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=20191031075911.24E1D60930@smtp.codeaurora.org \
--to=kvalo@codeaurora.org \
--cc=briannorris@chromium.org \
--cc=g.schlmm@googlemail.com \
--cc=linux-wireless@vger.kernel.org \
--cc=yhchuang@realtek.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.