From: Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org>
To: Carlo Caione <carlo-KA+7E9HrN00dnm+yROfE0A@public.gmane.org>
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
arnd-r2nGTMty4D4@public.gmane.org,
khilman-rdvid1DuHRBWk0Htik3J/w@public.gmane.org,
jens.wiklander-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org,
matthias.bgg-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org,
linux-amlogic-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
linux-6IF/jdPJHihWk0Htik3J/w@public.gmane.org,
afaerber-l3A5Bk7waGM@public.gmane.org,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
Subject: Re: [PATCH v3 4/4] documentation: Add secure monitor binding documentation
Date: Mon, 23 May 2016 18:11:59 +0100 [thread overview]
Message-ID: <20160523171159.GH4976@leverpostej> (raw)
In-Reply-To: <20160523165931.GA31299@mephisto>
On Mon, May 23, 2016 at 06:59:31PM +0200, Carlo Caione wrote:
> On 23/05/16 17:38, Mark Rutland wrote:
> > > +Required properties for the secure monitor node:
> > > +- compatible: Should be "amlogic,meson-sm"
> > > +- amlogic,sm-cmd-input-base: SMC32 function identifier to read the physical
> > > + address of the input buffer
> > > +- amlogic,sm-cmd-output-base: SMC32 function identifier to read the physical
> > > + address of the output buffer
> >
> > Do the IDs for these actually differ per board?
>
> I expect these to differ per SoC (GXBB in this case), not per board. The
> driver is generic enough to be (hopefully) used for several SoCs just
> changing the related header file that defines the SCM commands.
>
> > Are some functions simply not implemented on some boards?
>
> I don't think this is possible.
Given that, I think it may be better to just have a
"amlogic,meson-gxbb-sm" compatible string, and derive the set of
functions and associated IDs from that.
That is, unless you know that future revisions have functions with the
exact same semantics but differing IDs.
Regardless, it would make sense to have a GXBB-specific compatible
string prepended to the list. That way in the future we can handle
anything specific to the GXBB variant of the secure monitor if
necessary.
Thanks,
Mark.
--
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: mark.rutland@arm.com (Mark Rutland)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v3 4/4] documentation: Add secure monitor binding documentation
Date: Mon, 23 May 2016 18:11:59 +0100 [thread overview]
Message-ID: <20160523171159.GH4976@leverpostej> (raw)
In-Reply-To: <20160523165931.GA31299@mephisto>
On Mon, May 23, 2016 at 06:59:31PM +0200, Carlo Caione wrote:
> On 23/05/16 17:38, Mark Rutland wrote:
> > > +Required properties for the secure monitor node:
> > > +- compatible: Should be "amlogic,meson-sm"
> > > +- amlogic,sm-cmd-input-base: SMC32 function identifier to read the physical
> > > + address of the input buffer
> > > +- amlogic,sm-cmd-output-base: SMC32 function identifier to read the physical
> > > + address of the output buffer
> >
> > Do the IDs for these actually differ per board?
>
> I expect these to differ per SoC (GXBB in this case), not per board. The
> driver is generic enough to be (hopefully) used for several SoCs just
> changing the related header file that defines the SCM commands.
>
> > Are some functions simply not implemented on some boards?
>
> I don't think this is possible.
Given that, I think it may be better to just have a
"amlogic,meson-gxbb-sm" compatible string, and derive the set of
functions and associated IDs from that.
That is, unless you know that future revisions have functions with the
exact same semantics but differing IDs.
Regardless, it would make sense to have a GXBB-specific compatible
string prepended to the list. That way in the future we can handle
anything specific to the GXBB variant of the secure monitor if
necessary.
Thanks,
Mark.
WARNING: multiple messages have this Message-ID (diff)
From: mark.rutland@arm.com (Mark Rutland)
To: linus-amlogic@lists.infradead.org
Subject: [PATCH v3 4/4] documentation: Add secure monitor binding documentation
Date: Mon, 23 May 2016 18:11:59 +0100 [thread overview]
Message-ID: <20160523171159.GH4976@leverpostej> (raw)
In-Reply-To: <20160523165931.GA31299@mephisto>
On Mon, May 23, 2016 at 06:59:31PM +0200, Carlo Caione wrote:
> On 23/05/16 17:38, Mark Rutland wrote:
> > > +Required properties for the secure monitor node:
> > > +- compatible: Should be "amlogic,meson-sm"
> > > +- amlogic,sm-cmd-input-base: SMC32 function identifier to read the physical
> > > + address of the input buffer
> > > +- amlogic,sm-cmd-output-base: SMC32 function identifier to read the physical
> > > + address of the output buffer
> >
> > Do the IDs for these actually differ per board?
>
> I expect these to differ per SoC (GXBB in this case), not per board. The
> driver is generic enough to be (hopefully) used for several SoCs just
> changing the related header file that defines the SCM commands.
>
> > Are some functions simply not implemented on some boards?
>
> I don't think this is possible.
Given that, I think it may be better to just have a
"amlogic,meson-gxbb-sm" compatible string, and derive the set of
functions and associated IDs from that.
That is, unless you know that future revisions have functions with the
exact same semantics but differing IDs.
Regardless, it would make sense to have a GXBB-specific compatible
string prepended to the list. That way in the future we can handle
anything specific to the GXBB variant of the secure monitor if
necessary.
Thanks,
Mark.
next prev parent reply other threads:[~2016-05-23 17:11 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-05-23 16:30 [PATCH v3 0/4] Add Amlogic secure monitor driver Carlo Caione
2016-05-23 16:30 ` Carlo Caione
2016-05-23 16:30 ` Carlo Caione
[not found] ` <1464021024-29380-1-git-send-email-carlo-KA+7E9HrN00dnm+yROfE0A@public.gmane.org>
2016-05-23 16:30 ` [PATCH v3 1/4] firmware: Amlogic: Add " Carlo Caione
2016-05-23 16:30 ` Carlo Caione
2016-05-23 16:30 ` Carlo Caione
[not found] ` <1464021024-29380-2-git-send-email-carlo-KA+7E9HrN00dnm+yROfE0A@public.gmane.org>
2016-05-23 20:58 ` Kevin Hilman
2016-05-23 20:58 ` Kevin Hilman
2016-05-23 20:58 ` Kevin Hilman
[not found] ` <m2posco5k2.fsf-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
2016-05-24 8:08 ` Carlo Caione
2016-05-24 8:08 ` Carlo Caione
2016-05-24 8:08 ` Carlo Caione
2016-05-23 16:30 ` [PATCH v3 2/4] firmware: dt-bindings: Add secure monitor header file for GXBB Carlo Caione
2016-05-23 16:30 ` Carlo Caione
2016-05-23 16:30 ` Carlo Caione
2016-05-23 16:30 ` [PATCH v3 3/4] ARM64: dts: amlogic: gxbb: Enable secure monitor Carlo Caione
2016-05-23 16:30 ` Carlo Caione
2016-05-23 16:30 ` Carlo Caione
2016-05-23 16:30 ` [PATCH v3 4/4] documentation: Add secure monitor binding documentation Carlo Caione
2016-05-23 16:30 ` Carlo Caione
2016-05-23 16:30 ` Carlo Caione
[not found] ` <1464021024-29380-5-git-send-email-carlo-KA+7E9HrN00dnm+yROfE0A@public.gmane.org>
2016-05-23 16:38 ` Mark Rutland
2016-05-23 16:38 ` Mark Rutland
2016-05-23 16:38 ` Mark Rutland
2016-05-23 16:59 ` Carlo Caione
2016-05-23 16:59 ` Carlo Caione
2016-05-23 16:59 ` Carlo Caione
2016-05-23 17:11 ` Mark Rutland [this message]
2016-05-23 17:11 ` Mark Rutland
2016-05-23 17:11 ` Mark Rutland
2016-05-24 8:03 ` Carlo Caione
2016-05-24 8:03 ` Carlo Caione
2016-05-24 8:03 ` Carlo Caione
2016-05-23 17:04 ` [PATCH v3 0/4] Add Amlogic secure monitor driver Matthias Brugger
2016-05-23 17:04 ` Matthias Brugger
2016-05-23 17:04 ` Matthias Brugger
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=20160523171159.GH4976@leverpostej \
--to=mark.rutland-5wv7dgnigg8@public.gmane.org \
--cc=afaerber-l3A5Bk7waGM@public.gmane.org \
--cc=arnd-r2nGTMty4D4@public.gmane.org \
--cc=carlo-KA+7E9HrN00dnm+yROfE0A@public.gmane.org \
--cc=devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=jens.wiklander-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org \
--cc=khilman-rdvid1DuHRBWk0Htik3J/w@public.gmane.org \
--cc=linux-6IF/jdPJHihWk0Htik3J/w@public.gmane.org \
--cc=linux-amlogic-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
--cc=linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
--cc=matthias.bgg-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
--cc=robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.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.