[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <c8b7789c-38fb-6793-050f-7c60ccb8ca17@broadcom.com>
Date: Mon, 19 Jun 2017 10:32:38 -0700
From: Florian Fainelli <florian.fainelli@...adcom.com>
To: Mark Rutland <mark.rutland@....com>,
Florian Fainelli <f.fainelli@...il.com>
Cc: 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/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
Powered by blists - more mailing lists