From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 1F0D0230BDB for ; Sun, 16 Aug 2026 07:01:03 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786863665; cv=none; b=ODzyFNN9r2uGFKmrWeAHubzF0Q3qU+coVhoz1sfb6utaJAUNzxQcs2vVs98IED5fBw7smug0p1U1X2LUeydD6lP2dFtIDdEG3QpkfxduMViD4qMSYGBilv4d3j4atM0lJ3+8ItTixHQ3Vs83cZJf5v/Oy1AsT4IXWzOnB+U3pSs= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786863665; c=relaxed/simple; bh=SZDPp5x8Rntw233U+QIz4Wl3LFn8xCN0beD9y0K6sgw=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=R5sTPEBabTYkU9BfV/NJCId/+FW1Pk8ZmwKUHvnPcnb9/k4wuVSypYK1YLEkKYekPaSokxpVaro7KXND8GHduohGH4+/a2PPoZfsOxRSW/cRsH50MZd+/PLwrrC1dyICtp/YDmXIcal1WVjNz8m+amLbXBGmh3eY1dqdLm8c4tw= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=SsV2V/j9; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="SsV2V/j9" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 2F7261F000E9; Sun, 16 Aug 2026 07:00:59 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1786863663; bh=eKRkUJfCj88qVdlkI4awKV1gPZoWAVIlpCpTPjok5ko=; h=From:To:Cc:Subject:Date; b=SsV2V/j9ikUBTGVa5FVEE+2D35Imm4RGevTg2+T4nCFdF+eHXkNw5DSeSaTQae7La 4CK7qZDLGRyRqs9mRXsJxjwVeK6ajGwufH8cmIOpxgT/xiQcW05tSolebKlsec7Lup OdX3rSP9ECzOuvCvSmzZn3bM9PamuI+Xc8X/e17c7VYIaROGFWN84calzBf2ODniTr kbXvbKnepucdta34pmGw3H5tksiFQnMflS4QJM1eU6LmMSNW/M39v3LsZcKMb2qIpM UCpj7EYlEN4lDMHAGTN2NM2JAILxUfd07kRHsDoZRQ/h1LKCNmB5xIgWqr0ecY5w8u /EyU7KCznV+/w== From: Guo Ren To: linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org Cc: palmer@dabbelt.com, pjw@kernel.org, aou@eecs.berkeley.edu, alex@ghiti.fr, tglx@kernel.org, daniel.lezcano@kernel.org, anup@brainfault.org, hui.wang@canonical.com, samuel.holland@sifive.com, "GUO Ren (XuanTie)" Subject: [PATCH 0/5] riscv: Make IPI_MAX visible and use it consistently Date: Sun, 16 Aug 2026 07:00:44 +0000 Message-ID: <20260816070049.2097442-1-guoren@kernel.org> X-Mailer: git-send-email 2.43.0 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: "GUO Ren (XuanTie)" 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. GUO Ren (XuanTie) (5): riscv: smp: Move enum ipi_message_type to asm/smp.h riscv: sbi: Use IPI_MAX for SBI IPI muxing 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 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 - 7 files changed, 20 insertions(+), 21 deletions(-) -- 2.43.0