linux-kernel - Re: [PATCH v3 2/6] irqchip/riscv-intc: Allow drivers to directly discover INTC hwnode

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <87bkz04jpy.wl-maz@kernel.org>
Date:   Mon, 21 Feb 2022 10:06:33 +0000
From:   Marc Zyngier <maz@...nel.org>
To:     Anup Patel <anup@...infault.org>
Cc:     Anup Patel <apatel@...tanamicro.com>,
        Palmer Dabbelt <palmer@...belt.com>,
        Paul Walmsley <paul.walmsley@...ive.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        Daniel Lezcano <daniel.lezcano@...aro.org>,
        Atish Patra <atishp@...shpatra.org>,
        Alistair Francis <Alistair.Francis@....com>,
        linux-riscv <linux-riscv@...ts.infradead.org>,
        "linux-kernel@...r.kernel.org List" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v3 2/6] irqchip/riscv-intc: Allow drivers to directly discover INTC hwnode

On Mon, 21 Feb 2022 09:55:05 +0000,
Anup Patel <anup@...infault.org> wrote:
> 
> On Mon, Feb 21, 2022 at 3:21 PM Marc Zyngier <maz@...nel.org> wrote:
> >
> > On Sun, 20 Feb 2022 05:08:50 +0000,
> > Anup Patel <apatel@...tanamicro.com> wrote:
> > >
> > > Various RISC-V drivers (such as SBI IPI, SBI Timer, SBI PMU, and
> > > KVM RISC-V) don't have associated DT node but these drivers need
> > > standard per-CPU (local) interrupts defined by the RISC-V privileged
> > > specification.
> > >
> > > We add riscv_get_intc_hwnode() in arch/riscv which allows RISC-V
> > > drivers not having DT node to discover INTC hwnode which in-turn
> > > helps these drivers to map per-CPU (local) interrupts provided
> > > by the INTC driver.
> > >
> > > Signed-off-by: Anup Patel <apatel@...tanamicro.com>
> > > ---
> > >  arch/riscv/include/asm/irq.h     |  4 ++++
> > >  arch/riscv/kernel/irq.c          | 19 +++++++++++++++++++
> > >  drivers/irqchip/irq-riscv-intc.c |  7 +++++++
> > >  3 files changed, 30 insertions(+)
> > >

[...]

> > > index b65bd8878d4f..fa24ecd01d39 100644
> > > --- a/drivers/irqchip/irq-riscv-intc.c
> > > +++ b/drivers/irqchip/irq-riscv-intc.c
> > > @@ -92,6 +92,11 @@ static const struct irq_domain_ops riscv_intc_domain_ops = {
> > >       .xlate  = irq_domain_xlate_onecell,
> > >  };
> > >
> > > +static struct fwnode_handle *riscv_intc_hwnode(void)
> > > +{
> > > +     return (intc_domain) ? intc_domain->fwnode : NULL;
> > > +}
> >
> > This makes no sense. Either you have found the interrupt controller
> > and allocated the domain, or you haven't. But you don't register a
> > callback without having found it.
> 
> We are registering this callback after creating the INTC domain.

Then why are you checking for intc_domain being NULL?

> > And you have totally ignored my previous comments about the multitude
> > of irq domains for the INTC. Either you get rid of all but one and you
> > can register a single fwnode, or you stay with what you have today,
> 
> Only the INTC DT nodes are per-CPU but we are creating only one
> INTC domain to manage per-CPU IRQs across all CPUs.

Ah, there is this guard that is only valid on the boot CPU. Fair
enough.

	M.

-- 
Without deviation from the norm, progress is not possible.