LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Stefan Agner <stefan@agner.ch>
To: Robin Murphy <robin.murphy@arm.com>,
swarren@nvidia.com, thierry.reding@gmail.com, digetx@gmail.com
Cc: linux@armlinux.org.uk, ard.biesheuvel@linaro.org, arnd@arndb.de,
nicolas.pitre@linaro.org, keescook@chromium.org,
marc.zyngier@arm.com, linux-kernel@vger.kernel.org,
mka@chromium.org, linux-arm-kernel@lists.infradead.org,
Bernhard.Rosenkranzer@linaro.org
Subject: Re: [PATCH 3/5] ARM: trusted_foundations: do not use naked function
Date: Wed, 21 Mar 2018 15:09:58 +0100 [thread overview]
Message-ID: <302cfd1a4324e064cd4f189e4e0ffc21@agner.ch> (raw)
In-Reply-To: <124e16c9-b8ca-9c7e-ade5-b033eed76e14@arm.com>
On 21.03.2018 13:13, Robin Murphy wrote:
> On 20/03/18 23:02, Stefan Agner wrote:
>> As documented in GCC naked functions should only use Basic asm
>> syntax. The Extended asm or mixture of Basic asm and "C" code is
>> not guaranteed. Currently this works because it was hard coded
>> to follow and check GCC behavior for arguments and register
>> placement.
>>
>> Furthermore with clang using parameters in Extended asm in a
>> naked function is not supported:
>> arch/arm/firmware/trusted_foundations.c:47:10: error: parameter
>> references not allowed in naked functions
>> : "r" (type), "r" (arg1), "r" (arg2)
>> ^
>>
>> Use a regular function to be more portable. This aligns also with
>> the other smc call implementations e.g. in qcom_scm-32.c and
>> bcm_kona_smc.c.
>>
>> Additionally also make sure all callee-saved registers get saved
>> as it has been done before.
>>
>> Signed-off-by: Stefan Agner <stefan@agner.ch>
>> ---
>> arch/arm/firmware/trusted_foundations.c | 12 +++++++-----
>> 1 file changed, 7 insertions(+), 5 deletions(-)
>>
>> diff --git a/arch/arm/firmware/trusted_foundations.c b/arch/arm/firmware/trusted_foundations.c
>> index 3fb1b5a1dce9..426d732e6591 100644
>> --- a/arch/arm/firmware/trusted_foundations.c
>> +++ b/arch/arm/firmware/trusted_foundations.c
>> @@ -31,21 +31,23 @@
>> static unsigned long cpu_boot_addr;
>> -static void __naked tf_generic_smc(u32 type, u32 arg1, u32 arg2)
>> +static void tf_generic_smc(u32 type, u32 arg1, u32 arg2)
>> {
>> + register u32 r0 asm("r0") = type;
>> + register u32 r1 asm("r1") = arg1;
>> + register u32 r2 asm("r2") = arg2;
>> +
>> asm volatile(
>> ".arch_extension sec\n\t"
>> - "stmfd sp!, {r4 - r11, lr}\n\t"
>> __asmeq("%0", "r0")
>> __asmeq("%1", "r1")
>> __asmeq("%2", "r2")
>> "mov r3, #0\n\t"
>> "mov r4, #0\n\t"
>> "smc #0\n\t"
>> - "ldmfd sp!, {r4 - r11, pc}"
>> :
>> - : "r" (type), "r" (arg1), "r" (arg2)
>> - : "memory");
>> + : "r" (r0), "r" (r1), "r" (r2)
>> + : "memory", "r3", "r4", "r5", "r6", "r7", "r8", "r9", "r10");
>
> I may be missing a subtlety, but it looks like we no longer have a
> guarantee that r11 will be caller-saved as it was previously. I don't
> know the Trusted Foundations ABI to say whether that matters or not,
> but if it is the case that it never needed preserving anyway, that
> might be worth calling out in the commit message.
Adding r11 (fp) to the clobber list causes an error when using gcc and
CONFIG_FRAME_POINTER=y:
arch/arm/firmware/trusted_foundations.c: In function ‘tf_generic_smc’:
arch/arm/firmware/trusted_foundations.c:51:1: error: fp cannot be used
in asm here
Not sure what ABI Trusted Foundations follow.
[adding Stephen, Thierry and Dmitry]
Maybe someone more familiar with NVIDIA Tegra SoCs can help?
When CONFIG_FRAME_POINTER=y fp gets saved anyway. So we could add r11 to
clobber list ifndef CONFIG_FRAME_POINTER...
--
Stefan
>
> Robin.
>
>> }
>> static int tf_set_cpu_boot_addr(int cpu, unsigned long boot_addr)
>>
next prev parent reply other threads:[~2018-03-21 14:10 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-03-20 23:02 [PATCH 0/5] ARM: clang support Stefan Agner
2018-03-20 23:02 ` [PATCH 1/5] bus: arm-cci: use asm unreachable Stefan Agner
2018-03-20 23:30 ` Russell King - ARM Linux
2018-03-21 8:22 ` Stefan Agner
2018-03-20 23:02 ` [PATCH 2/5] efi/libstub/arm: add support for building with clang Stefan Agner
2018-03-20 23:02 ` [PATCH 3/5] ARM: trusted_foundations: do not use naked function Stefan Agner
2018-03-20 23:13 ` Russell King - ARM Linux
2018-03-21 8:41 ` Stefan Agner
2018-03-21 12:13 ` Robin Murphy
2018-03-21 14:09 ` Stefan Agner [this message]
2018-03-21 15:26 ` Dmitry Osipenko
2018-03-21 16:40 ` Stephen Warren
2018-03-21 17:16 ` Robin Murphy
2018-03-21 21:41 ` Stefan Agner
2018-03-22 11:48 ` Robin Murphy
2018-03-22 12:43 ` Stefan Agner
2018-03-22 14:03 ` Dmitry Osipenko
2018-03-20 23:02 ` [PATCH 4/5] ARM: drop no-thumb-interwork in EABI mode Stefan Agner
2018-03-20 23:02 ` [PATCH 5/5] ARM: add support for building ARM kernel with clang Stefan Agner
2018-03-20 23:18 ` Russell King - ARM Linux
2018-03-21 0:20 ` Matthias Kaehlcke
2018-03-21 9:03 ` Stefan Agner
2018-03-25 13:24 ` Stefan Agner
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=302cfd1a4324e064cd4f189e4e0ffc21@agner.ch \
--to=stefan@agner.ch \
--cc=Bernhard.Rosenkranzer@linaro.org \
--cc=ard.biesheuvel@linaro.org \
--cc=arnd@arndb.de \
--cc=digetx@gmail.com \
--cc=keescook@chromium.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@armlinux.org.uk \
--cc=marc.zyngier@arm.com \
--cc=mka@chromium.org \
--cc=nicolas.pitre@linaro.org \
--cc=robin.murphy@arm.com \
--cc=swarren@nvidia.com \
--cc=thierry.reding@gmail.com \
--subject='Re: [PATCH 3/5] ARM: trusted_foundations: do not use naked function' \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).