Eric Bentley <eric.bentley@xxxxxxxxxxxxx> writes: > The ath6kl driver attempts to get the txpower value from the radio by first > clearing the existing stored value and then watching the value to become > non-zero. > > APs allow setting client power to values from -127..127, but this radio > is not capable of setting values less then 0 and so will report txpower > as 0dbm for both negative and 0 client power values. > > When the radio has txpower set to 0dbm txpower (equivalent to 1mw) the > ath6kl_cfg80211_get_txpower() function will remain in the > wait_event_interruptible_timeout() loop waiting for the value to be > non-zero, and will eventually timeout. This results in a 5 second delay in > response. However, the correct value of zero is eventually returned. > > The 6004 defaults to 63dbm which is then limited by regulatory and > hardware limits with max of 18dbm (6003 max is 16dbm), therefore we can > use values larger then these to be able to determine when the value has > been updated. > > To correct the issue, set the value to a nonsensical value (255) and wait > for it to change to the valid value. > > -- > Tested on both 6003 and 6004 based radios. Return value of zero is > correctly returned in an expected amount of time (similar to when > returning non-zero values) when AP client power is set to both 0 and > negative values. > > Signed-off-by: Eric Bentley <eric.bentley@xxxxxxxxxxxxx> This is perfect now, thanks. I'll just remove the "--" line from the commit log, that looks a bit weird. -- Kalle Valo
