arch/riscv/include/asm/smp.h | 12 ++++++++++++ arch/riscv/kernel/sbi-ipi.c | 4 ++-- arch/riscv/kernel/smp.c | 12 ------------ drivers/clocksource/timer-clint.c | 4 ++-- drivers/irqchip/irq-aclint-sswi.c | 4 ++-- drivers/irqchip/irq-riscv-imsic-early.c | 4 ++-- drivers/irqchip/irq-riscv-imsic-state.h | 1 - drivers/media/platform/mediatek/vpu/mtk_vpu.c | 12 ++++++------ drivers/media/platform/mediatek/vpu/mtk_vpu.h | 4 ++-- 9 files changed, 28 insertions(+), 29 deletions(-)
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
arch/riscv/include/asm/smp.h | 12 ++++++++++++
arch/riscv/kernel/sbi-ipi.c | 4 ++--
arch/riscv/kernel/smp.c | 12 ------------
drivers/clocksource/timer-clint.c | 4 ++--
drivers/irqchip/irq-aclint-sswi.c | 4 ++--
drivers/irqchip/irq-riscv-imsic-early.c | 4 ++--
drivers/irqchip/irq-riscv-imsic-state.h | 1 -
drivers/media/platform/mediatek/vpu/mtk_vpu.c | 12 ++++++------
drivers/media/platform/mediatek/vpu/mtk_vpu.h | 4 ++--
9 files changed, 28 insertions(+), 29 deletions(-)
---
base-commit: 08df884136f1c1197bab2a27814404fd329d9aac
change-id: 20260911-ipi_max-ff71eeadf6fd
Best regards,
--
GUO Ren (XuanTie) <guoren@kernel.org>
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@linutronix.de). 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). > > arch/riscv/include/asm/smp.h | 12 ++++++++++++ > arch/riscv/kernel/sbi-ipi.c | 4 ++-- > arch/riscv/kernel/smp.c | 12 ------------ > drivers/clocksource/timer-clint.c | 4 ++-- > drivers/irqchip/irq-aclint-sswi.c | 4 ++-- > drivers/irqchip/irq-riscv-imsic-early.c | 4 ++-- > drivers/irqchip/irq-riscv-imsic-state.h | 1 - > drivers/media/platform/mediatek/vpu/mtk_vpu.c | 12 ++++++------ > drivers/media/platform/mediatek/vpu/mtk_vpu.h | 4 ++-- > 9 files changed, 28 insertions(+), 29 deletions(-) > --- > base-commit: 08df884136f1c1197bab2a27814404fd329d9aac > change-id: 20260911-ipi_max-ff71eeadf6fd > > Best regards, > -- > GUO Ren (XuanTie) <guoren@kernel.org>
On Mon, Sep 14, 2026 at 3:53 AM Radu Rendec <radu@rendec.net> 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@linutronix.de). 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. 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>. If you are willing to pick patch 6 as-is, I would appreciate it. Otherwise I will resend it as a standalone patch. -- Best Regards Guo Ren
On Thu, 2026-09-17 at 19:22 +0800, Guo Ren wrote: > On Mon, Sep 14, 2026 at 3:53 AM Radu Rendec <radu@rendec.net> 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@linutronix.de). 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
© 2016 - 2026 Red Hat, Inc.