On 3/17/2026 10:14 AM, Mathieu Poirier wrote:
> On Mon, Mar 16, 2026 at 11:29:49AM -0500, Shah, Tanmay wrote:
>>
>>
>> On 3/16/2026 10:18 AM, Mathieu Poirier wrote:
>>> On Thu, Feb 19, 2026 at 02:43:30PM -0800, Tanmay Shah wrote:
>>>> Only write a new message to the tx mbox queue if slot is available in
>>>> the tx queue. If queue is full, then do not send new mbox notification.
>>>>
>>>> Signed-off-by: Tanmay Shah <[email protected]>
>>>> ---
>>>>
>>>> Depends on:
>>>> https://lore.kernel.org/linux-remoteproc/[email protected]/T/#u
>>>>
>>>> drivers/remoteproc/xlnx_r5_remoteproc.c | 5 ++++-
>>>> 1 file changed, 4 insertions(+), 1 deletion(-)
>>>>
>>>> diff --git a/drivers/remoteproc/xlnx_r5_remoteproc.c
>>>> b/drivers/remoteproc/xlnx_r5_remoteproc.c
>>>> index bd619a6c42aa..622de733c929 100644
>>>> --- a/drivers/remoteproc/xlnx_r5_remoteproc.c
>>>> +++ b/drivers/remoteproc/xlnx_r5_remoteproc.c
>>>> @@ -332,7 +332,10 @@ static void zynqmp_r5_rproc_kick(struct rproc *rproc,
>>>> int vqid)
>>>> int ret;
>>>>
>>>> ipi = r5_core->ipi;
>>>> - if (!ipi)
>>>> + if (!ipi || !ipi->tx_chan)
>>>> + return;
>>>> +
>>>> + if (mbox_chan_tx_slots_available(ipi->tx_chan) == 0)
>>>> return;
>>>>
>>>
>>> Is see 3 options to handle this situation:
>>>
>>> (1) I can provide an RB for this patch and Jassi picks it up in his tree.
>>> The
>>> downside is that if a subsequent submission conflicts with this change, we
>>> have
>>> to wait for the next cycle. In that case:
>>>
>>> Reviewed-by: Mathieu Poirier <[email protected]>
>>>
>>> (2) Jassi provides me with a pull request to bring the patch in the
>>> rproc-next tree.
>>>
>>
>> Hi Mathieu,
>>
>> I am curious what do you mean by pull request?
>>
>> Jassi had included remoteproc mailing list when sent the original patch
>> here:
>> https://lore.kernel.org/linux-remoteproc/[email protected]/
>>
>> Since then no other change was introduced in that patch. Isn't it enough
>> for it to pick-up for rproc-next? I am just asking from the process
>> point of view, what should have been done differently?
>>
>> If all looks good, then I think you can pick up original patch from him
>> for rproc-next, as the same patch got merged in the linux-next.
>
> If I apply Jassi's patch to rproc-next, we'll end up with the same patch with
> two different SHA1s in two different trees, something that is not compatible
> with the linux-next process. To avoid this kind of situation we work with
> pull
> requests, which doesn't change the patch's SHA1.
>
> Since preparing a pull request takes time that Jassi may not have, I provided
> my
> R-B for your patch, allowing him to merge it in his mailbox tree.
>
Thanks Mathieu,
It makes sense now. I appreciate your response.
It looks like then option-3 is the cleanest solution then.
I can wait now as I have your R-B anyway now.
I will rebase the patch after 5-weeks on the remoteproc for-next branch.
If I see the merge conflict, then I will resend the patch.
Thanks,
Tanmay
>>
>> Thanks,
>> Tanmay
>>
>>> (3) I pick it up in the rproc-next tree in 5 weeks when v7.1-rc1 comes out.
>>>
>>>> mb_msg = (struct zynqmp_ipi_message *)ipi->tx_mc_buf;
>>>>
>>>> base-commit: 462799c088e71b2b8a511c2a9649420fcb569ab7
>>>> --
>>>> 2.34.1
>>>>
>>
