Fix race condition in gatekeeper ipc
Current trusty ipc logic (trusty/kernel/lib/trusty/tipc_virtio_dev.c)
drops a message on a channel when its receive fifo is full
(the receive fifo size is determined by the argument `recv_buf_size`
passed in the port_create api).
Filling the receive fifo can only happen when a new message
is received while the previous one has not been retired yet
(via a call to put_msg).
HAL to TA IPC won't hit this issue when following the recommended pattern:
- send a message
- wait for its response
- send the next message.
- receive a message
- retire it from the receive fifo
- then send the response.
Prior to this fix, gatekeeper TA used to send the response THEN retire
the message, while having a receive fifo size of 1.
This creates the race condition where the message would be dropped.
The fix consists in retiring the message (put_msg) prior to sending
1 file changed