linux-kernel - Re: [PATCH v2 1/1] irqchip: exynos-combiner: Save IRQ enable set on suspend

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]

Message-ID: <557B34A7.4090507@collabora.co.uk>
Date:	Fri, 12 Jun 2015 21:36:07 +0200
From:	Javier Martinez Canillas <javier.martinez@...labora.co.uk>
To:	Sudeep Holla <sudeep.holla@....com>
CC:	Krzysztof Kozlowski <k.kozlowski@...sung.com>,
	"linux-samsung-soc@...r.kernel.org" 
	<linux-samsung-soc@...r.kernel.org>,
	Jason Cooper <jason@...edaemon.net>,
	Chanho Park <parkch98@...il.com>,
	Doug Anderson <dianders@...omium.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Kukjin Kim <kgene@...nel.org>,
	Peter Chubb <peter.chubb@...ta.com.au>,
	Shuah Khan <shuahkhan@...il.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Tomasz Figa <tomasz.figa@...il.com>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH v2 1/1] irqchip: exynos-combiner: Save IRQ enable set
 on suspend

Hello Sudeep,

On 06/12/2015 02:57 PM, Javier Martinez Canillas wrote:
> On 06/12/2015 01:54 PM, Sudeep Holla wrote:

[snip]

> 
>> registers are lost assuming the combiner was powered down, even the
>> status register will be lost and you will not know exactly the wakeup
>> reason right ?
>>
> 
> Good question, I didn't find in the documentation I've access to that
> this happen but just found through experimentation that the IRQ enable
> set register values are lost after a resume and that saving/restoring
> the values makes the interrupts to be triggered again.
>

I'll share here too the findings I mentioned over IRC. As you suggested I
add some printouts and noticed that the ISTRn (Interrupt Status) registers
values are indeed preserved on resume so I can know for example if the
wakeup source was the power gpio-key or cros_ec keyboard. I've checked the
values of the registers against the Exynos manual and they corresponds to
the interrupt sources in each case so the values are correct.

So as you said, it seems that is not that the IP block loses its state on
S2R but that something is blindly writing the IESRn (Interrupt Enable Set)
registers.

To reduce the possible s/w components that could be doing this, I booted a
signed FIT image directly using the RO U-Boot instead of chain loading a
mainline nv-uboot. In this configuration I've the same issue so it seems
that if something is zeroing those registers on S2R, this can't be changed
without void the warranty of these machines.

I also looked at the downstream ChromiumOS v3.8 tree [0] and I see that
they have a very similar solution than my patch, the IESRn are also saved
but using a notifier for the CPU_PM_ENTER and CPU_PM_EXIT events instead
or registering a syscore ops but the idea is basically the same.

I have to take a look to the U-boot that is shipped on the device, I think
the correct branch is [1] but I'm not sure if that is the correct one.

Best regards,
Javier

[0]: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/chromeos-3.8/arch/arm/mach-exynos/common.c#657
[1]: https://chromium.googlesource.com/chromiumos/third_party/u-boot firmware-pit-4482.B

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/