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>
This commit is contained in:
Sunil Dutt 2017-10-09 20:02:20 +05:30 committed by Jouni Malinen
parent 37ed3254de
commit bb9808fa9f

View file

@ -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");