From: will.deacon@arm.com (Will Deacon)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v6 1/6] arm/arm64: add smccc
Date: Mon, 2 Nov 2015 14:45:22 +0000 [thread overview]
Message-ID: <20151102144521.GG29657@arm.com> (raw)
In-Reply-To: <20151102140313.GG2684@leverpostej>
On Mon, Nov 02, 2015 at 02:03:13PM +0000, Mark Rutland wrote:
> > > > +/**
> > > > + * struct smccc_res - Result from SMC/HVC call
> > > > + * @a0-a3 result values from registers 0 to 3
> > > > + */
> > > > +struct smccc_res {
> > > > + unsigned long a0;
> > > > + unsigned long a1;
> > > > + unsigned long a2;
> > > > + unsigned long a3;
> > > > +};
> > >
> > > Are there any endianness considerations for this structure?
> >
> > No, I can't find anything in the ARM SMC Calling Convention document
> > indicating that.
>
> The calling conventions have no bearing on the structure, which is our
> invention.
>
> We stash register values (which don't have endianness) returned by the
> firmeware into the structure in the sequences above (which appear
> endian-clean to me).
Ah yes, the structure is populated by the kernel not the firmware, so
there's nothing to worry about. Thanks for the explanation.
Will
WARNING: multiple messages have this Message-ID (diff)
From: Will Deacon <will.deacon-5wv7dgnIgG8@public.gmane.org>
To: Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org>
Cc: Jens Wiklander
<jens.wiklander-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org>,
Greg Kroah-Hartman
<gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org>,
Kees Cook <keescook-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>,
valentin.manea-hv44wF8Li93QT0dZR+AlfA@public.gmane.org,
jean-michel.delorme-qxv4g6HH51o@public.gmane.org,
emmanuel.michel-qxv4g6HH51o@public.gmane.org,
javier-5MUHepqpBA1BDgjK7y7TUQ@public.gmane.org,
Jason Gunthorpe
<jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>,
Michal Simek
<michal.simek-gjFFaj9aHVfQT0dZR+AlfA@public.gmane.org>,
Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Subject: Re: [PATCH v6 1/6] arm/arm64: add smccc
Date: Mon, 2 Nov 2015 14:45:22 +0000 [thread overview]
Message-ID: <20151102144521.GG29657@arm.com> (raw)
In-Reply-To: <20151102140313.GG2684@leverpostej>
On Mon, Nov 02, 2015 at 02:03:13PM +0000, Mark Rutland wrote:
> > > > +/**
> > > > + * struct smccc_res - Result from SMC/HVC call
> > > > + * @a0-a3 result values from registers 0 to 3
> > > > + */
> > > > +struct smccc_res {
> > > > + unsigned long a0;
> > > > + unsigned long a1;
> > > > + unsigned long a2;
> > > > + unsigned long a3;
> > > > +};
> > >
> > > Are there any endianness considerations for this structure?
> >
> > No, I can't find anything in the ARM SMC Calling Convention document
> > indicating that.
>
> The calling conventions have no bearing on the structure, which is our
> invention.
>
> We stash register values (which don't have endianness) returned by the
> firmeware into the structure in the sequences above (which appear
> endian-clean to me).
Ah yes, the structure is populated by the kernel not the firmware, so
there's nothing to worry about. Thanks for the explanation.
Will
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
WARNING: multiple messages have this Message-ID (diff)
From: Will Deacon <will.deacon@arm.com>
To: Mark Rutland <mark.rutland@arm.com>
Cc: Jens Wiklander <jens.wiklander@linaro.org>,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.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, jean-michel.delorme@st.com,
emmanuel.michel@st.com, javier@javigon.com,
Jason Gunthorpe <jgunthorpe@obsidianresearch.com>,
Michal Simek <michal.simek@xilinx.com>,
Rob Herring <robh+dt@kernel.org>
Subject: Re: [PATCH v6 1/6] arm/arm64: add smccc
Date: Mon, 2 Nov 2015 14:45:22 +0000 [thread overview]
Message-ID: <20151102144521.GG29657@arm.com> (raw)
In-Reply-To: <20151102140313.GG2684@leverpostej>
On Mon, Nov 02, 2015 at 02:03:13PM +0000, Mark Rutland wrote:
> > > > +/**
> > > > + * struct smccc_res - Result from SMC/HVC call
> > > > + * @a0-a3 result values from registers 0 to 3
> > > > + */
> > > > +struct smccc_res {
> > > > + unsigned long a0;
> > > > + unsigned long a1;
> > > > + unsigned long a2;
> > > > + unsigned long a3;
> > > > +};
> > >
> > > Are there any endianness considerations for this structure?
> >
> > No, I can't find anything in the ARM SMC Calling Convention document
> > indicating that.
>
> The calling conventions have no bearing on the structure, which is our
> invention.
>
> We stash register values (which don't have endianness) returned by the
> firmeware into the structure in the sequences above (which appear
> endian-clean to me).
Ah yes, the structure is populated by the kernel not the firmware, so
there's nothing to worry about. Thanks for the explanation.
Will
next prev parent reply other threads:[~2015-11-02 14:45 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-10-29 8:21 [PATCH v6 0/6] generic TEE subsystem Jens Wiklander
2015-10-29 8:21 ` Jens Wiklander
2015-10-29 8:21 ` Jens Wiklander
2015-10-29 8:21 ` [PATCH v6 1/6] arm/arm64: add smccc Jens Wiklander
2015-10-29 8:21 ` Jens Wiklander
2015-10-29 8:21 ` Jens Wiklander
2015-11-02 11:51 ` Will Deacon
2015-11-02 11:51 ` Will Deacon
2015-11-02 11:51 ` Will Deacon
2015-11-02 13:56 ` Jens Wiklander
2015-11-02 13:56 ` Jens Wiklander
2015-11-02 14:03 ` Mark Rutland
2015-11-02 14:03 ` Mark Rutland
2015-11-02 14:03 ` Mark Rutland
2015-11-02 14:45 ` Will Deacon [this message]
2015-11-02 14:45 ` Will Deacon
2015-11-02 14:45 ` Will Deacon
2015-10-29 8:21 ` [PATCH v6 2/6] drivers: psci: replace psci firmware calls Jens Wiklander
2015-10-29 8:21 ` Jens Wiklander
2015-10-29 8:21 ` Jens Wiklander
2015-11-02 11:55 ` Will Deacon
2015-11-02 11:55 ` Will Deacon
2015-11-02 11:55 ` Will Deacon
2015-11-02 13:08 ` Jens Wiklander
2015-11-02 13:08 ` Jens Wiklander
2015-11-02 13:08 ` Jens Wiklander
2015-11-02 13:46 ` Will Deacon
2015-11-02 13:46 ` Will Deacon
2015-11-02 13:46 ` Will Deacon
2015-10-29 8:21 ` [PATCH v6 3/6] dt/bindings: add bindings for optee Jens Wiklander
2015-10-29 8:21 ` Jens Wiklander
2015-11-16 17:01 ` Rob Herring
2015-11-16 17:01 ` Rob Herring
2015-11-19 9:18 ` Jens Wiklander
2015-11-19 9:18 ` Jens Wiklander
2015-11-19 9:18 ` Jens Wiklander
2015-11-19 14:30 ` Rob Herring
2015-11-19 14:30 ` Rob Herring
2015-10-29 8:21 ` [PATCH v6 4/6] tee: generic TEE subsystem Jens Wiklander
2015-10-29 8:21 ` Jens Wiklander
2015-10-29 8:21 ` Jens Wiklander
2015-10-29 8:21 ` [PATCH v6 5/6] tee: add OP-TEE driver Jens Wiklander
2015-10-29 8:21 ` Jens Wiklander
2015-10-29 8:21 ` [PATCH v6 6/6] Documentation: tee subsystem and op-tee driver Jens Wiklander
2015-10-29 8:21 ` 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=20151102144521.GG29657@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.