its_cmd_send may return prior to command being completed

[wma_semihalf.com]

Summary

its_cmd_wait_completion has been called to await command being completed
with a cmd_last argument taken from gic_v3_its_softc->its_cmdq_write,
which should be last command allocated; this would work with one core
environment, but in mlti-core environment this varible may be altered
as soon as lock is released (by another allocation) from sc inside
its_cmd_send, just before its_cmd_wait_completion is called;
because its_cmdq_write points into ring buffer, it might happen that
its_cmd_wait_completion decides that command has been comleted,
not because it has been returned by GIC as completed, but because
the range it has been compared to (cmd_last) has changed to fulfill
the condition for completion.  This would brake synchronization with other
commands as its_cmd_send would be expected to return only on the command
that it has been sending has completed.
Simple solution to that was just copy the pointer gic_v3_its_softc->its_cmdq_write
to temporary variable and provided it to its_cmd_wait_completion as
cmd_last (when there is mutex still locked around sc); this way changes
to its_cmdq_write pointer would not alter the completion condition
in its_cmd_wait_completion.