From: Johannes Berg <johannes@sipsolutions.net>
To: Wei-Ning Huang <wnhuang@chromium.org>,
Linux-Wireless <linux-wireless@vger.kernel.org>,
Luca Coelho <luca@coelho.fi>,
haim.dreyfuss@intel.com
Cc: Sameer Nanda <snanda@chromium.org>,
Todd Broch <tbroch@chromium.org>,
linux-kernel <linux-kernel@vger.kernel.org>
Subject: form factor subsystem (Re: [PATCH] cfg80211/nl80211: add wifi tx power mode switching support)
Date: Mon, 21 Nov 2016 09:50:28 +0100 [thread overview]
Message-ID: <1479718228.8662.9.camel@sipsolutions.net> (raw)
In-Reply-To: <1462430663-9448-1-git-send-email-wnhuang@chromium.org> (sfid-20160505_084509_232618_BB2A36EB)
Hi,
I'm revisiting this since we're asked to do the same for iwlwifi.
On Thu, 2016-05-05 at 14:44 +0800, Wei-Ning Huang wrote:
> Recent new hardware has the ability to switch between tablet mode and
> clamshell mode. To optimize WiFi performance, we want to be able to
> use different power table between modes. This patch adds a new
> netlink message type and cfg80211_ops function to allow userspace to
> trigger a power mode switch for a given wireless interface.
I've thought about this a bit more, and also heard this in different
contexts now, and I'm actually not convinced that the wifi subsystem
exposing this *in any way* is the right thing to do.
Why don't we add a minimal "form factor" subsystem to the kernel?
Something that allows
1) sensor/BIOS/... drivers to call a function to switch form factor
2) consumers to register and get callbacks when switching happens
If the sensor driver is in the kernel (some kind of driver probably has
to be anyway), or form factor switch ends up being a BIOS notification,
then this gets rid of a lot of complexity - no more need to bump this
through userspace etc.
If, for some reason, the sensor driver really has to be in userspace,
then some kind of API *to this subsystem* can be implemented to set the
form factor mode from userspace, and all the other stuff can be left as
is.
This would also allow other clients to know about this information,
let's say, for the sake of an argument that doesn't seem *too* far-
fetched, that the compass driver needs to adjust the direction if you
switch modes.
It seems to me that this would be more robust, which can only be a good
thing if we start using it for things that might be regulatory
relevant.
Additionally, the subsystem could allow userspace to also get an event
if it wants to know about this, e.g. to switch to a more touch-friendly
UI on switching to tablet mode, or something.
Thoughts?
johannes
prev parent reply other threads:[~2016-11-21 8:50 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-05-05 6:44 [PATCH] cfg80211/nl80211: add wifi tx power mode switching support Wei-Ning Huang
2016-05-05 16:07 ` Dan Williams
2016-05-06 8:19 ` Wei-Ning Huang
2016-05-11 5:03 ` Wei-Ning Huang
2016-05-11 18:33 ` Dan Williams
2016-05-12 9:34 ` Wei-Ning Huang
2016-05-12 22:02 ` Arend van Spriel
2016-05-13 3:22 ` Wei-Ning Huang
2016-06-28 10:57 ` Johannes Berg
2016-07-07 9:30 ` Wei-Ning Huang
2016-05-11 7:21 ` Johannes Berg
2016-11-21 8:50 ` Johannes Berg [this message]
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=1479718228.8662.9.camel@sipsolutions.net \
--to=johannes@sipsolutions.net \
--cc=haim.dreyfuss@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-wireless@vger.kernel.org \
--cc=luca@coelho.fi \
--cc=snanda@chromium.org \
--cc=tbroch@chromium.org \
--cc=wnhuang@chromium.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).