[PATCH] rt2800: Initialize max_txpower to MAX_G_TXPOWER and MAX_A_TXPOWER respectively

[PATCH] rt2800: Initialize max_txpower to MAX_G_TXPOWER and MAX_A_TXPOWER respectively

[Tobias Diedrich]

rt2800: Initialize max_txpower to MAX_G_TXPOWER and MAX_A_TXPOWER
respectively, similar to how it is already done in rt2[45]00pci.c

rt2800lib.c doesn't initialize max_power and thus after
http://git.kernel.org/?p=linux/kernel/git/linville/wireless-next.git;a=commitdiff;h=eccc068e8e84c8fe997115629925e0422a98e4de
was applied txpower is limited to 0 for these devices.

This should be the proper fix compared to the net/wireless/reg.c
hack in http://patchwork.openwrt.org/patch/2165/

(Patch against the OpenWRT compat-wireless version, but applies
equally well against wireless-next with a 19-line offset)

Signed-off-by: Tobias Diedrich <ranma+openwrt@tdiedrich.de>


Index: compat-wireless-2012-04-17/drivers/net/wireless/rt2x00/rt2800lib.c
===================================================================
--- compat-wireless-2012-04-17.orig/drivers/net/wireless/rt2x00/rt2800lib.c	2012-05-18 00:25:22.515271380 +0200
+++ compat-wireless-2012-04-17/drivers/net/wireless/rt2x00/rt2800lib.c	2012-05-18 00:28:48.809658951 +0200
@@ -4622,6 +4622,7 @@
 	default_power2 = rt2x00_eeprom_addr(rt2x00dev, EEPROM_TXPOWER_BG2);
 
 	for (i = 0; i < 14; i++) {
+		info[i].max_power = MAX_G_TXPOWER;
 		info[i].default_power1 = default_power1[i];
 		info[i].default_power2 = default_power2[i];
 	}
@@ -4631,6 +4632,7 @@
 		default_power2 = rt2x00_eeprom_addr(rt2x00dev, EEPROM_TXPOWER_A2);
 
 		for (i = 14; i < spec->num_channels; i++) {
+			info[i].max_power = MAX_A_TXPOWER;
 			info[i].default_power1 = default_power1[i];
 			info[i].default_power2 = default_power2[i];
 		}

-- 
Tobias						PGP: http://8ef7ddba.uguu.de

Re: [PATCH] rt2800: Initialize max_txpower to MAX_G_TXPOWER and MAX_A_TXPOWER respectively

[Gertjan van Wingerde]

On 05/18/12 01:04, Tobias Diedrich wrote:
> rt2800: Initialize max_txpower to MAX_G_TXPOWER and MAX_A_TXPOWER
> respectively, similar to how it is already done in rt2[45]00pci.c
> 
> rt2800lib.c doesn't initialize max_power and thus after
> http://git.kernel.org/?p=linux/kernel/git/linville/wireless-next.git;a=commitdiff;h=eccc068e8e84c8fe997115629925e0422a98e4de
> was applied txpower is limited to 0 for these devices.
> 
> This should be the proper fix compared to the net/wireless/reg.c
> hack in http://patchwork.openwrt.org/patch/2165/
> 
> (Patch against the OpenWRT compat-wireless version, but applies
> equally well against wireless-next with a 19-line offset)
> 
> Signed-off-by: Tobias Diedrich <ranma+openwrt@tdiedrich.de>

Acked-by: Gertjan van Wingerde <gwingerde@gmail.com>

> 
> 
> Index: compat-wireless-2012-04-17/drivers/net/wireless/rt2x00/rt2800lib.c
> ===================================================================
> --- compat-wireless-2012-04-17.orig/drivers/net/wireless/rt2x00/rt2800lib.c	2012-05-18 00:25:22.515271380 +0200
> +++ compat-wireless-2012-04-17/drivers/net/wireless/rt2x00/rt2800lib.c	2012-05-18 00:28:48.809658951 +0200
> @@ -4622,6 +4622,7 @@
>  	default_power2 = rt2x00_eeprom_addr(rt2x00dev, EEPROM_TXPOWER_BG2);
>  
>  	for (i = 0; i < 14; i++) {
> +		info[i].max_power = MAX_G_TXPOWER;
>  		info[i].default_power1 = default_power1[i];
>  		info[i].default_power2 = default_power2[i];
>  	}
> @@ -4631,6 +4632,7 @@
>  		default_power2 = rt2x00_eeprom_addr(rt2x00dev, EEPROM_TXPOWER_A2);
>  
>  		for (i = 14; i < spec->num_channels; i++) {
> +			info[i].max_power = MAX_A_TXPOWER;
>  			info[i].default_power1 = default_power1[i];
>  			info[i].default_power2 = default_power2[i];
>  		}
> 


