diff options
author | Jon Medhurst <tixy@linaro.org> | 2015-10-27 13:36:11 +0000 |
---|---|---|
committer | Jon Medhurst <tixy@linaro.org> | 2015-11-10 18:21:26 +0000 |
commit | 4ec4d0edbd837a0506487b02d9d70261bdb69249 (patch) | |
tree | 8525b116deab3b1222794d91c87fd884f8086883 /28b2f3b4f13e86596650228401ed1e9e02e21575 | |
parent | 46a8577b456a0ae20d71749e40696a35719610a6 (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