[rt2x00-users] [RFC] Limit txpower by eeprom values
Ivo Van Doorn
ivdoorn at gmail.com
Thu Jun 17 20:04:29 UTC 2010
>>>> Limit the txpower per rate by the approriate values in the eeprom.
>>>> This avoids too high txpower values resulting in bad tx performance.
>>>> Signed-off-by: Helmut Schaa <helmut.schaa at googlemail.com>
>>>> I don't like this patch at all but I wasn't able to come up with a more
>>>> readable version either -> Sending as RFC.
>>>> Maybe somebody else has a better idea on how to make the code readable
>>>> and nice.
>>> Wouldn't it be better to put the txpower_byrate array as part of the rt2x00dev structure,
>>> and read the EEPROM values at initialization time (e.g. from rt2800_eeprom_validate)?
>>> In that way we only have to build up the array once, and we can use it many times afterwards.
>> I just talked with Helmut about it, and we can't do this at initialization time.
>> The eeprom reading is also occuring from an allocated array, rather
>> then the EEPROM hardware,
>> so keeping another array with a copy is redundant information.
>> Building the array is a per-txpower setting, this means it must be
>> build during each TX power
>> configuration call. It might not be the nicest approach, but
>> unfortunately, there is no real alternative.
>> This means my only objection to the patch would be the array of 36
>> elements which is thrown right
>> on the stack rather then allocated. Perhaps it can be broken up into
>> an array of 8 elements,
>> which we initialize per register (TX_PWR_CFG_1, TX_PWR_CFG_2,
>> TX_PWR_CFG_3, TX_PWR_CFG_4)
>> rather then everything in a single large array.
> Hmmm, building up that array each time we have to configure the txpower seems like a lot of
> overhead to me. And now we have made it even worse by using kmalloc for it as well.
True, but the large framestack was also not something we would want.
> However, as the patch already has been merged in rt2x00.git, I will create a follow-up patch
> to clean this up a bit, whereby EEPROM array is read when programming the CSR values, rather
> than first creating an array, and then using that array when programming the CSR value, thereby
> eliminating the need for the array and the kzalloc call.
Well I can pull the patch out of rt2x00.git, and you can provide an
revised patch if you want...
More information about the users