[ath9k-devel] TX99 unreliable start sequence

[Mathieu Slabbinck]

Hi,

I was looking into the TX99 module recently and found that it was not
always starting properly.
If for example echo 1 > tx99 is done, the wireless module would not start
transmitting in all attempts. Even though a cat of tx99 is responding with
1.
Do the same command again (without modifying anything else) and the odds
increase of the module starting to transmit...

Since this was something annoying, I was investigating the write_file_tx99
function which seems to be the cause of the improper handling.
I've created the patch below and it responds much more reliable. Each
request is properly sending out RF waves.

--- a/drivers/net/wireless/ath/ath9k/tx99.c
+++ b/drivers/net/wireless/ath/ath9k/tx99.c
@@ -191,23 +191,14 @@ static ssize_t write_file_tx99(struct file *file,
const char __user *user_buf,
if (strtobool(buf, &start))
return -EINVAL;

- if (start == sc->tx99_state) {
- if (!start)
- return count;
- ath_dbg(common, XMIT, "Resetting TX99\n");
- ath9k_tx99_deinit(sc);
- }
-
- if (!start) {
- ath9k_tx99_deinit(sc);
- return count;
- }
-
- r = ath9k_tx99_init(sc);
- if (r)
- return r;
-
- return count;
+ if (start) {
+ ath9k_tx99_deinit(sc);
+ r = ath9k_tx99_init(sc);
+ }
+ else {
+ ath9k_tx99_deinit(sc);
+ }
+ return count;
}

I'm now just wondering if anyone knows why this piece of code was made this
way the first place, as I'm sure it had a purpose...

Kr

Mathieu

[Eduardo Abinader]

The reason behind that, I think, is due to the fact that you have to
echo 1 > tx99_power, before setting tx99.

Eduardo

On Wed, Sep 7, 2016 at 10:07 PM, Mathieu Slabbinck

Hi,
I was looking into the TX99 module recently and found that it was not always
starting properly.
If for example echo 1 > tx99 is done, the wireless module would not start
transmitting in all attempts. Even though a cat of tx99 is responding with
1.
Do the same command again (without modifying anything else) and the odds
increase of the module starting to transmit...
Since this was something annoying, I was investigating the write_file_tx99
function which seems to be the cause of the improper handling.
I've created the patch below and it responds much more reliable. Each
request is properly sending out RF waves.
--- a/drivers/net/wireless/ath/ath9k/tx99.c
+++ b/drivers/net/wireless/ath/ath9k/tx99.c
@@ -191,23 +191,14 @@ static ssize_t write_file_tx99(struct file *file,
const char __user *user_buf,
if (strtobool(buf, &start))
return -EINVAL;
- if (start == sc->tx99_state) {
- if (!start)
- return count;
- ath_dbg(common, XMIT, "Resetting TX99\n");
- ath9k_tx99_deinit(sc);
- }
-
- if (!start) {
- ath9k_tx99_deinit(sc);
- return count;
- }
-
- r = ath9k_tx99_init(sc);
- if (r)
- return r;
-
- return count;
+ if (start) {
+ ath9k_tx99_deinit(sc);
+ r = ath9k_tx99_init(sc);
+ }
+ else {
+ ath9k_tx99_deinit(sc);
+ }
+ return count;
}
I'm now just wondering if anyone knows why this piece of code was made this
way the first place, as I'm sure it had a purpose...
Kr
Mathieu
_______________________________________________
ath9k-devel mailing list
https://lists.ath9k.org/mailman/listinfo/ath9k-devel

[Eduardo Abinader]

Actually, echo $power > tx99_power

On Thu, Sep 8, 2016 at 3:08 PM, Eduardo Abinader

Post by Eduardo Abinader
The reason behind that, I think, is due to the fact that you have to
echo 1 > tx99_power, before setting tx99.
Eduardo
On Wed, Sep 7, 2016 at 10:07 PM, Mathieu Slabbinck

