8e294c3a2c
It is possible for the start_listen() callback to be called to request the driver to start a driver operation and stop_listen() called immediately after that (e.g., due to a request to transmit a P2P Public Action frame) before the driver has had time to start ROC and send an event to notify of that. Such a sequence could result in p2p->pending_listen_freq being left to a nonzero value without getting a call to p2p_listen_cb() to clear it. This would stop an ongoing P2P listen operation since no following p2p_listen() call would start the listen due to the pending command being assumed to be in effect. Fix this by detecting this particular sequence and clearing p2p->pending_listen_freq. This was found with the p2p_listen_and_offchannel_tx test case with the new kernel scheduled and UML time-travel. Signed-off-by: Jouni Malinen <j@w1.fi> |
||
|---|---|---|
| .. | ||
| Makefile | ||
| p2p.c | ||
| p2p.h | ||
| p2p_build.c | ||
| p2p_dev_disc.c | ||
| p2p_go_neg.c | ||
| p2p_group.c | ||
| p2p_i.h | ||
| p2p_invitation.c | ||
| p2p_parse.c | ||
| p2p_pd.c | ||
| p2p_sd.c | ||
| p2p_utils.c | ||