-- 
---
Gertjan

Re: [PATCH] rt2800: Initialize max_txpower to MAX_G_TXPOWER and MAX_A_TXPOWER respectively

[Helmut Schaa]

Hi,

On Fri, May 18, 2012 at 1:04 AM, Tobias Diedrich
<ranma+openwrt@tdiedrich.de> wrote:
> rt2800: Initialize max_txpower to MAX_G_TXPOWER and MAX_A_TXPOWER
> respectively, similar to how it is already done in rt2[45]00pci.c
>
> rt2800lib.c doesn't initialize max_power and thus after
> http://git.kernel.org/?p=linux/kernel/git/linville/wireless-next.git;a=commitdiff;h=eccc068e8e84c8fe997115629925e0422a98e4de
> was applied txpower is limited to 0 for these devices.
>
> This should be the proper fix compared to the net/wireless/reg.c
> hack in http://patchwork.openwrt.org/patch/2165/
>
> (Patch against the OpenWRT compat-wireless version, but applies
> equally well against wireless-next with a 19-line offset)
>
> Signed-off-by: Tobias Diedrich <ranma+openwrt@tdiedrich.de>
>
>
> Index: compat-wireless-2012-04-17/drivers/net/wireless/rt2x00/rt2800lib.c
> ===================================================================
> --- compat-wireless-2012-04-17.orig/drivers/net/wireless/rt2x00/rt2800lib.c     2012-05-18 00:25:22.515271380 +0200
> +++ compat-wireless-2012-04-17/drivers/net/wireless/rt2x00/rt2800lib.c  2012-05-18 00:28:48.809658951 +0200
> @@ -4622,6 +4622,7 @@
>        default_power2 = rt2x00_eeprom_addr(rt2x00dev, EEPROM_TXPOWER_BG2);
>
>        for (i = 0; i < 14; i++) {
> +               info[i].max_power = MAX_G_TXPOWER;

31dBm? That's ~1.3W.

I'd say we have to find a different way to deal with this issue.

Theoretically the device eeprom contains the allowed max tx power in
EEPROM_EIRP_MAX_TX_POWER however most devices don't use this
value at all :( so we cannot rely on it for most devices.

Typically the ralink devices are calibrated for 100% tx power. However,
without EEPROM_EIRP_MAX_TX_POWER we don't know the real tx
power of the device at all (have to consider antenna gain which should be
part of EEPROM_EIRP_MAX_TX_POWER).

So, maybe we should do it the safe way and just register a safe default
of 20dBm for all channels?

Helmut

Re: [PATCH] rt2800: Initialize max_txpower to MAX_G_TXPOWER and MAX_A_TXPOWER respectively

[Andreas Hartmann]

Hi Helmut,

Helmut Schaa wrote:
> Hi,
> 
> On Fri, May 18, 2012 at 1:04 AM, Tobias Diedrich
> <ranma+openwrt@tdiedrich.de> wrote:
>> rt2800: Initialize max_txpower to MAX_G_TXPOWER and MAX_A_TXPOWER
>> respectively, similar to how it is already done in rt2[45]00pci.c
>>
>> rt2800lib.c doesn't initialize max_power and thus after
>> http://git.kernel.org/?p=linux/kernel/git/linville/wireless-next.git;a=commitdiff;h=eccc068e8e84c8fe997115629925e0422a98e4de
>> was applied txpower is limited to 0 for these devices.
>>
>> This should be the proper fix compared to the net/wireless/reg.c
>> hack in http://patchwork.openwrt.org/patch/2165/
>>
>> (Patch against the OpenWRT compat-wireless version, but applies
>> equally well against wireless-next with a 19-line offset)
>>
>> Signed-off-by: Tobias Diedrich <ranma+openwrt@tdiedrich.de>
>>
>>
>> Index: compat-wireless-2012-04-17/drivers/net/wireless/rt2x00/rt2800lib.c
>> ===================================================================
>> --- compat-wireless-2012-04-17.orig/drivers/net/wireless/rt2x00/rt2800lib.c     2012-05-18 00:25:22.515271380 +0200
>> +++ compat-wireless-2012-04-17/drivers/net/wireless/rt2x00/rt2800lib.c  2012-05-18 00:28:48.809658951 +0200
>> @@ -4622,6 +4622,7 @@
>>        default_power2 = rt2x00_eeprom_addr(rt2x00dev, EEPROM_TXPOWER_BG2);
>>
>>        for (i = 0; i < 14; i++) {
>> +               info[i].max_power = MAX_G_TXPOWER;
> 
> 31dBm? That's ~1.3W.
> 
> I'd say we have to find a different way to deal with this issue.
> 
> Theoretically the device eeprom contains the allowed max tx power in
> EEPROM_EIRP_MAX_TX_POWER however most devices don't use this
> value at all :( so we cannot rely on it for most devices.
> 
> Typically the ralink devices are calibrated for 100% tx power. However,
> without EEPROM_EIRP_MAX_TX_POWER we don't know the real tx
> power of the device at all (have to consider antenna gain which should be
> part of EEPROM_EIRP_MAX_TX_POWER).
> 
> So, maybe we should do it the safe way and just register a safe default
> of 20dBm for all channels?

What are your considerations to set it to 20dBm and not to 25dBm, e.g.?
What would be the functional consequence, if it would be set to 25dBm or
to 31dBm?


Thanks,
Andreas

Re: [PATCH] rt2800: Initialize max_txpower to MAX_G_TXPOWER and MAX_A_TXPOWER respectively

[Tobias Diedrich]

Helmut Schaa wrote:
> Hi,
> 
> On Fri, May 18, 2012 at 1:04 AM, Tobias Diedrich
> <ranma+openwrt@tdiedrich.de> wrote:
> > rt2800: Initialize max_txpower to MAX_G_TXPOWER and MAX_A_TXPOWER
> > respectively, similar to how it is already done in rt2[45]00pci.c
> >
> > rt2800lib.c doesn't initialize max_power and thus after
> > http://git.kernel.org/?p=linux/kernel/git/linville/wireless-next.git;a=commitdiff;h=eccc068e8e84c8fe997115629925e0422a98e4de
> > was applied txpower is limited to 0 for these devices.
> >
> > This should be the proper fix compared to the net/wireless/reg.c
> > hack in http://patchwork.openwrt.org/patch/2165/
> >
> > (Patch against the OpenWRT compat-wireless version, but applies
> > equally well against wireless-next with a 19-line offset)
> >
> > Signed-off-by: Tobias Diedrich <ranma+openwrt@tdiedrich.de>
> >
> >
> > Index: compat-wireless-2012-04-17/drivers/net/wireless/rt2x00/rt2800lib.c
> > ===================================================================
> > --- compat-wireless-2012-04-17.orig/drivers/net/wireless/rt2x00/rt2800lib.c     2012-05-18 00:25:22.515271380 +0200
> > +++ compat-wireless-2012-04-17/drivers/net/wireless/rt2x00/rt2800lib.c  2012-05-18 00:28:48.809658951 +0200
> > @@ -4622,6 +4622,7 @@
> >        default_power2 = rt2x00_eeprom_addr(rt2x00dev, EEPROM_TXPOWER_BG2);
> >
> >        for (i = 0; i < 14; i++) {
> > +               info[i].max_power = MAX_G_TXPOWER;
> 
> 31dBm? That's ~1.3W.
> 
> I'd say we have to find a different way to deal with this issue.
> 
> Theoretically the device eeprom contains the allowed max tx power in
> EEPROM_EIRP_MAX_TX_POWER however most devices don't use this
> value at all :( so we cannot rely on it for most devices.

Yep, I looked at it for my device and I only found 0xff for both G
and A in there.  Maybe you could use max(eeprom_eirp, MAX_TXPOWER)
though...

> Typically the ralink devices are calibrated for 100% tx power. However,
> without EEPROM_EIRP_MAX_TX_POWER we don't know the real tx
> power of the device at all (have to consider antenna gain which should be
> part of EEPROM_EIRP_MAX_TX_POWER).
> 
> 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?).

-- 
Tobias						PGP: http://8ef7ddba.uguu.de

Re: [PATCH] rt2800: Initialize max_txpower to MAX_G_TXPOWER and MAX_A_TXPOWER respectively

[Helmut Schaa]

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.

For these devices we cannot rely on the tx power output at all and maybe
it makes sense to register a max power of 0 just to tell mac80211/cfg80211
that no tx power adjustments are possible on these devices?

Helmut

Re: [PATCH] rt2800: Initialize max_txpower to MAX_G_TXPOWER and MAX_A_TXPOWER respectively

[Andreas Hartmann]

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.

> For these devices we cannot rely on the tx power output at all and maybe
> it makes sense to register a max power of 0 just to tell mac80211/cfg80211
> that no tx power adjustments are possible on these devices?

Hmmm, this sounds really strange. How can I see if a device uses
EEPROM_EIRP_MAX_TX_POWER at all?
It would be good to have a log entry, telling the user that the Tx power
of the device can't be adjusted at all and therefore it is possible,
that the operation of the device might be illegal in the current country
even if cfg80211 is set correctly.


Is it done the same way by the legacy driver?


Thanks,
kind regards,
Andreas

Re: [PATCH] rt2800: Initialize max_txpower to MAX_G_TXPOWER and MAX_A_TXPOWER respectively

[Andreas Hartmann]

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.

Please Helmut, I would be really grateful if you could confirm or negate
my conclusion.

>> For these devices we cannot rely on the tx power output at all and maybe
>> it makes sense to register a max power of 0 just to tell mac80211/cfg80211
>> that no tx power adjustments are possible on these devices?
> 
> Hmmm, this sounds really strange. How can I see if a device uses
> EEPROM_EIRP_MAX_TX_POWER at all?
> It would be good to have a log entry, telling the user that the Tx power
> of the device can't be adjusted at all and therefore it is possible,
> that the operation of the device might be illegal in the current country
> even if cfg80211 is set correctly.


Thank you Helmut,
kind regards,
Andreas

Re: [PATCH] rt2800: Initialize max_txpower to MAX_G_TXPOWER and MAX_A_TXPOWER respectively

[Helmut Schaa]

Hi Andreas,

Sorry, missed your previous mail.

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.
>
> Please Helmut, I would be really grateful if you could confirm or negate
> my conclusion.

There are two classes of ralink devices the manufacturers could actually
produce: Devices that rely on software regulatory handling and devices
that are calibrated for a specific region.

The ones that rely on sw regulatory handling specify EEPROM_EIRP_MAX_TX_POWER
in their calibration data such that the driver is able to specify
arbitrary tx power
values. I've never seen such a device ...

The others are just calibrated for a specific country. For example
there could be
a device sold in the US that is calibrated to 23dBm while one that is sold in
Europe is calibrated to 18dBm. However, the driver has no information about
this.

Hence, using the US device in Europe is not allowed but there's nothing the
driver can actually do against that. The other way if you take your European
device with you to US you would be allowed (from a FCC POV) to use more
then 20dBm tx power but since the driver doesn't know how to configure the
device to a specific value you would have to live with the lower tx power.

>>> For these devices we cannot rely on the tx power output at all and maybe
>>> it makes sense to register a max power of 0 just to tell mac80211/cfg80211
>>> that no tx power adjustments are possible on these devices?
>>
>> Hmmm, this sounds really strange. How can I see if a device uses
>> EEPROM_EIRP_MAX_TX_POWER at all?
>> It would be good to have a log entry, telling the user that the Tx power
>> of the device can't be adjusted at all and therefore it is possible,
>> that the operation of the device might be illegal in the current country
>> even if cfg80211 is set correctly.

The same problem arises with different operating systems as well. If you
take your 23dBm US card to Europe it will also transmit with 23dBm when
using the ralink legacy drivers or the windows drivers. So there is nothing
the driver should warn about.

Btw. the legacy driver also allows tx power control on devices without
EEPROM_EIRP_MAX_TX_POWER but it doesn't allow arbitrary dBm values
to be specified. It only allows to set the tx power to a percentage value (up to
100%) of the calibrated value. This is however not possible with the current
regulatory implementation in cfg80211.

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.

Btw. I've got a proof-of-concept patch for this but need to dig it up first.

Helmut

Re: [PATCH] rt2800: Initialize max_txpower to MAX_G_TXPOWER and MAX_A_TXPOWER respectively

[Andreas Hartmann]

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

Re: [PATCH] rt2800: Initialize max_txpower to MAX_G_TXPOWER and MAX_A_TXPOWER respectively

[Helmut Schaa]

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.

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.

Helmut

Re: [PATCH] rt2800: Initialize max_txpower to MAX_G_TXPOWER and MAX_A_TXPOWER respectively

[Andreas Hartmann]

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

Re: [PATCH] rt2800: Initialize max_txpower to MAX_G_TXPOWER and MAX_A_TXPOWER respectively

[Andreas Hartmann]

Andreas Hartmann wrote:
> Helmut Schaa wrote:
>> 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

Well, I just saw, that the legacy driver
2010_0915_RT3572_Linux_STA_v2.4.0.2 defines in include/rtmp.h

UCHAR TxPower; // in unit of mW

Therefore my calculation above would have been wrong, if I got it right.

23dBm equate 199mW
20dBm equate 100mW

To get the ralink device work with the reduced legal Tx power (20dBm
instead of 23dBm), I would have to use 50% and not 87%.

>>>
>>> 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.

- The user has to know, that the base of the percentage is mW and he has
to take care of the different units and he has to know how to handle them.


I do not think, that it is a good idea to leave the user alone with
finding the correct new percentage.

Please, think again about this point - or did I get something wrong?

I know it is much more time and effort to implement it, but it would be
much more user friendly :-).


Thanks,
kind regards,
Andreas

Re: [PATCH] rt2800: Initialize max_txpower to MAX_G_TXPOWER and MAX_A_TXPOWER respectively

[Stanislaw Gruszka]

On Tue, May 22, 2012 at 12:02:24PM +0200, Helmut Schaa wrote:
> Btw. I've got a proof-of-concept patch for this but need to dig it up first.

So, when you will post it  ? :-)

Stanislaw

Re: [PATCH] rt2800: Initialize max_txpower to MAX_G_TXPOWER and MAX_A_TXPOWER respectively

[Helmut Schaa]

Hi,

On Mon, Jun 4, 2012 at 1:08 PM, Stanislaw Gruszka <sgruszka@redhat.com> wrote:
> On Tue, May 22, 2012 at 12:02:24PM +0200, Helmut Schaa wrote:
>> Btw. I've got a proof-of-concept patch for this but need to dig it up first.
>
> So, when you will post it  ? :-)

Now :D

However, treat this with care, and it still requires Tobias initial
cfg80211 patch  ...

Helmut

>From 44e01b6fcfa70fa2d015b30bab0cb1fb377dd3ca Mon Sep 17 00:00:00 2001
From: Helmut Schaa <helmut.schaa@googlemail.com>
Date: Mon, 4 Jun 2012 14:19:38 +0200
Subject: [PATCH] rt2x00: Allow txpower control on rt2800 devices
without eirp max tx power

Some rt2800 devices don't have their calibrated max eirp tx power in
their calibration data. For these devices we only allow tx power
reduction. As a calculation base we use the maximum allowed tx power as
imposed by the regulatory framework.

Signed-off-by: Helmut Schaa <helmut.schaa@googlemail.com>
---
 drivers/net/wireless/rt2x00/rt2800lib.c |   56 ++++++++++++++++++++++++++-----
 1 files changed, 47 insertions(+), 9 deletions(-)

diff --git a/drivers/net/wireless/rt2x00/rt2800lib.c
b/drivers/net/wireless/rt2x00/rt2800lib.c
index f028aa5..2304d0d 100644
--- a/drivers/net/wireless/rt2x00/rt2800lib.c
+++ b/drivers/net/wireless/rt2x00/rt2800lib.c
@@ -2330,6 +2330,24 @@ static int rt2800_get_txpower_bw_comp(struct
rt2x00_dev *rt2x00dev,
 	return comp_value;
 }

+static int rt2800_get_txpower_reg_delta(struct rt2x00_dev *rt2x00dev,
+					int power_level)
+{
+	if (!test_bit(CAPABILITY_POWER_LIMIT, &rt2x00dev->cap_flags))
+		return 0;
+
+	/*
+	 * XXX: We don't know the maximum transmit power of our hardware since
+	 * the EEPROM doesn't expose it. We only know that we are calibrated
+	 * to 100% tx power.
+	 *
+	 * Hence, we assume the regulatory limit that cfg80211 calulated for
+	 * the current channel is our maximum and if we are requested to lower
+	 * the value we just reduce our tx power accordingly.
+	 */
+	return power_level - rt2x00dev->hw->conf.channel->max_power;
+}
+
 static u8 rt2800_compensate_txpower(struct rt2x00_dev *rt2x00dev, int
is_rate_b,
 				   enum ieee80211_band band, int power_level,
 				   u8 txpower, int delta)
@@ -2341,9 +2359,6 @@ static u8 rt2800_compensate_txpower(struct
rt2x00_dev *rt2x00dev, int is_rate_b,
 	u8 eirp_txpower_criterion;
 	u8 reg_limit;

-	if (!((band == IEEE80211_BAND_5GHZ) && is_rate_b))
-		return txpower;
-
 	if (test_bit(CAPABILITY_POWER_LIMIT, &rt2x00dev->cap_flags)) {
 		/*
 		 * Check if eirp txpower exceed txpower_limit.
@@ -2370,10 +2385,17 @@ static u8 rt2800_compensate_txpower(struct
rt2x00_dev *rt2x00dev, int is_rate_b,

 		reg_limit = (eirp_txpower > power_level) ?
 					(eirp_txpower - power_level) : 0;
-	} else
-		reg_limit = 0;

-	return txpower + delta - reg_limit;
+		return txpower + delta - reg_limit;
+	} else if (delta < 0) {
+		/*
+		 * For devices without calibrated max EIRP tx power only allow
+		 * tx power reduction.
+		 */
+		return txpower + delta;
+	}
+
+	return txpower;
 }

 static void rt2800_config_txpower(struct rt2x00_dev *rt2x00dev,
@@ -2399,13 +2421,29 @@ static void rt2800_config_txpower(struct
rt2x00_dev *rt2x00dev,
 	delta += rt2800_get_gain_calibration_delta(rt2x00dev);

 	/*
-	 * set to normal bbp tx power control mode: +/- 0dBm
+	 * Apply regulatory delta
+	 */
+	delta += rt2800_get_txpower_reg_delta(rt2x00dev, power_level);
+
+	/*
+	 * Set bbp tx power control mode
 	 */
 	rt2800_bbp_read(rt2x00dev, 1, &r1);
-	rt2x00_set_field8(&r1, BBP1_TX_POWER_CTRL, 0);
+	if (delta <= -12) {
+		/* reduce tx power by 12 dBm */
+		rt2x00_set_field8(&r1, BBP1_TX_POWER_CTRL, 2);
+		delta += 12;
+	} else if (delta <= -6) {
+		/* reduce tx power by 6 dBm */
+		rt2x00_set_field8(&r1, BBP1_TX_POWER_CTRL, 1);
+		delta += 6;
+	} else {
+	 	/* set to normal bbp tx power control mode: +/- 0dBm */
+		rt2x00_set_field8(&r1, BBP1_TX_POWER_CTRL, 0);
+	}
 	rt2800_bbp_write(rt2x00dev, 1, r1);
-	offset = TX_PWR_CFG_0;

+	offset = TX_PWR_CFG_0;
 	for (i = 0; i < EEPROM_TXPOWER_BYRATE_SIZE; i += 2) {
 		/* just to be safe */
 		if (offset > TX_PWR_CFG_4)
-- 
1.7.7

Re: [PATCH] rt2800: Initialize max_txpower to MAX_G_TXPOWER and MAX_A_TXPOWER respectively

[Helmut Schaa]

On Fri, May 18, 2012 at 1:04 AM, Tobias Diedrich
<ranma+openwrt@tdiedrich.de> wrote:
> rt2800: Initialize max_txpower to MAX_G_TXPOWER and MAX_A_TXPOWER
> respectively, similar to how it is already done in rt2[45]00pci.c
>
> rt2800lib.c doesn't initialize max_power and thus after
> http://git.kernel.org/?p=linux/kernel/git/linville/wireless-next.git;a=commitdiff;h=eccc068e8e84c8fe997115629925e0422a98e4de
> was applied txpower is limited to 0 for these devices.
>
> This should be the proper fix compared to the net/wireless/reg.c
> hack in http://patchwork.openwrt.org/patch/2165/

Btw. Tobias, did this affect the real tx power of the device at all or
is this just
a cosmetic issue?

Thanks,
Helmut

Re: [PATCH] rt2800: Initialize max_txpower to MAX_G_TXPOWER and MAX_A_TXPOWER respectively

[Tobias Diedrich]

Helmut Schaa wrote:
> On Fri, May 18, 2012 at 1:04 AM, Tobias Diedrich
> <ranma+openwrt@tdiedrich.de> wrote:
> > rt2800: Initialize max_txpower to MAX_G_TXPOWER and MAX_A_TXPOWER
> > respectively, similar to how it is already done in rt2[45]00pci.c
> >
> > rt2800lib.c doesn't initialize max_power and thus after
> > http://git.kernel.org/?p=linux/kernel/git/linville/wireless-next.git;a=commitdiff;h=eccc068e8e84c8fe997115629925e0422a98e4de
> > was applied txpower is limited to 0 for these devices.
> >
> > This should be the proper fix compared to the net/wireless/reg.c
> > hack in http://patchwork.openwrt.org/patch/2165/
> 
> Btw. Tobias, did this affect the real tx power of the device at all or
> is this just
> a cosmetic issue?

Hmm, apparently setting txpower has no effect?
Is it not implemented in the driver?

i.e. regardless of "iw (dev wlan0|phy phy0) set txpower fixed (100|2000)"
I don't see any significant chane in Wifi Analyzer on my Android
phone.

(The real reason I couldn't connect to the AP at all was a different recent
change)

-- 
Tobias						PGP: http://8ef7ddba.uguu.de

Re: [PATCH] rt2800: Initialize max_txpower to MAX_G_TXPOWER and MAX_A_TXPOWER respectively

[Helmut Schaa]

On Tue, May 22, 2012 at 10:58 PM, Tobias Diedrich
<ranma+openwrt@tdiedrich.de> wrote:
> Helmut Schaa wrote:
>> On Fri, May 18, 2012 at 1:04 AM, Tobias Diedrich
>> <ranma+openwrt@tdiedrich.de> wrote:
>> > rt2800: Initialize max_txpower to MAX_G_TXPOWER and MAX_A_TXPOWER
>> > respectively, similar to how it is already done in rt2[45]00pci.c
>> >
>> > rt2800lib.c doesn't initialize max_power and thus after
>> > http://git.kernel.org/?p=linux/kernel/git/linville/wireless-next.git;a=commitdiff;h=eccc068e8e84c8fe997115629925e0422a98e4de
>> > was applied txpower is limited to 0 for these devices.
>> >
>> > This should be the proper fix compared to the net/wireless/reg.c
>> > hack in http://patchwork.openwrt.org/patch/2165/
>>
>> Btw. Tobias, did this affect the real tx power of the device at all or
>> is this just
>> a cosmetic issue?
>
> Hmm, apparently setting txpower has no effect?
> Is it not implemented in the driver?

It is, but only for devices with correct tx power limit in the eeprom.

> i.e. regardless of "iw (dev wlan0|phy phy0) set txpower fixed (100|2000)"
> I don't see any significant chane in Wifi Analyzer on my Android
> phone.
>
> (The real reason I couldn't connect to the AP at all was a different recent
> change)

So, we can actually drop this patch then?

Helmut

Re: [PATCH] rt2800: Initialize max_txpower to MAX_G_TXPOWER and MAX_A_TXPOWER respectively

[Tobias Diedrich]

Helmut Schaa wrote:
> On Tue, May 22, 2012 at 10:58 PM, Tobias Diedrich
> <ranma+openwrt@tdiedrich.de> wrote:
> > Helmut Schaa wrote:
> >> On Fri, May 18, 2012 at 1:04 AM, Tobias Diedrich
> >> <ranma+openwrt@tdiedrich.de> wrote:
> >> > rt2800: Initialize max_txpower to MAX_G_TXPOWER and MAX_A_TXPOWER
> >> > respectively, similar to how it is already done in rt2[45]00pci.c
> >> >
> >> > rt2800lib.c doesn't initialize max_power and thus after
> >> > http://git.kernel.org/?p=linux/kernel/git/linville/wireless-next.git;a=commitdiff;h=eccc068e8e84c8fe997115629925e0422a98e4de
> >> > was applied txpower is limited to 0 for these devices.
> >> >
> >> > This should be the proper fix compared to the net/wireless/reg.c
> >> > hack in http://patchwork.openwrt.org/patch/2165/
> >>
> >> Btw. Tobias, did this affect the real tx power of the device at all or
> >> is this just
> >> a cosmetic issue?
> >
> > Hmm, apparently setting txpower has no effect?
> > Is it not implemented in the driver?
> 
> It is, but only for devices with correct tx power limit in the eeprom.

Why?
Lowering the tx power should never be an issue, right?
Or are you saying I'm stuck with 0dBm txpower?
That would be an issue by itself.
Why not use min(hw defaults, regulatory limits) as maximum if there is
no limit in the eeprom?
Do I have to add an eeprom fixup that will insert valid txpower
limit bytes as an additional step after the eeprom extraction from flash
to make this work?

-- 
Tobias						PGP: http://8ef7ddba.uguu.de

Re: [PATCH] rt2800: Initialize max_txpower to MAX_G_TXPOWER and MAX_A_TXPOWER respectively

[Helmut Schaa]

Hi,

On Wed, May 23, 2012 at 3:55 PM, Tobias Diedrich
<ranma+openwrt@tdiedrich.de> wrote:
> Helmut Schaa wrote:
>> On Tue, May 22, 2012 at 10:58 PM, Tobias Diedrich
>> <ranma+openwrt@tdiedrich.de> wrote:
>> > Helmut Schaa wrote:
>> >> On Fri, May 18, 2012 at 1:04 AM, Tobias Diedrich
>> >> <ranma+openwrt@tdiedrich.de> wrote:
>> >> > rt2800: Initialize max_txpower to MAX_G_TXPOWER and MAX_A_TXPOWER
>> >> > respectively, similar to how it is already done in rt2[45]00pci.c
>> >> >
>> >> > rt2800lib.c doesn't initialize max_power and thus after
>> >> > http://git.kernel.org/?p=linux/kernel/git/linville/wireless-next.git;a=commitdiff;h=eccc068e8e84c8fe997115629925e0422a98e4de
>> >> > was applied txpower is limited to 0 for these devices.
>> >> >
>> >> > This should be the proper fix compared to the net/wireless/reg.c
>> >> > hack in http://patchwork.openwrt.org/patch/2165/
>> >>
>> >> Btw. Tobias, did this affect the real tx power of the device at all or
>> >> is this just
>> >> a cosmetic issue?
>> >
>> > Hmm, apparently setting txpower has no effect?
>> > Is it not implemented in the driver?
>>
>> It is, but only for devices with correct tx power limit in the eeprom.
>
> Why?

Please read [1] for a detailed explanation.

> Lowering the tx power should never be an issue, right?

Yes but only on by percentage since we don't know the tx power the
device was calibrated for.

> Or are you saying I'm stuck with 0dBm txpower?

No, your stuck with the tx power the device was calibrated for by the
manufacturer,
and the manufacturer did not intend to allow users to program arbitrary tx power
values (in terms of dBm or mW) into the hw.

So, your device might be calibrated to let's say 18dBm but the device
doesn't provide
this information to the driver at all. Hence, we cannot apply a tx
power of 16dBm to the
device. We could however reduce the real tx power by for example 50%
(= -3dBm) but
still we don't know the resulting discrete value. We only know we
reduced the tx power
by 3dBm.

> That would be an issue by itself.
> Why not use min(hw defaults, regulatory limits) as maximum if there is
> no limit in the eeprom?

See above and [1].

> Do I have to add an eeprom fixup that will insert valid txpower
> limit bytes as an additional step after the eeprom extraction from flash
> to make this work?

If you know the tx power limit your device is calibrated for you could actually
do this. However, I wouldn't suggest to do that ...

Helmut

[1] http://www.spinics.net/lists/linux-wireless/msg90718.html

Re: [PATCH] rt2800: Initialize max_txpower to MAX_G_TXPOWER and MAX_A_TXPOWER respectively

[Tobias Diedrich]

Helmut Schaa wrote:
> Hi,
> 
> On Wed, May 23, 2012 at 3:55 PM, Tobias Diedrich
> <ranma+openwrt@tdiedrich.de> wrote:
> > Helmut Schaa wrote:
> >> On Tue, May 22, 2012 at 10:58 PM, Tobias Diedrich
> >> <ranma+openwrt@tdiedrich.de> wrote:
> >> > Helmut Schaa wrote:
> >> >> On Fri, May 18, 2012 at 1:04 AM, Tobias Diedrich
> >> >> <ranma+openwrt@tdiedrich.de> wrote:
> >> >> > rt2800: Initialize max_txpower to MAX_G_TXPOWER and MAX_A_TXPOWER
> >> >> > respectively, similar to how it is already done in rt2[45]00pci.c
> >> >> >
> >> >> > rt2800lib.c doesn't initialize max_power and thus after
> >> >> > http://git.kernel.org/?p=linux/kernel/git/linville/wireless-next.git;a=commitdiff;h=eccc068e8e84c8fe997115629925e0422a98e4de
> >> >> > was applied txpower is limited to 0 for these devices.
> >> >> >
> >> >> > This should be the proper fix compared to the net/wireless/reg.c
> >> >> > hack in http://patchwork.openwrt.org/patch/2165/
> >> >>
> >> >> Btw. Tobias, did this affect the real tx power of the device at all or
> >> >> is this just
> >> >> a cosmetic issue?
> >> >
> >> > Hmm, apparently setting txpower has no effect?
> >> > Is it not implemented in the driver?
> >>
> >> It is, but only for devices with correct tx power limit in the eeprom.
> >
> > Why?
> 
> Please read [1] for a detailed explanation.

It still seems somewhat handwavy, I suppose what it means is:
You get a default value for the txpower controlling registers
from the eeprom (which is your 'calibration value'), but don't
actually know how much this is in dBm, so you don't want to
expose a 'fake' dBm value just so it's adjustable by the user (until
percentage setting is implemented).

And I suppose it's more about the antenna gain and attenuation of
the path between RT3050 and antenna than about what comes out of the
SoC directly (which was more what I was thinking about initially).

Thanks for the patience. :)

-- 
Tobias						PGP: http://8ef7ddba.uguu.de