Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1668101 > unrolled thread

[PATCH v3 0/4] Generalize fncpy availability

Back to article view | Back to linux.kernel

Contents

  [PATCH v3 0/4] Generalize fncpy availability Florian Fainelli <f.fainelli@gmail.com> - 2017-06-17 02:10 +0200
    Re: [PATCH v3 0/4] Generalize fncpy availability Mark Rutland <mark.rutland@arm.com> - 2017-06-19 14:30 +0200
      Re: [PATCH v3 0/4] Generalize fncpy availability Tony Lindgren <tony@atomide.com> - 2017-06-19 16:00 +0200
      Re: [PATCH v3 0/4] Generalize fncpy availability Florian Fainelli <florian.fainelli@broadcom.com> - 2017-06-19 19:40 +0200
    Re: [PATCH v3 0/4] Generalize fncpy availability David Howells <dhowells@redhat.com> - 2017-06-19 15:40 +0200

#1668101 — [PATCH v3 0/4] Generalize fncpy availability

Hi all,

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.

Thanks!

Florian Fainelli (4):
  ARM: fncpy: Rename include guards
  asm-generic: Provide a fncpy() implementation
  arm64: Provide a fncpy implementation
  misc: sram: Allow ARM64 to select SRAM_EXEC

 arch/arm/include/asm/fncpy.h  |  6 +--
 arch/arm64/include/asm/Kbuild |  1 +
 drivers/misc/Kconfig          |  2 +-
 include/asm-generic/fncpy.h   | 93 +++++++++++++++++++++++++++++++++++++++++++
 4 files changed, 98 insertions(+), 4 deletions(-)
 create mode 100644 include/asm-generic/fncpy.h

-- 
2.9.3

[toc] | [next] | [standalone]

#1669031

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?

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

what exactly do you intend to use this for?

Thanks,
Mark.

[toc] | [prev] | [next] | [standalone]

#1669085

* Mark Rutland <mark.rutland@arm.com> [170619 05:25]:
> On Fri, Jun 16, 2017 at 05:07:40PM -0700, Florian Fainelli wrote:
> > 
> > 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?
> 
> My understanding was that on 32-bit, this was to handle idle / suspend
> cases, whereas for arm64 that should be handled by PSCI.
> 
> what exactly do you intend to use this for?

Well idle / suspend can have multiple needs such as running
core while DDR is in self-refresh mode and saving and restoring
of some context registers in that state.

Also clock drivers may need this to reprogram some core clocks.

Regards,

Tony

[toc] | [prev] | [next] | [standalone]

#1669543

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

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

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

> 
> what exactly do you intend to use this for?

At the moment we use it to enter S2 on ARM64 systems (ARCH_BRCMSTB)
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.
-- 
Florian

[toc] | [prev] | [next] | [standalone]

#1669075

This should be have something put in the Documentation/ directory.

David

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web