linux-kernel - Re: [PATCH v3 0/4] Generalize fncpy availability

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: <e4d75953-b12f-7157-d3a7-84a5f417cac9@gmail.com>
Date:   Tue, 20 Jun 2017 10:03:53 -0700
From:   Florian Fainelli <f.fainelli@...il.com>
To:     Sudeep Holla <sudeep.holla@....com>
Cc:     Lorenzo Pieralisi <lorenzo.pieralisi@....com>,
        Florian Fainelli <florian.fainelli@...adcom.com>,
        Mark Rutland <mark.rutland@....com>,
        linux-arm-kernel@...ts.infradead.org,
        "open list:GENERIC INCLUDE/ASM HEADER FILES" 
        <linux-arch@...r.kernel.org>, Arnd Bergmann <arnd@...db.de>,
        Dave Gerlach <d-gerlach@...com>,
        Tony Lindgren <tony@...mide.com>,
        Catalin Marinas <catalin.marinas@....com>,
        Will Deacon <will.deacon@....com>,
        Russell King <linux@...linux.org.uk>,
        open list <linux-kernel@...r.kernel.org>,
        bcm-kernel-feedback-list@...adcom.com,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Alexandre Belloni <alexandre.belloni@...e-electrons.com>,
        linux-omap@...r.kernel.org, Shawn Guo <shawnguo@...nel.org>,
        Keerthy J <j-keerthy@...com>
Subject: Re: [PATCH v3 0/4] Generalize fncpy availability

On 06/20/2017 09:54 AM, Sudeep Holla wrote:
> 
> 
> On 20/06/17 17:20, Florian Fainelli wrote:
>> On 06/20/2017 02:10 AM, Lorenzo Pieralisi wrote:
>>> [+Sudeep]
>>>
>>> On Mon, Jun 19, 2017 at 10:32:38AM -0700, Florian Fainelli wrote:
>>>> On 06/19/2017 05:24 AM, Mark Rutland wrote:
>>>>> On Fri, Jun 16, 2017 at 05:07:40PM -0700, Florian Fainelli wrote:
>>>>>> Hi all,
>>>>>
>>>>> Hi Florian,
>>>>>
>>>>>> This patch series makes ARM's fncpy() implementation more generic (dropping the
>>>>>> Thumb-specifics) and available in an asm-generic header file.
>>>>>>
>>>>>> Tested on a Broadcom ARM64 STB platform with code that is written to SRAM.
>>>>>>
>>>>>> Changes in v3 (thanks Doug!):
>>>>>> - correct include guard names in asm-generic/fncpy.h to __ASM_FNCPY_H
>>>>>> - utilize Kbuild to provide the fncpy.h header on ARM64
>>>>>>
>>>>>> Changes in v2:
>>>>>> - leave the ARM implementation where it is
>>>>>> - make the generic truly generic (no)
>>>>>>
>>>>>> This is helpful in making SoC-specific power management code become true drivers
>>>>>> that can be shared between different architectures.
>>>>>> Could you elaborate on what this is needed for?
>>>>
>>>> Several uses cases come to mind:
>>>>
>>>> - it could be used as a trampoline code prior to entering S2 for systems
>>>> that do not support PSCI 1.0
>>>
>>> I think S2 here means PM_SUSPEND_MEM. It is very wrong to manage power
>>> states through platform specific hooks on PSCI based systems, consider
>>> upgrading to PSCI 1.0 please (or implement PSCI CPU_SUSPEND power
>>> states that allow to achieve same power savings as PM_SUSPEND_MEM
>>> by just entering suspend-to-idle).
>>
>> S2 is PM_SUSPEND_STANDBY and S3 is PM_SUSPEND_MEM, at least that how I
>> read it. I would rather we update to PSCI 1.0 (at least) to properly
>> support SYSTEM_SUSPEND rather than retrofitting a system-wide suspend
>> state into CPU_SUSPEND since that seems wrong.
>>
> 
> This has been discussed multiple times in the past. No one has come back
> with strong reason to add that to the PSCI SYSTEM_SUSPEND API.
> 
> Care to explain the difference between PM_SUSPEND_STANDBY and S3 is
> PM_SUSPEND_MEM on your platform. And why it can't be achieved with
> suspend-to-idle ?

S2 preserves the ON/OFF island power and allows wake logic to wake the
system (infrared, GPIOs, Wake-on-LAN/WLAN, etc.) whereas S3 allows
powering off the ON/OFF island entirely, and allows for a lower power
consumption, with a subset of the wake peripherals to actually wake the
system. S5 is also implemented although its use case is narrower (soft-off).

The higher latency involved in S3 entry/exit is totally accepted due to
the higher power savings that it yields.

> 
> You can always report any issue with PSCI specification at
> errata@....com as mentioned in the document.

I just did because there are a few other things missing.
-- 
Florian