P2P: Continue P2P_WAIT_PEER_(IDLE/CONNECT) sequence on a listen cancel

Some drivers may accept the remain-on-channel command, but instead of
indicating start event for remain-on-channel, just indicate that the
operation has been canceled immediately. This listen cancel from the
WAIT_PEER_CONNECT state ended up in discontinuation of further
WAIT_PEER_IDLE/WAIT_PEER_CONNECT state transitions. Hence, delay the
subsequent IDLE state by 100 ms.

Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>

diff --git a/src/p2p/p2p.c b/src/p2p/p2p.c
index 1a31ef2c813d620804ebb7090cb92d077bb83320..b4660c4f9616e6b06817769280e7e03a136f8aee 100644 (file)
--- a/src/p2p/p2p.c
+++ b/src/p2p/p2p.c
@@ -3889,6 +3889,19 @@ int p2p_listen_end(struct p2p_data *p2p, unsigned int freq)
        if (p2p->in_listen)
                return 0; /* Internal timeout will trigger the next step */
 
+       if (p2p->state == P2P_WAIT_PEER_CONNECT && p2p->go_neg_peer &&
+           p2p->pending_listen_freq) {
+               /*
+                * Better wait a bit if the driver is unable to start
+                * offchannel operation for some reason to continue with
+                * P2P_WAIT_PEER_(IDLE/CONNECT) state transitions.
+                */
+               p2p_dbg(p2p,
+                       "Listen operation did not seem to start - delay idle phase to avoid busy loop");
+               p2p_set_timeout(p2p, 0, 100000);
+               return 1;
+       }
+
        if (p2p->state == P2P_CONNECT_LISTEN && p2p->go_neg_peer) {
                if (p2p->go_neg_peer->connect_reqs >= 120) {
                        p2p_dbg(p2p, "Timeout on sending GO Negotiation Request without getting response");