From: will.deacon@arm.com (Will Deacon)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v5 1/5] arm/arm64: add smccc ARCH32
Date: Tue, 15 Sep 2015 19:26:45 +0100 [thread overview]
Message-ID: <20150915182645.GQ31157@arm.com> (raw)
In-Reply-To: <20150914083029.GA13963@ermac>
On Mon, Sep 14, 2015 at 09:30:30AM +0100, Jens Wiklander wrote:
> On Fri, Aug 21, 2015 at 01:43:31PM +0200, Jens Wiklander wrote:
> > On Fri, Aug 21, 2015 at 10:24:30AM +0100, Will Deacon wrote:
> > > On Thu, Aug 20, 2015 at 12:37:29PM +0100, Jens Wiklander wrote:
> > > > On Wed, Aug 19, 2015 at 05:50:09PM +0100, Will Deacon wrote:
> > > > > On Wed, Aug 19, 2015 at 09:40:25AM +0100, Jens Wiklander wrote:
> > > > > > + mov x28, x0
> > > > > > + ldp w0, w1, [x28, #SMC_PARAM_W0_OFFS]
> > > > > > + ldp w2, w3, [x28, #SMC_PARAM_W2_OFFS]
> > > > > > + ldp w4, w5, [x28, #SMC_PARAM_W4_OFFS]
> > > > > > + ldp w6, w7, [x28, #SMC_PARAM_W6_OFFS]
> > > > > > + smc #0
> > > > > > + stp w0, w1, [x28, #SMC_PARAM_W0_OFFS]
> > > > > > + stp w2, w3, [x28, #SMC_PARAM_W2_OFFS]
> > > > > > + ldp x28, x30, [sp], #16
> > > > > > + ret
> > > > > > +ENDPROC(smccc_call32)
> > > > >
> > > > > Could we deal with this like we do for PSCI instead? (see
> > > > > __invoke_psci_fn_smc). We could also then rename psci-call.S to fw-call.S
> > > > > and stick this in there too.
> > > >
> > > > I assume you're referring to when to use "hvc" and "smc".
> > >
> > > No, I mean use a C prototype to avoid marshalling the parameters in assembly
> > > like this. As Rutland pointed out, the return value is a bit messy, but
> > > the arguments align nicely with the PCS afaict.
> >
> > If possible I'd like the function to have the same prototype for both
> > arm and arm64. For arm it's not possible to supply more than 4
> > parameters. To fully support SMC Calling Convention we need to be able
> > to pass 8 parameters and have 4 return values. The OP-TEE driver in this
> > patch set depends on this. I don't see how we can avoid the marshalling
> > here.
> >
> > We could have two versions of the SMCCC functions, one simplified which
> > only uses registers and one complete like this one with marshalling.
>
> Will, what do think about this?
I still think you should make use of a C prototype to avoid explicit
parameter marshalling in assembly. If you want to maintain a compatible
API between arm and arm64, then you can easily have an intermediate
function in arm64 that sits between the API entry point and the assembly.
Will
WARNING: multiple messages have this Message-ID (diff)
From: Will Deacon <will.deacon@arm.com>
To: Jens Wiklander <jens.wiklander@linaro.org>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
Arnd Bergmann <arnd@arndb.de>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Kees Cook <keescook@chromium.org>,
"valentin.manea@huawei.com" <valentin.manea@huawei.com>,
Mark Rutland <Mark.Rutland@arm.com>,
"javier@javigon.com" <javier@javigon.com>,
"emmanuel.michel@st.com" <emmanuel.michel@st.com>,
Michal Simek <michal.simek@xilinx.com>,
"jean-michel.delorme@st.com" <jean-michel.delorme@st.com>,
Jason Gunthorpe <jgunthorpe@obsidianresearch.com>,
Rob Herring <robh+dt@kernel.org>
Subject: Re: [PATCH v5 1/5] arm/arm64: add smccc ARCH32
Date: Tue, 15 Sep 2015 19:26:45 +0100 [thread overview]
Message-ID: <20150915182645.GQ31157@arm.com> (raw)
In-Reply-To: <20150914083029.GA13963@ermac>
On Mon, Sep 14, 2015 at 09:30:30AM +0100, Jens Wiklander wrote:
> On Fri, Aug 21, 2015 at 01:43:31PM +0200, Jens Wiklander wrote:
> > On Fri, Aug 21, 2015 at 10:24:30AM +0100, Will Deacon wrote:
> > > On Thu, Aug 20, 2015 at 12:37:29PM +0100, Jens Wiklander wrote:
> > > > On Wed, Aug 19, 2015 at 05:50:09PM +0100, Will Deacon wrote:
> > > > > On Wed, Aug 19, 2015 at 09:40:25AM +0100, Jens Wiklander wrote:
> > > > > > + mov x28, x0
> > > > > > + ldp w0, w1, [x28, #SMC_PARAM_W0_OFFS]
> > > > > > + ldp w2, w3, [x28, #SMC_PARAM_W2_OFFS]
> > > > > > + ldp w4, w5, [x28, #SMC_PARAM_W4_OFFS]
> > > > > > + ldp w6, w7, [x28, #SMC_PARAM_W6_OFFS]
> > > > > > + smc #0
> > > > > > + stp w0, w1, [x28, #SMC_PARAM_W0_OFFS]
> > > > > > + stp w2, w3, [x28, #SMC_PARAM_W2_OFFS]
> > > > > > + ldp x28, x30, [sp], #16
> > > > > > + ret
> > > > > > +ENDPROC(smccc_call32)
> > > > >
> > > > > Could we deal with this like we do for PSCI instead? (see
> > > > > __invoke_psci_fn_smc). We could also then rename psci-call.S to fw-call.S
> > > > > and stick this in there too.
> > > >
> > > > I assume you're referring to when to use "hvc" and "smc".
> > >
> > > No, I mean use a C prototype to avoid marshalling the parameters in assembly
> > > like this. As Rutland pointed out, the return value is a bit messy, but
> > > the arguments align nicely with the PCS afaict.
> >
> > If possible I'd like the function to have the same prototype for both
> > arm and arm64. For arm it's not possible to supply more than 4
> > parameters. To fully support SMC Calling Convention we need to be able
> > to pass 8 parameters and have 4 return values. The OP-TEE driver in this
> > patch set depends on this. I don't see how we can avoid the marshalling
> > here.
> >
> > We could have two versions of the SMCCC functions, one simplified which
> > only uses registers and one complete like this one with marshalling.
>
> Will, what do think about this?
I still think you should make use of a C prototype to avoid explicit
parameter marshalling in assembly. If you want to maintain a compatible
API between arm and arm64, then you can easily have an intermediate
function in arm64 that sits between the API entry point and the assembly.
Will
next prev parent reply other threads:[~2015-09-15 18:26 UTC|newest]
Thread overview: 47+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-08-19 8:40 [PATCH v5 0/5] generic TEE subsystem Jens Wiklander
2015-08-19 8:40 ` Jens Wiklander
2015-08-19 8:40 ` [PATCH v5 1/5] arm/arm64: add smccc ARCH32 Jens Wiklander
2015-08-19 8:40 ` Jens Wiklander
2015-08-19 10:56 ` Yury
2015-08-19 10:56 ` Yury
2015-08-20 7:23 ` Jens Wiklander
2015-08-20 7:23 ` Jens Wiklander
2015-08-20 7:23 ` Jens Wiklander
2015-08-19 16:50 ` Will Deacon
2015-08-19 16:50 ` Will Deacon
2015-08-20 11:35 ` Michal Simek
2015-08-20 11:35 ` Michal Simek
2015-08-20 11:37 ` Jens Wiklander
2015-08-20 11:37 ` Jens Wiklander
2015-08-20 21:30 ` Mark Rutland
2015-08-20 21:30 ` Mark Rutland
2015-08-20 21:30 ` Mark Rutland
2015-08-21 9:24 ` Will Deacon
2015-08-21 9:24 ` Will Deacon
2015-08-21 11:43 ` Jens Wiklander
2015-08-21 11:43 ` Jens Wiklander
2015-08-21 11:43 ` Jens Wiklander
2015-09-14 8:30 ` Jens Wiklander
2015-09-14 8:30 ` Jens Wiklander
2015-09-14 8:30 ` Jens Wiklander
2015-09-15 18:26 ` Will Deacon [this message]
2015-09-15 18:26 ` Will Deacon
2015-09-15 21:05 ` Jens Wiklander
2015-09-15 21:05 ` Jens Wiklander
2015-09-16 17:18 ` Will Deacon
2015-09-16 17:18 ` Will Deacon
2015-08-19 8:40 ` [PATCH v5 2/5] dt/bindings: add bindings for optee Jens Wiklander
2015-08-19 8:40 ` Jens Wiklander
2015-08-19 8:40 ` Jens Wiklander
2015-09-15 22:37 ` Rob Herring
2015-09-15 22:37 ` Rob Herring
2015-09-16 7:13 ` Jens Wiklander
2015-09-16 7:13 ` Jens Wiklander
2015-08-19 8:40 ` [PATCH v5 3/5] tee: generic TEE subsystem Jens Wiklander
2015-08-19 8:40 ` Jens Wiklander
2015-08-19 8:40 ` [PATCH v5 4/5] tee: add OP-TEE driver Jens Wiklander
2015-08-19 8:40 ` Jens Wiklander
2015-08-19 8:40 ` Jens Wiklander
2015-08-19 8:40 ` [PATCH v5 5/5] Documentation: tee subsystem and op-tee driver Jens Wiklander
2015-08-19 8:40 ` Jens Wiklander
2015-08-19 8:40 ` Jens Wiklander
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=20150915182645.GQ31157@arm.com \
--to=will.deacon@arm.com \
--cc=linux-arm-kernel@lists.infradead.org \
/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.