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

[Mathieu Poirier <mathieu.poirier@linaro.org>]

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@amd.com>
> >> ---
> >>
> >> Depends on: https://lore.kernel.org/linux-remoteproc/20260209234430.512492-1-jassisinghbrar@gmail.com/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@linaro.org>
> > 
> > (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@gmail.com/
> 
> 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,
> 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
> >>
>