Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1669543
| From | Florian Fainelli <florian.fainelli@broadcom.com> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: [PATCH v3 0/4] Generalize fncpy availability |
| Date | 2017-06-19 19:40 +0200 |
| Message-ID | <tU8OC-5H3-15@gated-at.bofh.it> (permalink) |
| References | <tT9tn-7uo-3@gated-at.bofh.it> <tU3YD-2AA-29@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
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
Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
[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 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
Re: [PATCH v3 0/4] Generalize fncpy availability David Howells <dhowells@redhat.com> - 2017-06-19 15:40 +0200
csiph-web