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

From	Sudeep Holla <sudeep.holla@arm.com>
Newsgroups	linux.kernel
Subject	Re: [PATCH v3 0/4] Generalize fncpy availability
Date	2017-06-20 19:00 +0200
Message-ID	<tUuFs-2G9-23@gated-at.bofh.it> (permalink)
References	<tT9tn-7uo-3@gated-at.bofh.it> <tU3YD-2AA-29@gated-at.bofh.it> <tU8OC-5H3-15@gated-at.bofh.it> <tUnkC-6DB-27@gated-at.bofh.it> <tUucq-2wu-31@gated-at.bofh.it>
Organization	ARM

Show all headers | View raw


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 ?

You can always report any issue with PSCI specification at
errata@arm.com as mentioned in the document.
-- 
Regards,
Sudeep

Thread

Re: [PATCH v3 0/4] Generalize fncpy availability Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> - 2017-06-20 11:10 +0200
  Re: [PATCH v3 0/4] Generalize fncpy availability Florian Fainelli <f.fainelli@gmail.com> - 2017-06-20 18:30 +0200
    Re: [PATCH v3 0/4] Generalize fncpy availability Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> - 2017-06-20 18:50 +0200
    Re: [PATCH v3 0/4] Generalize fncpy availability Sudeep Holla <sudeep.holla@arm.com> - 2017-06-20 19:00 +0200
      Re: [PATCH v3 0/4] Generalize fncpy availability Florian Fainelli <f.fainelli@gmail.com> - 2017-06-20 19:10 +0200

csiph-web