From: arnd@arndb.de (Arnd Bergmann)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC PATCH] ARM: Make a compile trustzone conditionally
Date: Wed, 20 Jun 2012 16:01:51 +0000 [thread overview]
Message-ID: <201206201601.51368.arnd@arndb.de> (raw)
In-Reply-To: <20120620144111.GC2179@linaro.org>
On Wednesday 20 June 2012, Dave Martin wrote:
> From my point of view, the name "smc ops" is a bit bogus. Really these are
> platform-specific hooks which may need to be handled by firmware depending
> on the configuration, and the fact that they may be implemented by calling
> SMC is more of an implementation detail of one of the alternative
> implementations of those hooks.
>
> So your struct might instead be called struct exynos4_firmware_ops, and
> your two instances might be called exynos4_native_firmware_ops and
> exynos4_smc_firmware_ops, or similar. This is purely cosmetic, though.
>
> As discussed in previous mails, the best way to choose which struct
> exynos4_firmware_ops to use may be to scan for something in the device
> tree, rather than using some scary probing hack.
Naming it firmware_ops rather than smc_ops sounds reasonable.
> If we have standard DT bindings for this stuff, we could have generic DT
> support code for selecting the correct exynos4_firmware_ops structure
> based on the DT. Only the definition and contents of the platform-
> specific firmware_ops structs would need to vary.
>
> Whether we could end up with a common firmware_ops structure across all
> platforms is less certain (?)
I would prefer to have a common one. Ideally I'd also like to see a
standardized firmware binary interface so that we can actually
have a generic instance of this structure for all platforms that
follow the standard and let the nonstandard ones provide their own
instance of this struct. We might need more than one standard though,
e.g. one for direct SMC calls and another one for ACPI in the future.
If we want to do something local to each platform, I would not even
call it firmware_ops, but just do whatever that platform needs.
In case of exynos, having two implementations of the pm_interface
as Kyungmin suggested sounds sufficient there, and we can do something
else for the next part of the platform that needs it.
If we want to have a more generic way to do it, I'd go all the way
and make it a platform-independent structure.
Arnd
next prev parent reply other threads:[~2012-06-20 16:01 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-06-11 5:15 [RFC PATCH] ARM: Make a compile trustzone conditionally Kyungmin Park
2012-06-18 0:58 ` Kyungmin Park
2012-06-18 1:10 ` Olof Johansson
2012-06-18 4:37 ` Kyungmin Park
2012-06-18 14:10 ` Arnd Bergmann
2012-06-19 6:50 ` Kyungmin Park
2012-06-20 11:14 ` Arnd Bergmann
2012-06-20 14:41 ` Dave Martin
2012-06-20 16:01 ` Arnd Bergmann [this message]
2012-06-20 1:22 ` Stephen Boyd
2012-06-20 9:43 ` Will Deacon
2012-06-20 10:51 ` Bindings for SMC/HVC firmware interfaces on ARM (Re: [RFC PATCH] ARM: Make a compile trustzone conditionally) Dave Martin
2012-06-20 15:14 ` Rob Herring
2012-06-20 15:34 ` Dave Martin
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=201206201601.51368.arnd@arndb.de \
--to=arnd@arndb.de \
--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 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).