During IBSS session tear down, we are hitting a lockup. The issue is
seen as the pdev->peer_ref_mutex is being taken up twice in
ol_txrx_remove_peers_for_vdev and ol_txrx_peer_unref_delete. The later
function gets invoked by the former and hence we are stuck while trying
to acquire the spinlock, the second time.
Fix issue by releasing peer_ref_mutex lock before invoking
callback (wma_remove_peer) in ol_txrx_remove_peers_for_vdev function.
The dmesg signature of the lock-up is as follows
1100.230392: <2> [<ffffffc0002035a4>] el1_irq+0x64/0xd4
1100.235432: <2> [<ffffffbffc17e890>]
ol_txrx_peer_unref_delete+0xc4/0x33c [wlan]
1100.242461: <2> [<ffffffbffc17ecc8>] ol_txrx_peer_detach+0x1c0/0x1e0
[wlan]
1100.249020: <2> [<ffffffbffc160914>] wma_remove_peer+0x7c/0x18c
[wlan]
1100.255141: <2> [<ffffffbffc17dee4>]
ol_txrx_remove_peers_for_vdev+0x170/0x1b0 [wlan]
1100.262606: <2> [<ffffffbffc16311c>]
wma_vdev_stop_resp_handler+0x204/0x460 [wlan]
1100.269816: <2> [<ffffffbffc1886a8>] __wmi_control_rx+0x280/0x2c0
[wlan]
1100.276204: <2> [<ffffffbffc188a34>] wmi_process_fw_event+0x8/0x14
[wlan]
1100.282595: <2> [<ffffffbffc157054>] wma_mc_process_msg+0x80c/0x27fc
[wlan]
1100.289176: <2> [<ffffffbffc13f238>] $x+0x190/0x3f4 [wlan]
1100.294115: <2> [<ffffffc00023d7e8>] kthread+0xac/0xb8
CRs-Fixed: 1006847
Change-Id: Icedeb172bbd6736ab39343391ff0643ddd688444
137b97dd46