From: kyungmin.park@samsung.com (Kyungmin Park)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 4/5] ARM: EXYNOS: Add support for Exynos secure firmware
Date: Sat, 22 Sep 2012 14:57:09 +0900 [thread overview]
Message-ID: <CAH9JG2WQ0ec0ytR1vTo+kFA88YPZYpSpCMBTuyCAX6tFafWY2A@mail.gmail.com> (raw)
In-Reply-To: <CAOesGMivzmbNxCeScBAhAzv+eOiF-bagLsW3WJzECaZEg5jFPg@mail.gmail.com>
On 9/22/12, Olof Johansson <olof@lixom.net> wrote:
> On Wed, Sep 19, 2012 at 3:10 AM, Tomasz Figa <t.figa@samsung.com> wrote:
>> Hi Olof,
>>
>> On Saturday 15 of September 2012 17:44:55 Olof Johansson wrote:
>>> On Thu, Sep 13, 2012 at 10:13:37AM +0200, Tomasz Figa wrote:
>>> > +static void __iomem *exynos_cpu_boot_reg(int cpu)
>>> > +{
>>> > + return S5P_VA_SYSRAM_NS + 0x1c + 4*cpu;
>>> > +}
>>>
>>> This communication area in sysram should probably be seen as a part of
>>> the firmware interface. It should thus be defined as part of the binding
>>> instead, i.e. through a reg property or similar there. That also would
>>> make it easy to convert to using ioremap() instead of iodesc tables,
>>> which always a nice thing.
>>
>> The problem with SYSRAM_NS is that it might be also used in other code,
>> not
>> related to firmware only. I don't know exactly all the use cases for it.
>
> If you don't know the use cases, and the use cases are not in the
> kernel tree that we care about here (upstream), then there's really
> nothing to worry about. It's after all just a define that's moved to
> an ioremap, if there's some out of tree code that needs the old legacy
> define then it can be added in whatever out-of-tree code that uses it.
> Right?
Now this address is used at cpu boot, cpuidle, inform at this time.
As it touched at several places, it's defined at iodesc. if it changed
with ioremap, it has to export remaped address and each codes should
use it.
As I wrote at cover letter, if you want to use ioremap, it can be
modified. however can you merge firmware codes itself? since ioremap
is not related with trustzone or firmware issues and it's exynos
specific implementation issues. Right?
Thank you,
Kyungmin Park
>
>> Is it really a big problem or we could let it be for now, merge the
>> patches
>> for firmware and then convert SYSRAM_NS to dynamic mapping when its
>> situation clarifies?
>
> What do you expect is required to clarify the situation, and when do
> you expect that to happen?
>
>
> -Olof
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc"
> in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
next prev parent reply other threads:[~2012-09-22 5:57 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-09-13 8:13 [PATCH 0/5] ARM: EXYNOS: Add secure firmware support Tomasz Figa
2012-09-13 8:13 ` [PATCH 1/5] ARM: EXYNOS: Add IO mapping for non-secure SYSRAM Tomasz Figa
2012-09-13 8:13 ` [PATCH 2/5] ARM: Add interface for registering and calling firmware-specific operations Tomasz Figa
2012-09-13 8:25 ` Tomasz Figa
2012-09-22 5:50 ` Olof Johansson
2012-09-22 6:01 ` Kyungmin Park
2012-09-22 6:23 ` Olof Johansson
2012-09-22 13:17 ` Tomasz Figa
2012-09-22 13:22 ` Russell King - ARM Linux
2012-09-13 8:13 ` [PATCH 3/5] ARM: EXYNOS: Add support for secure monitor calls Tomasz Figa
2012-09-13 8:13 ` [PATCH 4/5] ARM: EXYNOS: Add support for Exynos secure firmware Tomasz Figa
2012-09-16 0:44 ` Olof Johansson
2012-09-19 10:10 ` Tomasz Figa
2012-09-22 5:39 ` Olof Johansson
2012-09-22 5:57 ` Kyungmin Park [this message]
2012-09-22 6:36 ` Olof Johansson
2012-09-22 6:39 ` Kyungmin Park
2012-09-24 14:39 ` Tomasz Figa
2012-09-13 8:13 ` [PATCH 5/5] ARM: EXYNOS: Add secure firmware support to secondary CPU bring-up Tomasz Figa
2012-09-19 13:29 ` [PATCH 0/5] ARM: EXYNOS: Add secure firmware support Tomasz Figa
2012-09-21 8:39 ` Kyungmin Park
2012-09-22 5:52 ` Olof Johansson
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=CAH9JG2WQ0ec0ytR1vTo+kFA88YPZYpSpCMBTuyCAX6tFafWY2A@mail.gmail.com \
--to=kyungmin.park@samsung.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 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).