From: Marc Zyngier <maz@kernel.org>
To: Anup Patel <anup@brainfault.org>
Cc: Anup Patel <apatel@ventanamicro.com>,
Palmer Dabbelt <palmer@dabbelt.com>,
Paul Walmsley <paul.walmsley@sifive.com>,
Thomas Gleixner <tglx@linutronix.de>,
Daniel Lezcano <daniel.lezcano@linaro.org>,
Atish Patra <atishp@atishpatra.org>,
Alistair Francis <Alistair.Francis@wdc.com>,
linux-riscv <linux-riscv@lists.infradead.org>,
"linux-kernel@vger.kernel.org List"
<linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v4 3/6] RISC-V: Treat IPIs as normal Linux IRQs
Date: Fri, 04 Mar 2022 08:04:48 +0000 [thread overview]
Message-ID: <87ee3ita73.wl-maz@kernel.org> (raw)
In-Reply-To: <CAAhSdy3ACa-447MrLs=5GLjSSWKiKyR585RFWP_ycM3RZ+RTQg@mail.gmail.com>
On Tue, 01 Mar 2022 17:40:55 +0000,
Anup Patel <anup@brainfault.org> wrote:
>
> On Tue, Mar 1, 2022 at 8:07 PM Marc Zyngier <maz@kernel.org> wrote:
> > > +struct ipi_mux {
> > > + struct irq_domain *domain;
> > > + int parent_virq;
> > > + void (*clear_ipi)(void);
> > > + void (*send_ipi)(const struct cpumask *mask);
> > > +};
> >
> > Why do you need this in the arch code? It really looks like something
> > that is irqchip specific (single IPI signal on which actual IPIs are
> > overlayed). It is also something that other irqchips are already
> > implementing, so there is potential for consolidation.
>
> I agree we can share the IPI muxing among irqchip drivers.
>
> I was not sure where to place this IPI muxing so I made it
> RISC-V specific initially.
>
> Can we place a simplified IPI muxing (with no RISC-V specific
> stuff) under drivers/irqchip or kernel/irq ??
We already have IPI-specific code in kernel/irq, so it should probably
live there.
> > > +struct irq_domain *riscv_ipi_mux_create(bool use_soft_irq,
> > > + void (*clear_ipi)(void),
> > > + void (*send_ipi)(const struct cpumask *mask))
> > > +{
> >
> > There really shouldn't be a need for such a registration interface
> > anyway (the current idiom is to allocate IPIs in the root irqchip, and
> > pass them to the arch code).
> >
> > Why can't you model it after the existing architectures?
>
> I ended up with a lot of duplicate code between SBI IPI driver and
> SiFive CLINT driver so I factored out the IPI muxing as separate
> sources. We also have RISC-V AIA drivers using the same IPI muxing.
>
> If we simplify the IPI muxing and move it out of arch/riscv then
> changes in this patch are straight forward to review.
It isn't only about making things easier to review. It is about having
consistent interfaces across architecture and reducing the amount of
glue between arch code and random drivers. If there is a lot of
similar code between your various irqchips, then it can be made common
between the irqchips. But the interface between arch code and those
should not be arch-specific.
M.
--
Without deviation from the norm, progress is not possible.
next prev parent reply other threads:[~2022-03-04 8:05 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-03-01 4:27 [PATCH v4 0/6] RISC-V IPI Improvements Anup Patel
2022-03-01 4:27 ` [PATCH v4 1/6] RISC-V: Clear SIP bit only when using SBI IPI operations Anup Patel
2022-03-01 4:27 ` [PATCH v4 2/6] irqchip/riscv-intc: Allow drivers to directly discover INTC hwnode Anup Patel
2022-03-01 4:27 ` [PATCH v4 3/6] RISC-V: Treat IPIs as normal Linux IRQs Anup Patel
2022-03-01 14:36 ` Marc Zyngier
2022-03-01 17:40 ` Anup Patel
2022-03-04 8:04 ` Marc Zyngier [this message]
2022-03-01 4:27 ` [PATCH v4 4/6] RISC-V: Allow marking IPIs as suitable for remote FENCEs Anup Patel
2022-03-01 4:27 ` [PATCH v4 5/6] RISC-V: Use IPIs for remote TLB flush when possible Anup Patel
2022-03-01 4:27 ` [PATCH v4 6/6] RISC-V: Use IPIs for remote icache " 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=87ee3ita73.wl-maz@kernel.org \
--to=maz@kernel.org \
--cc=Alistair.Francis@wdc.com \
--cc=anup@brainfault.org \
--cc=apatel@ventanamicro.com \
--cc=atishp@atishpatra.org \
--cc=daniel.lezcano@linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-riscv@lists.infradead.org \
--cc=palmer@dabbelt.com \
--cc=paul.walmsley@sifive.com \
--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