linux-kernel - Re: [PATCH v2 2/2] irqchip: al-fic: Introduce Amazon's Annapurna Labs Fabric Interrupt Controller Driver

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] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 06 Jun 2019 08:10:24 +0100
From:   Marc Zyngier <marc.zyngier@....com>
To:     Benjamin Herrenschmidt <benh@...nel.crashing.org>
Cc:     Talel Shenhar <talel@...zon.com>, <nicolas.ferre@...rochip.com>,
        <jason@...edaemon.net>, <mark.rutland@....com>,
        <mchehab+samsung@...nel.org>, <robh+dt@...nel.org>,
        <davem@...emloft.net>, <shawn.lin@...k-chips.com>,
        <tglx@...utronix.de>, <devicetree@...r.kernel.org>,
        <gregkh@...uxfoundation.org>, <linux-kernel@...r.kernel.org>,
        <dwmw@...zon.co.uk>, <jonnyc@...zon.com>, <hhhawa@...zon.com>,
        <ronenk@...zon.com>, <hanochu@...zon.com>, <barakw@...zon.com>
Subject: Re: [PATCH v2 2/2] irqchip: al-fic: Introduce Amazon's Annapurna Labs Fabric Interrupt Controller Driver

On Wed, 05 Jun 2019 23:02:13 +0100,
Benjamin Herrenschmidt <benh@...nel.crashing.org> wrote:
> 
> On Wed, 2019-06-05 at 13:22 +0100, Marc Zyngier wrote:
> > 
> > > +	 * This is generally fixed depending on what pieces of HW it's wired up
> > > +	 * to.
> > > +	 *
> > > +	 * We configure it based on the sensitivity of the first source
> > > +	 * being setup, and reject any subsequent attempt at configuring it in a
> > > +	 * different way.
> > 
> > Is that a reliable guess? It also strikes me that the DT binding doesn't
> > allow for the trigger type to be passed, meaning the individual drivers
> > have to request the trigger as part of their request_irq() call. I'd
> > rather you have a complete interrupt specifier in DT, and document the
> > various limitations of the HW.
> 
> Actually the DT does, but Talel forgot to update the "example" part of
> the binding patch. The description does say 2 cells.

Yeah, I missed that and only read the example.

> This is the best approach imho (translation: I asked Talel to do it
> this way :-) The other option which I don't like is to stick to
> #interrupt-cells = 1, and have a separate property in the interrupt
> controller node to indicate whether it needs to be configured as level
> or edge.

Right, that's what I was suggesting in a separate email.

> These FICs are used for what is generally fixed wires inside the SoC,
> so it doesn't matter much either way, but I prefer having it self
> configured based on source just in case a future implementation doesn't
> have the limitation of all inputs having the same trigger type.

Fair enough. But it should be pretty easy to verify statically that
all interrupt specifiers targeting this interrupt controller have a
similar type.

RobH, is that something the yaml thing could do for us?

Thanks,

	M.

-- 
Jazz is not dead, it just smells funny.