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 14:47:06 +0200	[thread overview]
Message-ID: <4FBB8ACA.3080408@01019freenet.de> (raw)
In-Reply-To: <CAGXE3d8m_0E2HGjCY9uMtj-Kahg9QCJjpsCCGjm+go6n_+V1Pg@mail.gmail.com>

Helmut Schaa schrieb:
> On Tue, May 22, 2012 at 1:26 PM, Andreas Hartmann
> <andihartmann@01019freenet.de> wrote:
>> 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.
> 
> Understood, but that would require the user to know the domain the
> device is calibrated for.

Why should he not know this? If it is really not known, your default is
applied hence nothing is lost.

> I think we should just always run the device at 100% but add an option in
> the future to allow rx power reduction by percentage.

Hmmm, but this requires the user to know even more:
- For which domain is the device originally calibrated?
- What's the allowed max value of this domain?
- What's the allowed max value of the new domain the device should
operate now?
- Calculate the percentage < 100% to get the correct Tx-power.

Don't you think that this is much more complicated as just applying the
domain the device was originally sold from (or maybe there is a
certificate given with the device telling about another approved domain)?


Sorry,
kind regards,
Andreas

  reply	other threads:[~2012-05-22 12:49 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
2012-05-22 11:32               ` Helmut Schaa
2012-05-22 12:47                 ` Andreas Hartmann [this message]
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=4FBB8ACA.3080408@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).