Hi,
I was looking into the TX99 module recently and found that it was not always
starting properly.
If for example echo 1 > tx99 is done, the wireless module would not start
transmitting in all attempts. Even though a cat of tx99 is responding with
1.
Do the same command again (without modifying anything else) and the odds
increase of the module starting to transmit...
Since this was something annoying, I was investigating the write_file_tx99
function which seems to be the cause of the improper handling.
I've created the patch below and it responds much more reliable. Each
request is properly sending out RF waves.
--- a/drivers/net/wireless/ath/ath9k/tx99.c
+++ b/drivers/net/wireless/ath/ath9k/tx99.c
@@ -191,23 +191,14 @@ static ssize_t write_file_tx99(struct file *file,
const char __user *user_buf,
if (strtobool(buf, &start))
return -EINVAL;
- if (start == sc->tx99_state) {
- if (!start)
- return count;
- ath_dbg(common, XMIT, "Resetting TX99\n");
- ath9k_tx99_deinit(sc);
- }
-
- if (!start) {
- ath9k_tx99_deinit(sc);
- return count;
- }
-
- r = ath9k_tx99_init(sc);
- if (r)
- return r;
-
- return count;
+ if (start) {
+ ath9k_tx99_deinit(sc);
+ r = ath9k_tx99_init(sc);
+ }
+ else {
+ ath9k_tx99_deinit(sc);
+ }
+ return count;
}
I'm now just wondering if anyone knows why this piece of code was made this
way the first place, as I'm sure it had a purpose...
Kr
Mathieu
_______________________________________________
ath9k-devel mailing list
https://lists.ath9k.org/mailman/listinfo/ath9k-devel

[Mathieu Slabbinck]

Thanks for the feedback Eduardo,

but this is indeed what I do.
Each test sequence consists of setting all values needed (including the
power), and afterwards, trying to echo 1 > tx99.
This still shows the issue.

Kr

Mathieu

Post by Eduardo Abinader
Actually, echo $power > tx99_power
On Thu, Sep 8, 2016 at 3:08 PM, Eduardo Abinader

Post by Eduardo Abinader
The reason behind that, I think, is due to the fact that you have to
echo 1 > tx99_power, before setting tx99.
Eduardo
On Wed, Sep 7, 2016 at 10:07 PM, Mathieu Slabbinck

Post by Mathieu Slabbinck
Hi,
I was looking into the TX99 module recently and found that it was not

always

Post by Eduardo Abinader

Post by Mathieu Slabbinck
starting properly.
If for example echo 1 > tx99 is done, the wireless module would not

start

Post by Eduardo Abinader

Post by Mathieu Slabbinck
transmitting in all attempts. Even though a cat of tx99 is responding

with

Post by Eduardo Abinader

Post by Mathieu Slabbinck
1.
Do the same command again (without modifying anything else) and the odds
increase of the module starting to transmit...
Since this was something annoying, I was investigating the

write_file_tx99

Post by Eduardo Abinader

Post by Mathieu Slabbinck
function which seems to be the cause of the improper handling.
I've created the patch below and it responds much more reliable. Each
request is properly sending out RF waves.
--- a/drivers/net/wireless/ath/ath9k/tx99.c
+++ b/drivers/net/wireless/ath/ath9k/tx99.c
@@ -191,23 +191,14 @@ static ssize_t write_file_tx99(struct file *file,
const char __user *user_buf,
if (strtobool(buf, &start))
return -EINVAL;
- if (start == sc->tx99_state) {
- if (!start)
- return count;
- ath_dbg(common, XMIT, "Resetting TX99\n");
- ath9k_tx99_deinit(sc);
- }
-
- if (!start) {
- ath9k_tx99_deinit(sc);
- return count;
- }
-
- r = ath9k_tx99_init(sc);
- if (r)
- return r;
-
- return count;
+ if (start) {
+ ath9k_tx99_deinit(sc);
+ r = ath9k_tx99_init(sc);
+ }
+ else {
+ ath9k_tx99_deinit(sc);
+ }
+ return count;
}
I'm now just wondering if anyone knows why this piece of code was made

this

Post by Eduardo Abinader

Post by Mathieu Slabbinck
way the first place, as I'm sure it had a purpose...
Kr
Mathieu
_______________________________________________
ath9k-devel mailing list
https://lists.ath9k.org/mailman/listinfo/ath9k-devel