linux-kernel - Re: Multi-parent IRQ domains

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: <alpine.DEB.2.21.1809171510020.16580@nanos.tec.linutronix.de>
Date:   Mon, 17 Sep 2018 15:27:19 +0200 (CEST)
From:   Thomas Gleixner <tglx@...utronix.de>
To:     Thierry Reding <thierry.reding@...il.com>
cc:     Marc Zyngier <marc.zyngier@....com>,
        Rob Herring <robh+dt@...nel.org>, linux-tegra@...r.kernel.org,
        devicetree@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: Multi-parent IRQ domains

On Mon, 17 Sep 2018, Thierry Reding wrote:
> On Mon, Sep 17, 2018 at 02:28:01PM +0200, Thomas Gleixner wrote:
> > I'm not a DT wizerd, but the GPIO cannot be linked there I think.
> > 
> >     RTC ---------------------------> [ PMC domain 1] -----> GIC
> > 
> >     Button --> [GPIO domain] ------> [ PMC domain 2]
> > 
> > The RTC is connected to PMC domain 1 and that allocates the GIC irq.
> > 
> > The button is conntected to the GPIO which connect to the PMC domain
> > 2. That PMC domain has no connection to anything. It ends there.
> 
> Interesting, I was assuming the following:
> 
>     Button --> [PMC domain 2] --> [GPIO domain]
> 
> based on the hardware documentation that maps the wake events to
> specific signals on the chip.

That might be, but there is no reason why we can't interpret that
creatively :)

> > So, I don't know how GPIOs are mapped into the PMC when they are a wakeup
> > source. It might be all of them have the ability so there is some 1:1
> > relation ship or if the whole GPIO -> PMC connection can be built at run
> > time, but that's just an implementation detail.
> 
> There's a fixed mapping for which signals go to which wake event. Some
> of those events are mapped to GPIOs, others to different signals, such
> as the RTC alarm. I think I should be able to build a GPIO -> PMC map
> at runtime using a static table.

Ok, so for the RTC and the like (which are directly GIC backed) it's easy
as you just say: RTC interrupt = PMC irq #N.

And for GPIO you can just have the GPIO domains all parented by the PMC
domain 2 and then have the allocation function of the PMC domain do the
lookup of the GPIOs which actually have a PMC connection.

If it's there then you set the hwirq in the domains irq_data to the real
PMC hwirq number and for those which are not connected you set it to some
invalid value. In the set_type() callback you can then error out when it's
called for a GPIO which is not connected to the PMC by checking the hwirq
value.

That way the GPIO code does not have any requirement to know about the PMC
connections and only the PMC domain 2 needs to know. So if in the next chip
the GPIO/PMC association changes, you don't have to worry about it at the
GPIO (driver) level, you just hand a different GPIO/PMC map to the PMC
driver via DT.

Thanks,

	tglx