From: Marc Zyngier <maz@kernel.org>
To: Palmer Dabbelt <palmer@dabbelt.com>
Cc: apatel@ventanamicro.com, Paul Walmsley <paul.walmsley@sifive.com>,
tglx@linutronix.de, daniel.lezcano@linaro.org, marcan@marcan.st,
sven@svenpeter.dev, alyssa@rosenzweig.io, atishp@atishpatra.org,
Alistair Francis <Alistair.Francis@wdc.com>,
anup@brainfault.org, linux-riscv@lists.infradead.org,
linux-kernel@vger.kernel.org, asahi@lists.linux.dev
Subject: Re: [PATCH v16 0/9] RISC-V IPI Improvements
Date: Mon, 20 Feb 2023 08:35:19 +0000 [thread overview]
Message-ID: <0a0d1a182cef674a8e70347b2ed6f67b@kernel.org> (raw)
In-Reply-To: <mhng-a886c4b4-d748-420f-889b-76ada4f9a432@palmer-ri-x1c9>
On 2023-02-15 03:17, Palmer Dabbelt wrote:
> On Sun, 05 Feb 2023 03:04:14 PST (-0800), Marc Zyngier wrote:
>> On Tue, 03 Jan 2023 14:12:12 +0000,
>> Anup Patel <apatel@ventanamicro.com> wrote:
>>>
>>> This series aims to improve IPI support in Linux RISC-V in following
>>> ways:
>>> 1) Treat IPIs as normal per-CPU interrupts instead of having custom
>>> RISC-V
>>> specific hooks. This also makes Linux RISC-V IPI support aligned
>>> with
>>> other architectures.
>>> 2) Remote TLB flushes and icache flushes should prefer local IPIs
>>> instead
>>> of SBI calls whenever we have specialized hardware (such as
>>> RISC-V AIA
>>> IMSIC and RISC-V SWI) which allows S-mode software to directly
>>> inject
>>> IPIs without any assistance from M-mode runtime firmware.
>>
>> [...]
>>
>> I'm queuing patches 3 and 9 via the irqchip tree as they are
>> standalone.
>>
>> For the rest, I need an Ack from the riscv maintainers as they change
>> a large amount of arch-specific code, and the couple of irqchip
>> patches depend on these changes.
>>
>> Palmer, Paul?
>
> I haven't gotten time to give this a proper review, but I think we've
> got enough of a mess with our interrupt handling that it doesn't
> really matter so
>
> Acked-by: Palmer Dabbelt <palmer@rivosinc.com>
>
> if you want to take it for this cycle that's fine with me, but I'm
> also fine holding off so it can have a while to bake in linux-next --
> there's no real rush for any of this, as there's no hardware yet.
Letting this sort of things simmering in -next is the way.
Now that the basic dependencies are on their way, I'd expect this to be
rebased on 6.3-rc1, and we can then put the whole thing in -next.
Thanks,
M.
--
Jazz is not dead. It just smells funny...
next prev parent reply other threads:[~2023-02-20 8:35 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-03 14:12 [PATCH v16 0/9] RISC-V IPI Improvements Anup Patel
2023-01-03 14:12 ` [PATCH v16 1/9] RISC-V: Clear SIP bit only when using SBI IPI operations Anup Patel
2023-01-03 14:12 ` [PATCH v16 2/9] irqchip/riscv-intc: Allow drivers to directly discover INTC hwnode Anup Patel
2023-01-03 14:12 ` [PATCH v16 3/9] genirq: Add mechanism to multiplex a single HW IPI Anup Patel
2023-02-05 11:29 ` [irqchip: irq/irqchip-next] " irqchip-bot for Anup Patel
2023-01-03 14:12 ` [PATCH v16 4/9] RISC-V: Treat IPIs as normal Linux IRQs Anup Patel
2023-01-03 14:12 ` [PATCH v16 5/9] RISC-V: Allow marking IPIs as suitable for remote FENCEs Anup Patel
2023-01-03 14:12 ` [PATCH v16 6/9] RISC-V: Use IPIs for remote TLB flush when possible Anup Patel
2023-01-03 14:12 ` [PATCH v16 7/9] RISC-V: Use IPIs for remote icache " Anup Patel
2023-01-03 14:12 ` [PATCH v16 8/9] irqchip/riscv-intc: Add empty irq_eoi() for chained irq handlers Anup Patel
2023-01-03 14:12 ` [PATCH v16 9/9] irqchip/apple-aic: Move over to core ipi-mux Anup Patel
2023-02-05 11:29 ` [irqchip: irq/irqchip-next] " irqchip-bot for Marc Zyngier
2023-01-12 12:17 ` [PATCH v16 0/9] RISC-V IPI Improvements Anup Patel
2023-01-20 3:29 ` Anup Patel
2023-02-05 11:04 ` Marc Zyngier
2023-02-15 3:17 ` Palmer Dabbelt
2023-02-20 8:35 ` Marc Zyngier [this message]
2023-02-20 9:50 ` Anup Patel
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=0a0d1a182cef674a8e70347b2ed6f67b@kernel.org \
--to=maz@kernel.org \
--cc=Alistair.Francis@wdc.com \
--cc=alyssa@rosenzweig.io \
--cc=anup@brainfault.org \
--cc=apatel@ventanamicro.com \
--cc=asahi@lists.linux.dev \
--cc=atishp@atishpatra.org \
--cc=daniel.lezcano@linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-riscv@lists.infradead.org \
--cc=marcan@marcan.st \
--cc=palmer@dabbelt.com \
--cc=paul.walmsley@sifive.com \
--cc=sven@svenpeter.dev \
--cc=tglx@linutronix.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox