linux-kernel - Re: [PATCH v2 2/3] regulator: core: add helper to check if regulator is disabled in 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: <40a2dbb6-56aa-173a-4be0-d7072ed32b53@microchip.com>
Date:   Fri, 11 Jan 2019 14:08:19 +0000
From:   <Claudiu.Beznea@...rochip.com>
To:     <broonie@...nel.org>
CC:     <Nicolas.Ferre@...rochip.com>, <alexandre.belloni@...tlin.com>,
        <Ludovic.Desroches@...rochip.com>, <linux@...linux.org.uk>,
        <lgirdwood@...il.com>, <rjw@...ysocki.net>, <pavel@....cz>,
        <len.brown@...el.com>, <linux-arm-kernel@...ts.infradead.org>,
        <linux-kernel@...r.kernel.org>, <linux-pm@...r.kernel.org>
Subject: Re: [PATCH v2 2/3] regulator: core: add helper to check if regulator
 is disabled in suspend



On 11.01.2019 14:39, Mark Brown wrote:
> On Thu, Jan 10, 2019 at 10:24:26AM +0000, Claudiu.Beznea@...rochip.com wrote:
>> On 09.01.2019 18:57, Mark Brown wrote:
> 
>>> regulator state which feels fragile.  But based on the cover letter
>>> that's kind of like what the initial proposal about target states was so
>>> perhaps this is the way we end up going... 
> 
>> Are you talking about [1] ?
> 
> I can't follow that link right now, I'm working offline.
> 
>> I can get rid of this patch, take advantage of [3] and [4] and introduce
>> also the regulator standby states. In this case, no matter the mapping b/w
>> Linux power saving modes and AT91 SoC's power saving modes, we will be
>> covered on misconfiguration (at least on SAMA5D2 Xplained board).
> 
>> And in patch 3/3 I could get rid of regulator checks and rely on DT (bad
>> thing would be that in case of no input for regulator's state in
>> mem/standby the board could not properly suspended/resumed), if any.
> 
>> What do you think about this?
> 
> Like I say I'm working offline so I can't check the links but it sounds
> like you're saying that the existing suspend mode configuration features
> are enough for your systems? 

Yes, if we rely on the fact that core's regulator device tree bindings for
suspend-to-mem/suspend-to-standby were filled correctly.

The function I added here was to double check that core's regulator will be
off in suspend/standby based on what was parsed from DT.

Thank you,
Claudiu Beznea

> so that's great - certainly what you're
> saying above sounds sensible to me but it's possible I misunderstood
> something based on not having the links.
>