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
next prev parent 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).