Re: [PATCH v2 0/6] riscv: Make IPI_MAX visible and use it consistently

[Radu Rendec]

On Thu, 2026-09-17 at 19:22 +0800, Guo Ren wrote:
> On Mon, Sep 14, 2026 at 3:53 AM Radu Rendec <radu@xxxxxxxxxx> wrote:
> > 
> > On Fri, 2026-09-11 at 03:27 +0000, Guo Ren wrote:
> > > This series removes the implicit assumption that RISC-V supports exactly
> > > eight IPI message types.
> > > 
> > > Currently, the SBI, CLINT and ACLINT SSWI IPI providers use
> > > BITS_PER_BYTE when sizing the generic IPI mux, while IMSIC carries a
> > > separate IMSIC_NR_IPI definition set to 8. These values happen to match
> > > IPI_MAX today, but neither is the proper source of truth for the number
> > > of RISC-V IPI message types.
> > > 
> > > Move enum ipi_message_type to asm/smp.h so IPI providers can use IPI_MAX
> > > directly, then replace the BITS_PER_BYTE and IMSIC_NR_IPI uses with
> > > IPI_MAX.
> > > 
> > > This also makes adding future RISC-V IPI message types independent of
> > > the current eight-entry assumption.
> > > 
> > > A follow-up patch renames the MediaTek VPU mailbox terminator from
> > > IPI_MAX to IPI_VPU_MAX. That token belongs to the VPU firmware IPI id
> > > enum and should follow the same prefixed convention as IPI_VPU_INIT
> > > (and SCP_IPI_MAX on the SCP side), instead of reusing the generic
> > > IPI_MAX name.
> > > 
> > > ---
> > > GUO Ren (XuanTie) (4):
> > >       clocksource: clint: Use IPI_MAX for IPI muxing
> > >       irqchip/aclint-sswi: Use IPI_MAX for IPI muxing
> > >       irqchip/imsic: Use IPI_MAX instead of IMSIC_NR_IPI
> > >       media: mtk-vpu: rename IPI_MAX to IPI_VPU_MAX
> > > 
> > > tip-bot2 for GUO Ren (XuanTie) (2):
> > >       riscv: smp: Move enum ipi_message_type to asm/smp.h
> > >       riscv: sbi: Use IPI_MAX for SBI IPI muxing
> > 
> > I am confused. Thomas merged your entire v1 series a week before (see
> > the individual replies from tip-bot2@xxxxxxxxxxxxx). Why are you
> > sending v2?
> > 
> > Patch 6 was not included in v1 (but it's clearly related), so perhaps
> > you meant to send only this one as a separate patch?
> > 
> > Also:
> >  * The cover letter should include a changelog, indicating what changes
> >    were made in each version compared to the previous one.
> >  * Patches 1 and 2 carry a "From:" tag that attributes authorship to
> >    tip-bot2, which is wrong (if these patches were to be applied).
> 
> Sorry for the noise, and thanks for catching these.

No worries :)

> You are right on both points. I missed the cover-letter changelog,
> and I should not have resent the already-merged patches as v2. The
> "From: tip-bot2" tags were added by b4 because those two patches had
> already landed; that is useful as a reminder to me, but it should not
> have been left in the patches themselves.
> 
> I should have skipped the b4 v2 flow and just sent patch 6 on its
> own. The only remaining change is the mtk-vpu IPI_MAX rename, which
> is needed after IPI_MAX became visible from <asm/smp.h>.

Ugh, I missed that part. Because the IPI_MAX rename was already picked
up, it's going to break the mtk-vpu driver until patch 6 is picked up
too.

> If you are willing to pick patch 6 as-is, I would appreciate it.
> Otherwise I will resend it as a standalone patch.

I cannot pick up anything myself because I'm just a reviewer. But I
don't see any reason why patch 6 couldn't be picked up as-is, as long
as everyone is on the same page. The "[PATCH v2 6/6]" part of the
subject is dropped anyway.

I now realize that patch 1 (which introduces the conflicting change)
was picked up by Thomas via the irq/drivers tip branch, but patch 6 is
strictly a media subsystem patch, so I guess normally it should be
picked up by a different maintainer via a different tree.

Thomas, are you willing to pick this up too? I'm thinking it could
avoid some pain if irq/drivers gets merged into mainline first, before
patch 6 makes it there through the media subsystem. Also, it's a pretty
"innocent" patch, it just renames an enum value, and it's contained
within that driver.

-- 
Best regards,
Radu