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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 20 Jul 2016 14:36:12 +0100
From:	Marc Zyngier <marc.zyngier@....com>
To:	Sören Brinkmann <soren.brinkmann@...inx.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

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,

	M.
-- 
Jazz is not dead. It just smells funny...