[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1467111448.2493.15.camel@sipsolutions.net>
Date: Tue, 28 Jun 2016 12:57:28 +0200
From: Johannes Berg <johannes@...solutions.net>
To: Wei-Ning Huang <wnhuang@...gle.com>, Dan Williams <dcbw@...hat.com>
Cc: Linux-Wireless <linux-wireless@...r.kernel.org>,
LKML <linux-kernel@...r.kernel.org>,
Sameer Nanda <snanda@...omium.org>,
Todd Broch <tbroch@...omium.org>, davem@...emloft.net,
netdev@...r.kernel.org
Subject: Re: [PATCH] cfg80211/nl80211: add wifi tx power mode switching
support
On Thu, 2016-05-12 at 17:34 +0800, Wei-Ning Huang wrote:
>
> Johannes, I feel like being able to set calibration data at runtime
> is something common to all wireless drivers, so instead of using
> vendor commands what do you think if I pass the calibration data name
> instead of using those magic constants? This way, userspace does not
> need to know the details of what band/range power limit the driver
> supports. It allows for flexible driver side implementation and
> easier for userspace to control.
>
Sorry - I dropped this thread accidentally.
I'm not really sure I understand the situation fully, but right now to
me this seems very strange.
The physical antennas probably don't really change between "clamshell"
and "tablet" mode, do the physical radiation properties change enough
to actually require different *calibration*? To me, that sounds very
strange.
Assuming they don't really change fundamentally, then I understand the
need to set different power levels, per band/channel/whatever
granularity. But that can be achieved in very different ways, and in
fact if you look at Chrome then for our iwl7000 driver there we do have
a command to do something similar (currently a vendor command, but that
can be changed) without ever changing the *calibration*.
So to me, the whole premise of the patch is confusing and/or wrong.
johannes
Powered by blists - more mailing lists