aboutsummaryrefslogtreecommitdiff
path: root/28b2f3b4f13e86596650228401ed1e9e02e21575
diff options
context:
space:
mode:
authorJon Medhurst <tixy@linaro.org>2015-10-27 13:36:11 +0000
committerJon Medhurst <tixy@linaro.org>2015-11-10 18:21:26 +0000
commit4ec4d0edbd837a0506487b02d9d70261bdb69249 (patch)
tree8525b116deab3b1222794d91c87fd884f8086883 /28b2f3b4f13e86596650228401ed1e9e02e21575
parent46a8577b456a0ae20d71749e40696a35719610a6 (diff)
firmware: arm_scpi: Properly implement wait for messages to complete
scpi_send_message is broken for a least two reasons. 1. The driver sets tx_block on the mailbox client and expects mbox_send_message to block until the message is sent, however this isn't the case. Whether by design or in error, mbox_send_message waits for tx_complete which will be signalled when any message is transmitted, not the one just queued. So in the case where two threads send messages concurrently, one thread may see the signal from the other's message completing, whilst it's message is still in the queue. 2. The second flaw is that even if the mailbox framework was waiting for the correct message signal the driver has set a timeout (mailbox client tx_tout) which means the wait for that signal may be aborted whilst the message is still in the queue for sending. Both the above mean that when mbox_send_message returns the message may still be pending transmission so we cannot safely do anything with its resources. The current code however goes on to free the message with put_scpi_xfer resulting in all sorts of bugs. To fix this, we add code to do a proper wait for the message to complete and if a timeout occurs BUG because we don't have any way to cancel messages in the queue. Signed-off-by: Jon Medhurst <tixy@linaro.org>
Diffstat (limited to '28b2f3b4f13e86596650228401ed1e9e02e21575')
0 files changed, 0 insertions, 0 deletions