Checking arrival in RX_ON races with incoming traffic. If frame
reception begins before we have a chance to see that we've arrived
in RX_ON, at86rf230_state complains about unexpectedly finding the
transceiver in BUSY_RX.
This isn't the prettiest solution (and it doesn't check if we're
in BUSY_RX before even commanding the change, although I think
this shouldn't happen), but it makes the problem go away.
Signed-off-by: Werner Almesberger <wer...@almesberger.net>
---
drivers/ieee802154/at86rf230.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/ieee802154/at86rf230.c b/drivers/ieee802154/at86rf230.c
index 12c900a..1411447 100644
--- a/drivers/ieee802154/at86rf230.c
+++ b/drivers/ieee802154/at86rf230.c
@@ -322,6 +322,8 @@ at86rf230_state(struct ieee802154_dev *dev, int state)
if (val == desired_status)
return 0;
+ if (state == STATE_RX_ON && val == STATE_BUSY_RX)
+ return 0;
pr_err("%s unexpected state change: %d, asked for %d\n", __func__,
val, state);
--
1.7.0.4
------------------------------------------------------------------------------
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2d-c2
_______________________________________________
Linux-zigbee-devel mailing list
Linux-zigbee-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-zigbee-devel
