linux-kernel - Re: [PATCH v2 0/3] add support for power off check in suspend

Open Source and information security mailing list archives

Message-ID: <c749ad04-1f95-1f8d-7fd8-93b228ace10c@microchip.com>
Date:   Tue, 8 Jan 2019 14:07:35 +0000
From:   <Claudiu.Beznea@...rochip.com>
To:     <rafael@...nel.org>
CC:     <len.brown@...el.com>, <alexandre.belloni@...tlin.com>,
        <linux-pm@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
        <rjw@...ysocki.net>, <lgirdwood@...il.com>,
        <Ludovic.Desroches@...rochip.com>, <broonie@...nel.org>,
        <pavel@....cz>, <linux@...linux.org.uk>,
        <linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH v2 0/3] add support for power off check in suspend

On 08.01.2019 13:46, Rafael J. Wysocki wrote:
> On Tue, Jan 8, 2019 at 11:56 AM <Claudiu.Beznea@...rochip.com> wrote:
>>
>> From: Claudiu Beznea <claudiu.beznea@...rochip.com>
>>
>> Hi,
>>
>> AT91 platforms support a power saving mode where SoC's power is cut off (we call
>> it backup mode). The resume is done with the help of bootloaders.
> 
> But still the contents of RAM are preserved?

Yes, the RAM is kept alive, in self-refresh (forgot to mention).
Besides this, there is the so called backup area which contains RTC
shutdown controller, RC oscillator which remains powered. The rest is off.

> 
> That would require at least the memory controller to be under power AFAICS.

Yes, this is powered by a different regulator.

> 
>> To be able to
>> suspend/resume Linux to/from this mode all the drivers suspend/resume callbacks
>> should save/restore the content of all the active registers. We have 2 problems
>> we are trying to solve:
>> - some of these drivers are shared with other non Microchip SoCs (e.g. macb
>>   driver) and we don't want to disturbe other users of corresponding IPs with
>>   all the register save/restore operations;
>> - the suspend/resume time for the rest of the power saving mode we are using
>>   could be improved if we would know in drivers the suspend mode the platform
>>   is switched to.
>>
>> A solution that would have been solve our problems was proposed in [1] but in
>> the end it wasn't accepted. It ended up with the introduction of
>> pm_suspend_target_state variable that could be used along with the changes in
>> this series.
>>
>> While the discussion of [1] progressed it has been proposed (in [2]) to
>> implement a function that would tell if the platform's power would be cut off
>> at the end of the suspend procedure.
>>
>> The patches in this series does as follows:
>> 1/3 - add a new member to platform_suspend_ops that will tell if platform's
>>       power will be cut off at the end of the suspend procedure; drivers could
>>       use it via platform_off_in_suspend()
> 
> I would rather avoid doing this if possible.

Having this mechanism as part of platform_suspend_ops? Or this mechanism at
all?
Could you give me some hints on how would you prefer to do it, if any?

Thank you,
Claudiu Beznea

> 
> Thanks,
> Rafael
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@...ts.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> 

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