linux-wireless.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Andreas Hartmann <andihartmann@01019freenet.de>
To: Helmut Schaa <helmut.schaa@googlemail.com>
Cc: "linux-wireless@vger.kernel.org" <linux-wireless@vger.kernel.org>
Subject: Re: [PATCH] rt2800: Initialize max_txpower to MAX_G_TXPOWER and MAX_A_TXPOWER respectively
Date: Tue, 22 May 2012 13:26:12 +0200	[thread overview]
Message-ID: <4FBB77D4.9050801@01019freenet.de> (raw)
In-Reply-To: <CAGXE3d-2ndXX1D-JQLo6m=Osg6RRe4Z2gb_=BPrz0wASzFciNA@mail.gmail.com>

Hello Helmut,

Helmut Schaa wrote:
> Hi Andreas,
> 
> Sorry, missed your previous mail.

Thanks for your response!! This made things more clear to me!

> On Tue, May 22, 2012 at 10:38 AM, Andreas Hartmann
> <andihartmann@01019freenet.de> wrote:
>> Andreas Hartmann wrote:
>>> Helmut Schaa wrote:
>>>> On Fri, May 18, 2012 at 6:21 PM, Tobias Diedrich <ranma@tdiedrich.de> wrote:
>>>>>> So, maybe we should do it the safe way and just register a safe default
>>>>>> of 20dBm for all channels?
>>>>>
>>>>> AFAIU that would cap you to 20dBm even if you are in a country that
>>>>> has higher limits (e.g. 27dBm in the US?).
>>>>
>>>> Not necessarily because the driver won't allow tx power adjustments at all
>>>> if EEPROM_EIRP_MAX_TX_POWER is unused.
>>>
>>> This means:
>>> Tx settings in cfg80211 as given by "iw reg get" e.g. are ignored
>>> completely as long as EEPROM_EIRP_MAX_TX_POWER is unused.
>>> Thus it is more or less chance that the device actually uses the allowed
>>> / correct Tx power at all. Maybe it's too high or too low. Both would be
>>> bad.

[Most ralink devices have fixed max Tx power depended on the region, the
device was sold]

> Either we have to tune cfg80211 to allow setting the tx power by percentage
> or disallow tx power control on these device or we trick cfg80211 by registering
> a reasonable default value (like 20dBm) to cfg80211 but do adjustments
> by percentage.
> 
> So, if a device is actually calibrated to 17dBm but we register 20dBm
> to cfg80211
> and a user sets the new tx power to 17dBm we can apply the actual delta to
> the device tx power configuration. Hence, the device will then
> transmit with 14dBm
> while cfg80211 shows 17dBm. This would be a compromise to still allow tx power
> settings without having to add all the overhead to cfg80211.

What about this idea: The driver gets an option to set the calibrated
region (devcalreg), say US. This is a static value in respect of the device.
If the user operates the device in DE, he just would have to change the
value of cfg80211 from US to DE.

Device sold in US
=================

Device operated in US
devcalreg=US					23dBm
cfg80211=US		100% max Tx power	23dBm

Device operated in DE
devcalreg=US					23dBm
cfg80211=DE		87%  max Tx power	20dBm

If cfg80211 is set to a region which allows higher values, the
percentage would be >100%, but this could be probably easily prohibited.

If the user doesn't provide devcalreg your default value gets applied.

The difference to your idea is, that the "default" could be dynamically
derived from cfg80211 on the basis of the devcalreg. This would prohibit
the problem you showed above.


Kind regards,
Andreas

  reply	other threads:[~2012-05-22 11:28 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-05-17 23:04 [PATCH] rt2800: Initialize max_txpower to MAX_G_TXPOWER and MAX_A_TXPOWER respectively Tobias Diedrich
2012-05-18  6:57 ` Gertjan van Wingerde
2012-05-18  9:18 ` Helmut Schaa
2012-05-18 12:13   ` Andreas Hartmann
2012-05-18 16:21   ` Tobias Diedrich
2012-05-19  8:14     ` Helmut Schaa
2012-05-19  9:37       ` Andreas Hartmann
2012-05-22  8:38         ` Andreas Hartmann
2012-05-22 10:02           ` Helmut Schaa
2012-05-22 11:26             ` Andreas Hartmann [this message]
2012-05-22 11:32               ` Helmut Schaa
2012-05-22 12:47                 ` Andreas Hartmann
2012-05-24  7:35                   ` Andreas Hartmann
2012-06-04 11:08             ` Stanislaw Gruszka
2012-06-04 12:24               ` Helmut Schaa
2012-05-22 11:33 ` Helmut Schaa
2012-05-22 20:58   ` Tobias Diedrich
2012-05-23 11:32     ` Helmut Schaa
2012-05-23 13:55       ` Tobias Diedrich
2012-05-23 19:30         ` Helmut Schaa
2012-05-23 20:51           ` Tobias Diedrich

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=4FBB77D4.9050801@01019freenet.de \
    --to=andihartmann@01019freenet.de \
    --cc=helmut.schaa@googlemail.com \
    --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).