linux-kernel - form factor subsystem (Re: [PATCH] cfg80211/nl80211: add wifi tx power mode switching support)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Mon, 21 Nov 2016 09:50:28 +0100
From:   Johannes Berg <johannes@...solutions.net>
To:     Wei-Ning Huang <wnhuang@...omium.org>,
        Linux-Wireless <linux-wireless@...r.kernel.org>,
        Luca Coelho <luca@...lho.fi>, haim.dreyfuss@...el.com
Cc:     Sameer Nanda <snanda@...omium.org>,
        Todd Broch <tbroch@...omium.org>,
        linux-kernel <linux-kernel@...r.kernel.org>
Subject: form factor subsystem (Re: [PATCH] cfg80211/nl80211: add wifi tx
 power mode switching support)

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