Generally below process should happen in renegotiation failure
case.
1. TWT setup (successful)
2. TWT setup (renegotiation failure)
3. TWT teardown
4. TWT GET STATUS - 0(dialog ID) 0 0 0
5. TWT setup - successful
Since all WMI TWT events gets executed in WMI thread. So when
renegotiation failure case hits, driver sends TWT
teardown to firmware and waits for twt ack in worker thread.
In same worker thread TWT event needs to be processed.
TWT ack event will not process as it's waiting in same worker
thread and it will get timedout.
As part of fix, break the context in renegotiation and
send the teardown in the new worker context.
Change-Id: Id12cb906b780d3013562c1772e276639a056c8f7
CRs-Fixed: 3207537
Peer MAC address is not specified when get_peer_by_mac fails.
We should print the peer MAC address with debug message.
Change-Id: I5f559e6ba7373e8fef851f8035008cfaba8a3574
CRs-Fixed: 3155419
When host sends TWT disable command to firmware, send reason code
also as part of it. So that firmware will check and take the
following action:
a. If host sends disable due SCC/MCC concurrency then firmware
will teardown the existing TWT session and send the teardown
reason code as concurrency to host.
b. If it's for other reason then it will take action based on
that.
Change-Id: I5b4584a964f142d17aef5629adeb12e686fd983c
CRs-Fixed: 3098862
