[+Sudeep]

On Mon, Jun 19, 2017 at 10:32:38AM -0700, Florian Fainelli wrote:

On 06/19/2017 05:24 AM, Mark Rutland wrote:

quoted

On Fri, Jun 16, 2017 at 05:07:40PM -0700, Florian Fainelli wrote:

quoted

Hi all,

Hi Florian,

quoted

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).

- any code that has a specific need to relocate a performance, security
sensitive code into SRAM and use it as another pool of memory.

quoted

My understanding was that on 32-bit, this was to handle idle / suspend
cases, whereas for arm64 that should be handled by PSCI.

For systems that support PSCI 1.0, I agree, but it may not be possible
to update those systems easily, still use case 2 is completely valid.

Just to be clear, thinking of using platform specific suspend hooks
on PSCI systems is not a viable solution, I will let other people
comment on option 2.

quoted

what exactly do you intend to use this for?

At the moment we use it to enter S2 on ARM64 systems (ARCH_BRCMSTB)

"At the moment", where ?

which are PSCI 0.2 only. And yes, we do have a plan to evaluate
upgrading to PSCI 1.0, but in general, any SoC which as an addressable
SRAM could use it for whatever purpose it sees fit.

Not to implement suspend hooks on PSCI 0.2 systems.

Thanks,
Lorenzo