Re: [PATCH] remoteproc: xlnx: do not send new mailbox notification

[Shah, Tanmay]

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 <tanmay.shah@xxxxxxx>
>>>> ---
>>>>
>>>> Depends on: https://lore.kernel.org/linux-remoteproc/20260209234430.512492-1-jassisinghbrar@xxxxxxxxx/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 <mathieu.poirier@xxxxxxxxxx>
>>>
>>> (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/20260209234430.512492-1-jassisinghbrar@xxxxxxxxx/
>>
>> 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
>>>>
>>