msm: vidc: handle dynamic buffers in pendingq during flush

In dynamic buffer mode, if flush was received before
stream-on, driver would have incremented the ref count
for output buffers, but not yet sent to firmware. So,
after flush done, there would be no fbd from firmware
and the reference to these buffers would not be removed.
So when the buffers are dequeued, driver fails to
unmap and free the output buffers.
Subsequently, after flush done, when client queues
the same output buffers again to driver, the ref
count is increased and becomes 2. This results in
the driver holding the buffers with itself, thereby
entering in to a deadlock situation and starving the
firmware of output buffers. This results in a video
freeze.

b/17647776

Change-Id: I0c3d13124bd48b900e56e14666eaed2f0e7ee9d6
Signed-off-by: Arun Menon <avmenon@codeaurora.org>
msm: vidc: fix corruption of registered buffer list

The buffer list for output buffers is accessed from
different threads leading to race conditions. Consider
the case of firmware throwing up a fatal error, which gets
propagated to v4l2 client. The v4l2 client closes the
driver fd, which will trigger msm_vidc_release_buffers
to release all output buffers and free node from
the registered buffer list. During this time, if
firmware sends a release reference event, the buffer
node being accessed in msm_vidc_release_buffers could
be freed, triggering kernel panic.

Change-Id: I522edff06a62dbc2ab60d6cca5990babb18d5c6c
Signed-off-by: Arun Menon <avmenon@codeaurora.org>
net: wireless: bcmdhd: Fix Batch scan get bug

Legacy Batch scan code would issue mutex unlock w/o a lock

bug: 17021370

Signed-off-by: Ashwin <ashwin.bhat@broadcom.com>