diff mbox

ath6kl: Allow the radio to report 0 dbm txpower without timing out

Message ID 1472537779-3723-1-git-send-email-eric.bentley@lairdtech.com (mailing list archive)
State Accepted
Commit cabd34d0e9c47ac8747e7a1d871e10acdb8e980f
Delegated to: Kalle Valo
Headers show

Commit Message

Eric Bentley Aug. 30, 2016, 6:16 a.m. UTC
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@lairdtech.com>
---
 drivers/net/wireless/ath/ath6kl/cfg80211.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

Comments

Kalle Valo Aug. 30, 2016, 6:28 a.m. UTC | #1
Eric Bentley <eric.bentley@lairdtech.com> 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@lairdtech.com>

This is perfect now, thanks. I'll just remove the "--" line from the
commit log, that looks a bit weird.
Kalle Valo Sept. 9, 2016, 12:14 p.m. UTC | #2
Eric Bentley <eric.bentley@lairdtech.com> wrote:
> 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.

Thanks, 1 patch applied to ath-next branch of ath.git:

cabd34d0e9c4 ath6kl: Allow the radio to report 0 dbm txpower without timing out
diff mbox

Patch

diff --git a/drivers/net/wireless/ath/ath6kl/cfg80211.c b/drivers/net/wireless/ath/ath6kl/cfg80211.c
index 72e2ec6..b7fe0af 100644
--- a/drivers/net/wireless/ath/ath6kl/cfg80211.c
+++ b/drivers/net/wireless/ath/ath6kl/cfg80211.c
@@ -1449,14 +1449,14 @@  static int ath6kl_cfg80211_get_txpower(struct wiphy *wiphy,
 		return -EIO;
 
 	if (test_bit(CONNECTED, &vif->flags)) {
-		ar->tx_pwr = 0;
+		ar->tx_pwr = 255;
 
 		if (ath6kl_wmi_get_tx_pwr_cmd(ar->wmi, vif->fw_vif_idx) != 0) {
 			ath6kl_err("ath6kl_wmi_get_tx_pwr_cmd failed\n");
 			return -EIO;
 		}
 
-		wait_event_interruptible_timeout(ar->event_wq, ar->tx_pwr != 0,
+		wait_event_interruptible_timeout(ar->event_wq, ar->tx_pwr != 255,
 						 5 * HZ);
 
 		if (signal_pending(current)) {