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:20:29 -0800 [thread overview]
Message-ID: <20191119192029.GP35479@atomide.com> (raw)
In-Reply-To: <7fa11037-8d33-2274-c8cc-80e9630b38b0@ti.com>
* Andrew F. Davis <afd@ti.com> [191119 19:13]:
> On 11/19/19 2:07 PM, Tony Lindgren wrote:
> > * 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.
>
> Then why call arm_smccc_smc()? omap_smc2() is already an assembly
> function, all it needs to do after loading the registers and saving the
> right ones is issue an "smc #0" instruction, why would we want to
> instead call into some other function to re-save registers and issue the
> exact same instruction?
To use Linux generic API for smc calls where possible.
> > 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?
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Sorry but maybe check the font size on your screen. I'm trying to
get your attention again for the second time above to answer a
question I asked.
> >> 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 :)
> Unless all our calls use the r12 hack, then we would need to fixup
> OP-TEE to accept that also.
No idea about that that part, but sounds like r12 use is up to
the caller in the optee case.
Regards,
Tony
next prev parent reply other threads:[~2019-11-19 19:20 UTC|newest]
Thread overview: 28+ 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 21:57 ` Tony Lindgren
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 16:21 ` Tony Lindgren
2019-11-19 16:30 ` Tony Lindgren
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:32 ` Tony Lindgren
2019-11-19 18:50 ` Andrew F. Davis
2019-11-19 19:07 ` Tony Lindgren
2019-11-19 19:12 ` Andrew F. Davis
2019-11-19 19:20 ` Tony Lindgren [this message]
2019-11-19 19:35 ` Andrew F. Davis
2019-11-19 19:44 ` Tony Lindgren
2019-11-19 19:59 ` 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:41 ` Tony Lindgren
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: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=20191119192029.GP35479@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox