linux-kernel - Re: SOC-specific action for irq_set

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:	Wed, 20 Jul 2016 09:03:13 -0700
From:	Sören Brinkmann <soren.brinkmann@...inx.com>
To:	Marc Zyngier <marc.zyngier@....com>
CC:	Andy Gross <andy.gross@...aro.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Jason Cooper <jason@...edaemon.net>,
	<linux-arm-kernel@...ts.infradead.org>,
	Michal Simek <michal.simek@...inx.com>,
	<linux-kernel@...r.kernel.org>
Subject: Re: SOC-specific action for irq_set_wake

On Wed, 2016-07-20 at 14:36:12 +0100, Marc Zyngier wrote:
> Hi Sören,
> 
> On 20/07/16 14:16, Sören Brinkmann wrote:
> > Hi Marc,
> 
> >>>>> Does anybody have similar problems and probably already solved it?
> >>>>> Any other suggestions for approaching the problem? Any preferred
> >>>>> solution?
> >>>>
> >>>> I think we have the same problem.  Can you provide more detail on the hardware
> >>>> implementation of your wake irq controller?  I presume you have some set of
> >>>> registers, an irq maybe, and some other stuff?  And how does it fit into the
> >>>> overall architecture from a hardware perspective?
> >>>
> >>> We have essentially a whole second interrupt controller. All IRQs are
> >>> connected to the A53 GIC and this second interrupt controller that is
> >>> controlled by the companion core. The companion core is supposed to be
> >>> informed about what source the A53 needs to wake up on and will program
> >>> this second IRQ controller, etc.
> >>
> >> So your "special case" is exactly like everyone else's. Implement it as
> >> a hierarchical chip on top of the GIC, just like Tegra, OMAP, iMX6,
> >> Exynos and a few others. Unless you implement PSCI.
> > 
> > I didn't really think that our case is unique. I was just looking for
> > some pointers into the right direction as the extension mechanism that I
> > remembered disappeared and I haven't been following the development
> > closely enough to just know what alternatives are available.
> > So, you say the approach of letting the secure monitor infer the wake
> > IRQ by reading the GIC config is preferred over handling it as
> > hierarchical chip within Linux?
> 
> The in-kernel approach is a consequence of the firmware-less 32bit
> configuration. Hopefully, we won't see anything like that anymore.
> Fingers crossed.
> 
> So the firmware approach is clearly the preferred one on arm64, as it
> simplifies absolutely everything (and your power management has to know
> about all of this anyway).

Thanks for your input. We'll do it this way then. Thanks, everybody.

	Sören