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

Date:   Thu, 06 Jun 2019 17:49:25 +1000
From:   Benjamin Herrenschmidt <benh@...nel.crashing.org>
To:     Marc Zyngier <marc.zyngier@....com>
Cc:     "Shenhar, Talel" <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 Thu, 2019-06-06 at 08:05 +0100, Marc Zyngier wrote:
> 
> > I disagree Marc. This is a rather bad error which indicates that the
> > device-tree is probably incorrect (or the HW was wired in a way that
> > cannot work).
> 
> But surely that's something you'll spot pretty quickly.

Not really. A level/edge mismatch isn't something you can spot that
quickly, but will cause lost interrupts on load. Since the kernel can
spot the error pretty much right away, I think that could even be a
pr_err :)

> Also, you get
> a splat from the irq subsystem already, telling you that things went
> wrong (see __irq_set_trigger). At that stage, you can enable debugging
> and figure it out.

Ah returning an error will cause such splat indeed.

> What I'm trying to avoid is the kernel becoming a (pretty bad)
> validation tool for DTS files.

Haha, yeah, I don't like it going out of its way to validate them but
that sort of very obvious sanity checking makes sense.

> > Basically a given FIC can either be entirely level sensitive or
> > entirely edge sensitive. This catches cases where the DT has routed
> > a mixed of both to the same FIC. Definitely worth barfing loudly
> > about rather than trying to understand subtle odd misbehaviours of
> > the device in the field.
> 
> Then, in the interest of not producing incorrect DTs, could the
> edge/level property be encoded in the FIC description itself, rather
> than in the interrupt specifiers of the individual devices? It would
> sidestep the problem altogether. You can still put the wrong one in
> the FIC node, but it then becomes even more obvious what is going
> on...

This was Talel original approach internally in fact. I told him to put
it in the specifier instead :-) The advantage in doing it that way is
that you get the right flags in the descriptor by default iirc, so the
right value in /proc/interrupts etc... And it will continue working if
a future FIC loses that limitation.

That said, if you feel strongly about it, we can revert to putting a
global property in the FIC node itself. Let us know what you want.

Cheers,
Ben.