2012/8/5 Tobias Diedrich <ranma+open...@tdiedrich.de>:
> Nick Kossifidis wrote:
>> 2012/8/5 Tobias Diedrich <ranma+open...@tdiedrich.de>:
>> > Nick Kossifidis wrote:
>> >> 2012/8/5 Tobias Diedrich <ranma+open...@tdiedrich.de>:
>> >> > Fix two small issues with user txpower setting
>> >> >
>> >> > 1)
>> >> > ath5k is not setting max_power in the channel info, I'm using
>> >> > AR5K_TUNE_MAX_TXPOWER/2 (31dBm) as the default in this patch.
>> >>
>> >> Is that ath5k's job or should the upper layers do it ?
>> >
>> > I think it's ath5k's job, but I'm no expert in this.
>> > The behaviour of the upper layers regarding this changed in January,
>> > I believe previously it was not necessary to set it:
>> > http://git.kernel.org/?p=linux/kernel/git/linville/wireless-next.git;a=commitdiff;h=eccc068e8e84c8fe997115629925e0422a98e4de
>> >
>> > Grepping for max_power in net/wireless I see most other drivers
>> > setting it, for example:
>> > ath/ath6kl/cfg80211.c:  .max_power      = 30,
>> > ath/ath9k/hw.c:         channel->max_power = MAX_RATE_POWER / 2;
>> > b43/main.c:     .max_power              = 30,
>> > \
>> > ti/wlcore/main.c:       { .hw_value = 1, .center_freq = 2412,
>> > .max_power = 25 },
>> >
>>
>> According to that changeset this is the maximum allowed tx power, not
>> the maximum power the hw can trasmit at so either the documentation is
>> wrong or the drivers doing that are wrong. Maybe we should ask on
>> linux-wireless about it.
>>
>> >> > 2)
>> >> > The newly added ah->ah_txpower.txp_user_pwr gets reset on channel
>> >> > change, save the value and restore it after clearing the ah_txpower
>> >> > struct.
>> >>
>> >> There is no such variable on ath5k, maybe on openwrt but not on
>> >> wireless-testing, we use a different one with a recent patch but you
>> >> are right about memset, I'll have to fix that.
>> >
>> > I tried this against wireless-next that I pulled yesterday and it
>> > has txp_user_pwr.
>> >
>> > Cheers,
>> >
>>
>> Are you sure ? I checked wireless-testing yesterday and there is no
>> such variable, unless something weird is going on in wireless-next I
>> don't know when this came up.
>
> Whoops, my bad, you're right.
> It's coming from the 300-pending_work.patch to wireless-compat in the
> OpenWRT sources, which I assumed was wireless-next...
>

No worries, thanks for catching that memset ;-)


-- 
GPG ID: 0xEE878588
As you read this post global entropy rises. Have Fun ;-)
Nick
_______________________________________________
ath5k-devel mailing list
ath5k-devel@lists.ath5k.org
https://lists.ath5k.org/mailman/listinfo/ath5k-devel

Reply via email to