rpmsg: wait endpoint ready in rpmsg_send

[xiaoxiang781216]

because the remote need time to return the destination address

[arnopo]

As previously discussed this imposes a way of implementing to other platforms which would not want to wait on first message, and not be blocked because channel has been closed by remote side (RPMSG_NS_DESTROY).

Look to me that test in rpmsg_send_offchannel_raw is enough to protect from a non initialized destination address .
The loop should be implement in application if necessary, to keep flexibility in the lib usage.

@edmooring
Any opinion on this?

[xiaoxiang781216]

But this change doesn't forbid the user do the loop in application, user has all possible choice:

1. Call rpmsg_try_send and check the return value
2. Check dest_addr before call rpmsg_send
3. Let rpmsg_send to do the check

With this patch, user can still do item 1 and item 2 as they want, but item 3 can protect user if they forget to do the check.
BTW, it also follow the same behaviour when the vring buffer exhaust:
https://github.com/OpenAMP/open-amp/blob/master/lib/rpmsg/rpmsg_virtio.c#L305

[edmooring]

I agree with Arnaud. This changes the behavior of an existing API in a way that could be very surprising to a user by introducing a possible 15 second delay in their application.
This should be done in an application, where the user knows what conditions they might be expected and can set timeout values and retry patterns in a way that is best for them.

[xiaoxiang781216]

Ok, let's see how many user will report this issue and then decide whether a common solution is needed.

[edmooring]

I agree with Arnaud. This changes the behavior of an existing API in a way that could be very surprising to a user by introducing a possible 15 second delay in their application.
This should be done in an application, where the user knows what conditions they might be expected and can set timeout values and retry patterns in a way that is best for them.

[github-actions]

This pull request has been marked as a stale pull request because it has been open (more than) 45 days with no activity.