linux-kernel - Re: Save and Restore Generic Interrupt Controller for System Sleep on ARM

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

Message-ID: <87vahk6vbz.fsf@on-the-bus.cambridge.arm.com>
Date:   Wed, 06 Dec 2017 09:48:16 +0000
From:   Marc Zyngier <marc.zyngier@....com>
To:     "dbasehore ." <dbasehore@...omium.org>
Cc:     linux-kernel <linux-kernel@...r.kernel.org>,
        Thomas Gleixner <tglx@...utronix.de>, sudeep.holla@....com,
        Linux-pm mailing list <linux-pm@...r.kernel.org>
Subject: Re: Save and Restore Generic Interrupt Controller for System Sleep on ARM

On Thu, Nov 30 2017 at  5:21:20 pm GMT, "dbasehore ." <dbasehore@...omium.org> wrote:
> On Thu, Nov 30, 2017 at 1:44 AM, Marc Zyngier <marc.zyngier@....com> wrote:
>> On Wed, Nov 29 2017 at 2:49:18 pm GMT, "dbasehore ."
>> <dbasehore@...omium.org> wrote:
>>> There was some work in ARM Trusted Firmware to support saving and
>>> restoring the Generic Interrupt Controller (GICv3) before and after
>>> sleep, but it seems that the plan is to have this all in the kernel
>>> now. The point of doing this is to save power during sleep. On an
>>> RK3399 system, we save about 15mW by disabling the power rail that the
>>> GIC is on.
>>>
>>> I was looking for whether anyone had anything in progress already or
>>> for preferences on how to do this. Marc suggested using a device tree
>>> entry to indicate the need to save and restore the GIC. There is
>>> another requirement to resend MAPC commands on certain implementations
>>> of the GICv3 which could be indicated by another device tree entry.
>>
>> Let's be precise: This is a GIC-500 requirement, and not something that
>> the GICv3 architecture defines (PM is *not* part of the GICv3
>> architecture).
>>
>
> Just to double check, do the register restores apply to all GICv3
> designs? If so, I can put that code in the gic-v3 code instead of
> breaking it out.

I would keep it GIC-500 specific for the time being. But that code
should live in the GICv3 driver, gated on the IIDR registers and some
form of firmware negotiation.

Again, it will be much easier to comment on this when we see the
code. So far, I feel a bit uneasy talking mostly hypothetically.

Thanks,

	M.
-- 
Jazz is not dead, it just smell funny.