linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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:44:25 -0800	[thread overview]
Message-ID: <20191119194425.GQ35479@atomide.com> (raw)
In-Reply-To: <0ad31b32-712e-5bef-5645-0336dfec99cc@ti.com>

* Andrew F. Davis <afd@ti.com> [191119 19:36]:
> On 11/19/19 2:20 PM, Tony Lindgren wrote:
> > * 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.
> 
> But we are not using generic API calls, we are using omap_smcx() which
> cannot call into arm_smccc_smc(). For all the above reasons plus
> arm_smccc_smc() uses r12 to save the stack pointer, our ROM expects r12
> to store the function ID.

Saving and restoring r12 could be handled by the arm_smccc_smc() quirk
for the non-optee case.

Then we could get rid of omap_smc1() and arm_smccc_smc() should work
for the optee case and non-optee case, right.

> >>> 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?

> They should not be needed at the same time, either OP-TEE is on the
> secure side or ROM is there.

OK thanks. So we could just modify the code dynamically on boot
based on if optee is found or not. The quirk could be done along
the lines of the qcom quirk but only for the non-optee case:

$ git grep -C10 ARM_SMCCC_QUIRK_QCOM_A6

Regards,

Tony

  reply	other threads:[~2019-11-19 19:44 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
2019-11-19 19:35                             ` Andrew F. Davis
2019-11-19 19:44                               ` Tony Lindgren [this message]
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=20191119194425.GQ35479@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;
as well as URLs for NNTP newsgroup(s).