| Message ID | ca3c90022f0ffa24b267418ec280dbee38be0986.1399450779.git.jithu@broadcom.com |
|---|---|
| State | Changes Requested |
| Headers | show |
On Wed, May 07, 2014 at 02:02:06PM +0530, Jithu Jance wrote: > If p2p_listen is called while previous listen command's > remain_on_channel event is pending, the p2p_listen would fail > and it used to clear pending_listen_freq. Now when the remain- > on-channel event comes from the driver, the pending_listen_freq > doesn't match and gets ignored. This was leading to a case > where listen state was getting stuck (in case of WAIT_PEER_CONNECT > state). > diff --git a/src/p2p/p2p.c b/src/p2p/p2p.c > @@ -284,6 +284,12 @@ int p2p_listen(struct p2p_data *p2p, unsigned int timeout) > p2p_dbg(p2p, "Going to listen(only) state"); > > + if (p2p->pending_listen_freq) { > + /* We have a pending p2p_listen request */ > + p2p_dbg(p2p, "p2p_listen command pending already"); > + return -1; > + } This seems to be causing failures in hwsim test cases. I'm not completely sure why, but the logs seems to imply that this case is hit and the P2P state machine is then stuck in waiting for something that never happens. It looks like this can happen at least when P2P_LISTEN is issued while a p2p_scan from a previously started P2P_FIND is in progress.
diff --git a/src/p2p/p2p.c b/src/p2p/p2p.c index b30ea56..3efc071 100644 --- a/src/p2p/p2p.c +++ b/src/p2p/p2p.c @@ -284,6 +284,12 @@ int p2p_listen(struct p2p_data *p2p, unsigned int timeout) p2p_dbg(p2p, "Going to listen(only) state"); + if (p2p->pending_listen_freq) { + /* We have a pending p2p_listen request */ + p2p_dbg(p2p, "p2p_listen command pending already"); + return -1; + } + freq = p2p_channel_to_freq(p2p->cfg->reg_class, p2p->cfg->channel); if (freq < 0) { p2p_dbg(p2p, "Unknown regulatory class/channel");