From: Tony Lindgren <tony@atomide.com>
To: "Andrew F. Davis" <afd@ti.com>
Cc: Mark Rutland <mark.rutland@arm.com>,
linux-omap@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] ARM: OMAP: Use ARM SMC Calling Convention when OP-TEE is available
Date: Tue, 19 Nov 2019 11:07:21 -0800 [thread overview]
Message-ID: <20191119190721.GO35479@atomide.com> (raw)
In-Reply-To: <a351461a-f6a1-334b-6bdd-a56626914fb3@ti.com>
* Andrew F. Davis <afd@ti.com> [191119 18:51]:
> On 11/19/19 1:32 PM, Tony Lindgren wrote:
> > It would allow us to completely change over to using
> > arm_smccc_smc() and forget the custom calls.
>
> We would need more than just the r12 quirk to replace all our custom SMC
> handlers, we would need quirks for omap_smc2 which puts process ID in r1
> and puts #0xff in r6, and omap_smc3 that uses smc #1. All of our legacy
> SMC calls also trash r4-r11, that is very non SMCCC complaint as only
> r4-r7 need be caller saved. I don't see arm_smccc_smc() working with
> legacy ROM no matter how much we hack at it :(
We would just have omap_smc2() call arm_smccc_smc() and in that
case. And omap_smc2() would still deal with saving and restoring
the registers.
Certainly the wrapper functions calling arm_smccc_smc() can deal
with r12 too if the r12-quirk version and the plain version are
never needed the same time on a booted SoC.
Are they ever needed the same time on a booted SoC or not?
> I can make OP-TEE also compatible with the r12 quirk, which is what I
> used to do. That way we didn't need to do any detection. The issue was
> that non-standard SMC calls should not go through the common SMCCC
> handler (unless you are QCOM for some reason..).
Sounds like for optee nothing must be done for r12 :)
Regards,
Tony
next prev parent reply other threads:[~2019-11-19 19:07 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-11-18 16:52 [PATCH] ARM: OMAP: Use ARM SMC Calling Convention when OP-TEE is available Andrew F. Davis
2019-11-18 16:52 ` Andrew F. Davis
2019-11-18 21:57 ` Tony Lindgren
2019-11-18 22:13 ` Andrew F. Davis
2019-11-18 22:13 ` Andrew F. Davis
2019-11-18 22:31 ` Tony Lindgren
2019-11-19 1:13 ` Andrew F. Davis
2019-11-19 1:13 ` Andrew F. Davis
2019-11-19 16:21 ` Tony Lindgren
2019-11-19 16:21 ` Tony Lindgren
2019-11-19 16:30 ` Tony Lindgren
2019-11-19 16:30 ` Andrew F. Davis
2019-11-19 16:30 ` Andrew F. Davis
2019-11-19 16:42 ` Tony Lindgren
2019-11-19 18:05 ` Tony Lindgren
2019-11-19 18:20 ` Andrew F. Davis
2019-11-19 18:20 ` Andrew F. Davis
2019-11-19 18:32 ` Tony Lindgren
2019-11-19 18:50 ` Andrew F. Davis
2019-11-19 18:50 ` Andrew F. Davis
2019-11-19 19:07 ` Tony Lindgren [this message]
2019-11-19 19:12 ` Andrew F. Davis
2019-11-19 19:12 ` Andrew F. Davis
2019-11-19 19:20 ` Tony Lindgren
2019-11-19 19:35 ` Andrew F. Davis
2019-11-19 19:35 ` Andrew F. Davis
2019-11-19 19:44 ` Tony Lindgren
2019-11-19 19:59 ` Andrew F. Davis
2019-11-19 19:59 ` Andrew F. Davis
2019-12-16 20:56 ` Andrew F. Davis
2019-12-16 20:56 ` Andrew F. Davis
2019-12-16 21:04 ` Tony Lindgren
2019-12-16 22:34 ` Andrew F. Davis
2019-12-16 22:34 ` Andrew F. Davis
2019-12-16 22:41 ` Tony Lindgren
2019-12-17 13:14 ` Andrew F. Davis
2019-12-17 13:14 ` Andrew F. Davis
2019-12-17 15:07 ` Tony Lindgren
2019-12-17 17:01 ` Andrew F. Davis
2019-12-17 17:01 ` Andrew F. Davis
2019-12-17 17:11 ` Tony Lindgren
2019-12-17 17:18 ` Tony Lindgren
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=20191119190721.GO35479@atomide.com \
--to=tony@atomide.com \
--cc=afd@ti.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-omap@vger.kernel.org \
--cc=mark.rutland@arm.com \
/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
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.