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, > 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 > >> >
