linux-kernel - Re: [PATCH 4/7] dt-bindings: sdm845-pinctrl: add wakeup interrupt parent for GPIO

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:   Fri, 11 Jan 2019 15:20:48 -0800
From:   Stephen Boyd <sboyd@...nel.org>
To:     Lina Iyer <ilina@...eaurora.org>, Rob Herring <robh@...nel.org>
Cc:     Evan Green <evgreen@...omium.org>,
        Marc Zyngier <marc.zyngier@....com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "Raju P.L.S.S.S.N" <rplsssn@...eaurora.org>,
        linux-arm-msm <linux-arm-msm@...r.kernel.org>,
        Thierry Reding <thierry.reding@...il.com>,
        Bjorn Andersson <bjorn.andersson@...aro.org>,
        devicetree@...r.kernel.org
Subject: Re: [PATCH 4/7] dt-bindings: sdm845-pinctrl: add wakeup interrupt parent for GPIO

Quoting Rob Herring (2019-01-09 11:36:56)
> 
> > >However, my main concern is documenting something genericish in a
> > >device specific binding. It looks like Tegra is trying to add the same
> > >thing, so this needs to be documented in a common place. One question
> > >is whether wakeup is the only use or if this should be more generally
> > >a secondary interrupt parent?
> > >
> > Yes, wakeup is the only use of this interrupt parent.
> 
> Maybe for you, but I was wondering about this more generally. Should
> we encode what the function (e.g. wakeup) is in the property name or
> have something like aux-interrupt-controller? Maybe some platforms
> have some need for a secondary interrupt-controller which is not
> wakeup. Routing interrupts to other cores perhaps?
> 

I'd say it's not the interrupt-parent, but a secondary-interrupt-parent,
because it's another path that some GPIO interrupts will go through vs.
the "normal" summary irq line that uses the interrupt-parent. Maybe
that's similar to the interrupt partitioning that ARM is doing for PPIs
that only go to some CPUs?

We don't really specify that some GPIO is corresponding to the secondary
or primary interrupt controller for the GPIO controller in DT. If we
did, then we could do something like the interrupt-map binding and have
the index of that property be the gpio number and the interrupt parent
that it maps to (either summary from the GIC or MPM pin number).

 interrupt-map = <0 0 &gic GIC_SPI 208 0>,
                 <1 0 &pdc 3 0>;
 interrupt-map-mask = <0xfffffff 0>;

And then we would pass the 2-cell GPIO interrupt specifier (gpio# and
flags) through the table and remap it to arbitrary domain parents. We
could use this same design for the SSBI and SPMI gpio interrupt
controller where we're currently looking at hardcoding the base
interrupt number in the driver (0xc0) and then adding the GPIO number to
that to get the parent interrupt specifier.

It's sort of an abuse of interrupt-map, but I don't know if it really
matters because there isn't a child of the gpio controller that is going
to go through this table.