diff options
author | Bjorn Andersson <quic_bjorande@quicinc.com> | 2023-03-27 17:46:17 +0300 |
---|---|---|
committer | Bjorn Andersson <andersson@kernel.org> | 2023-04-19 22:43:19 +0300 |
commit | c05dfce0b89e3b58043805b6f4bdf30e3561d867 (patch) | |
tree | 837e31a4b31aef9f96e7532b75e8542484746542 /drivers/opp | |
parent | 0a7eee89e79eb8b97d46e1e0001b9e2709795af5 (diff) | |
download | linux-c05dfce0b89e3b58043805b6f4bdf30e3561d867.tar.xz |
rpmsg: glink: Wait for intent, not just request ack
In some implementations of the remote firmware, an intent request
acknowledgment is sent when it's determined if the intent allocation
will be fulfilled, but then the intent is queued after the
acknowledgment.
The result is that upon receiving a granted allocation request, the
search for the newly allocated intent will fail and an additional
request will be made. This will at best waste memory, but if the second
request is rejected the transaction will be incorrectly rejected.
Take the incoming intent into account in the wait to mitigate this
problem.
The above scenario can still happen, in the case that, on that same
channel, an unrelated intent is delivered prior to the request
acknowledgment and a separate process enters the send path and picks up
the intent. Given that there's no relationship between the
acknowledgment and the delivered (or to be delivered intent), there
doesn't seem to be a solution to this problem.
Signed-off-by: Bjorn Andersson <quic_bjorande@quicinc.com>
Reviewed-by: Chris Lew <quic_clew@quicinc.com>
[bjorn: Fixed spelling issues pointed out by checkpatch in commit message]
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20230327144617.3134175-3-quic_bjorande@quicinc.com
Diffstat (limited to 'drivers/opp')
0 files changed, 0 insertions, 0 deletions