From: sboyd@codeaurora.org (Stephen Boyd)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v2] clocksource: arch_timer: Allow the device tree to specify the physical timer
Date: Fri, 12 Sep 2014 11:59:29 -0700 [thread overview]
Message-ID: <54134291.3040700@codeaurora.org> (raw)
In-Reply-To: <5412E3BB.9030800@arm.com>
On 09/12/14 05:14, Marc Zyngier wrote:
> Hi Christopher,
>
> On 12/09/14 12:43, Christopher Covington wrote:
>> Hi Marc,
>>
>> On 09/11/2014 01:43 PM, Marc Zyngier wrote:
>>> On 11/09/14 18:29, Doug Anderson wrote:
>>>
>>>> I did this in the past (again, see Sonny's thread), but didn't
>>>> consider myself knowledgeable to know if that was truly a good test:
>>>>
>>>> asm volatile("mrc p15, 0, %0, c1, c1, 0" : "=r" (val));
>>>> pr_info("DOUG: val is %#010x", val);
>>>> val |= (1 << 2);
>>>> asm volatile("mcr p15, 0, %0, c1, c1, 0" : : "r" (val));
>>>> val = 0xffffffff;
>>>> asm volatile("mrc p15, 0, %0, c1, c1, 0" : "=r" (val));
>>>> pr_info("DOUG: val is %#010x", val);
>>>>
>>>> The idea being that if you can make modifications to the SCR register
>>>> (and see your changes take effect) then you must be in secure mode.
>>>> In my case the first printout was 0x0 and the second was 0x4.
>>> The main issue is when you're *not* in secure mode. It is likely that
>>> this will explode badly. This is why I suggested something that is set
>>> by the bootloader (after all. it knows which mode it is booted in), and
>>> that the timer driver can use when the CPU comes up.
>> What exactly does "exploding badly" look like? Causing and undefined
>> instruction exception? That's just a branch with a mode switch. Any reason the
>> code couldn't deal with that or even use that to its advantage?
> We surely can handle the UNDEF and do something there. We just can't do
> it the way Doug described it above.
>
>
I suggested doing that for something else a while ago and Will and Dave
we're not thrilled[1]. The suggestion back then was to use DT to
indicate what mode the kernel is running in.
[1]
http://lists.infradead.org/pipermail/linux-arm-kernel/2012-June/105321.html
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
WARNING: multiple messages have this Message-ID (diff)
From: Stephen Boyd <sboyd-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
To: Marc Zyngier <marc.zyngier-5wv7dgnIgG8@public.gmane.org>,
Christopher Covington
<cov-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
Cc: Doug Anderson <dianders-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>,
Will Deacon <Will.Deacon-5wv7dgnIgG8@public.gmane.org>,
"olof-nZhT3qVonbNeoWH0uzbU5w@public.gmane.org"
<olof-nZhT3qVonbNeoWH0uzbU5w@public.gmane.org>,
Sonny Rao <sonnyrao-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>,
Catalin Marinas <Catalin.Marinas-5wv7dgnIgG8@public.gmane.org>,
Mark Rutland <Mark.Rutland-5wv7dgnIgG8@public.gmane.org>,
Sudeep Holla <Sudeep.Holla-5wv7dgnIgG8@public.gmane.org>,
Lorenzo Pieralisi
<Lorenzo.Pieralisi-5wv7dgnIgG8@public.gmane.org>,
Thomas Gleixner <tglx-hfZtesqFncYOwBW4kG4KsQ@public.gmane.org>,
Daniel Lezcano
<daniel.lezcano-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>,
Nathan Lynch
<Nathan_Lynch-nmGgyN9QBj3QT0dZR+AlfA@public.gmane.org>,
"linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org"
<linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org>,
"robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org"
<robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
Pawel Moll <Pawel.Moll-5wv7dgnIgG8@public.gmane.org>,
"ijc+devicetree-KcIKpvwj1kUDXYZnReoRVg@public.gmane.org"
<ijc+devicetree-KcIKpvwj1kUDXYZnReoRVg@public.gmane.org>,
"galak-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org"
<galak-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>,
"devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
"linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
Subject: Re: [PATCH v2] clocksource: arch_timer: Allow the device tree to specify the physical timer
Date: Fri, 12 Sep 2014 11:59:29 -0700 [thread overview]
Message-ID: <54134291.3040700@codeaurora.org> (raw)
In-Reply-To: <5412E3BB.9030800-5wv7dgnIgG8@public.gmane.org>
On 09/12/14 05:14, Marc Zyngier wrote:
> Hi Christopher,
>
> On 12/09/14 12:43, Christopher Covington wrote:
>> Hi Marc,
>>
>> On 09/11/2014 01:43 PM, Marc Zyngier wrote:
>>> On 11/09/14 18:29, Doug Anderson wrote:
>>>
>>>> I did this in the past (again, see Sonny's thread), but didn't
>>>> consider myself knowledgeable to know if that was truly a good test:
>>>>
>>>> asm volatile("mrc p15, 0, %0, c1, c1, 0" : "=r" (val));
>>>> pr_info("DOUG: val is %#010x", val);
>>>> val |= (1 << 2);
>>>> asm volatile("mcr p15, 0, %0, c1, c1, 0" : : "r" (val));
>>>> val = 0xffffffff;
>>>> asm volatile("mrc p15, 0, %0, c1, c1, 0" : "=r" (val));
>>>> pr_info("DOUG: val is %#010x", val);
>>>>
>>>> The idea being that if you can make modifications to the SCR register
>>>> (and see your changes take effect) then you must be in secure mode.
>>>> In my case the first printout was 0x0 and the second was 0x4.
>>> The main issue is when you're *not* in secure mode. It is likely that
>>> this will explode badly. This is why I suggested something that is set
>>> by the bootloader (after all. it knows which mode it is booted in), and
>>> that the timer driver can use when the CPU comes up.
>> What exactly does "exploding badly" look like? Causing and undefined
>> instruction exception? That's just a branch with a mode switch. Any reason the
>> code couldn't deal with that or even use that to its advantage?
> We surely can handle the UNDEF and do something there. We just can't do
> it the way Doug described it above.
>
>
I suggested doing that for something else a while ago and Will and Dave
we're not thrilled[1]. The suggestion back then was to use DT to
indicate what mode the kernel is running in.
[1]
http://lists.infradead.org/pipermail/linux-arm-kernel/2012-June/105321.html
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
--
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: Stephen Boyd <sboyd@codeaurora.org>
To: Marc Zyngier <marc.zyngier@arm.com>,
Christopher Covington <cov@codeaurora.org>
Cc: Doug Anderson <dianders@chromium.org>,
Will Deacon <Will.Deacon@arm.com>,
"olof@lixom.net" <olof@lixom.net>,
Sonny Rao <sonnyrao@chromium.org>,
Catalin Marinas <Catalin.Marinas@arm.com>,
Mark Rutland <Mark.Rutland@arm.com>,
Sudeep Holla <Sudeep.Holla@arm.com>,
Lorenzo Pieralisi <Lorenzo.Pieralisi@arm.com>,
Thomas Gleixner <tglx@linutronix.de>,
Daniel Lezcano <daniel.lezcano@linaro.org>,
Nathan Lynch <Nathan_Lynch@mentor.com>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"robh+dt@kernel.org" <robh+dt@kernel.org>,
Pawel Moll <Pawel.Moll@arm.com>,
"ijc+devicetree@hellion.org.uk" <ijc+devicetree@hellion.org.uk>,
"galak@codeaurora.org" <galak@codeaurora.org>,
"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v2] clocksource: arch_timer: Allow the device tree to specify the physical timer
Date: Fri, 12 Sep 2014 11:59:29 -0700 [thread overview]
Message-ID: <54134291.3040700@codeaurora.org> (raw)
In-Reply-To: <5412E3BB.9030800@arm.com>
On 09/12/14 05:14, Marc Zyngier wrote:
> Hi Christopher,
>
> On 12/09/14 12:43, Christopher Covington wrote:
>> Hi Marc,
>>
>> On 09/11/2014 01:43 PM, Marc Zyngier wrote:
>>> On 11/09/14 18:29, Doug Anderson wrote:
>>>
>>>> I did this in the past (again, see Sonny's thread), but didn't
>>>> consider myself knowledgeable to know if that was truly a good test:
>>>>
>>>> asm volatile("mrc p15, 0, %0, c1, c1, 0" : "=r" (val));
>>>> pr_info("DOUG: val is %#010x", val);
>>>> val |= (1 << 2);
>>>> asm volatile("mcr p15, 0, %0, c1, c1, 0" : : "r" (val));
>>>> val = 0xffffffff;
>>>> asm volatile("mrc p15, 0, %0, c1, c1, 0" : "=r" (val));
>>>> pr_info("DOUG: val is %#010x", val);
>>>>
>>>> The idea being that if you can make modifications to the SCR register
>>>> (and see your changes take effect) then you must be in secure mode.
>>>> In my case the first printout was 0x0 and the second was 0x4.
>>> The main issue is when you're *not* in secure mode. It is likely that
>>> this will explode badly. This is why I suggested something that is set
>>> by the bootloader (after all. it knows which mode it is booted in), and
>>> that the timer driver can use when the CPU comes up.
>> What exactly does "exploding badly" look like? Causing and undefined
>> instruction exception? That's just a branch with a mode switch. Any reason the
>> code couldn't deal with that or even use that to its advantage?
> We surely can handle the UNDEF and do something there. We just can't do
> it the way Doug described it above.
>
>
I suggested doing that for something else a while ago and Will and Dave
we're not thrilled[1]. The suggestion back then was to use DT to
indicate what mode the kernel is running in.
[1]
http://lists.infradead.org/pipermail/linux-arm-kernel/2012-June/105321.html
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
next prev parent reply other threads:[~2014-09-12 18:59 UTC|newest]
Thread overview: 82+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-09-11 16:16 [PATCH v2] clocksource: arch_timer: Allow the device tree to specify the physical timer Doug Anderson
2014-09-11 16:16 ` Doug Anderson
2014-09-11 16:47 ` Will Deacon
2014-09-11 16:47 ` Will Deacon
2014-09-11 16:47 ` Will Deacon
2014-09-11 16:59 ` Doug Anderson
2014-09-11 16:59 ` Doug Anderson
2014-09-11 16:59 ` Doug Anderson
2014-09-11 17:07 ` Will Deacon
2014-09-11 17:07 ` Will Deacon
2014-09-11 17:14 ` Doug Anderson
2014-09-11 17:14 ` Doug Anderson
2014-09-11 17:00 ` Marc Zyngier
2014-09-11 17:00 ` Marc Zyngier
2014-09-11 17:11 ` Doug Anderson
2014-09-11 17:11 ` Doug Anderson
2014-09-11 17:11 ` Doug Anderson
2014-09-11 17:22 ` Marc Zyngier
2014-09-11 17:22 ` Marc Zyngier
2014-09-11 17:22 ` Marc Zyngier
2014-09-11 17:29 ` Doug Anderson
2014-09-11 17:29 ` Doug Anderson
2014-09-11 17:29 ` Doug Anderson
2014-09-11 17:43 ` Marc Zyngier
2014-09-11 17:43 ` Marc Zyngier
2014-09-11 17:43 ` Marc Zyngier
2014-09-11 23:55 ` Doug Anderson
2014-09-11 23:55 ` Doug Anderson
2014-09-11 23:55 ` Doug Anderson
2014-09-11 23:56 ` Stephen Boyd
2014-09-11 23:56 ` Stephen Boyd
2014-09-11 23:56 ` Stephen Boyd
2014-09-12 0:01 ` Doug Anderson
2014-09-12 0:01 ` Doug Anderson
2014-09-12 0:01 ` Doug Anderson
2014-09-12 10:20 ` Marc Zyngier
2014-09-12 10:20 ` Marc Zyngier
2014-09-12 0:14 ` Sonny Rao
2014-09-12 1:17 ` Stephen Boyd
2014-09-12 3:25 ` Sonny Rao
2014-09-12 3:25 ` Sonny Rao
2014-09-12 3:25 ` Sonny Rao
2014-09-12 11:43 ` Christopher Covington
2014-09-12 11:43 ` Christopher Covington
2014-09-12 11:43 ` Christopher Covington
2014-09-12 12:14 ` Marc Zyngier
2014-09-12 12:14 ` Marc Zyngier
2014-09-12 18:59 ` Stephen Boyd [this message]
2014-09-12 18:59 ` Stephen Boyd
2014-09-12 18:59 ` Stephen Boyd
2014-09-15 11:10 ` Catalin Marinas
2014-09-15 11:10 ` Catalin Marinas
2014-09-15 11:10 ` Catalin Marinas
2014-09-15 20:33 ` Stephen Boyd
2014-09-15 20:33 ` Stephen Boyd
2014-09-15 21:47 ` Sonny Rao
2014-09-15 21:47 ` Sonny Rao
2014-09-15 21:47 ` Sonny Rao
2014-09-15 21:49 ` Stephen Boyd
2014-09-15 21:49 ` Stephen Boyd
2014-09-15 21:49 ` Stephen Boyd
2014-09-15 21:52 ` Sonny Rao
2014-09-15 21:52 ` Sonny Rao
2014-09-15 21:52 ` Sonny Rao
2014-09-15 22:04 ` Sonny Rao
2014-09-15 22:04 ` Sonny Rao
2014-09-15 22:04 ` Sonny Rao
2014-09-15 22:51 ` Christopher Covington
2014-09-15 22:51 ` Christopher Covington
2014-09-15 22:51 ` Christopher Covington
2014-09-16 0:24 ` Sonny Rao
2014-09-16 0:24 ` Sonny Rao
2014-09-16 0:24 ` Sonny Rao
2014-09-16 10:42 ` Catalin Marinas
2014-09-16 10:42 ` Catalin Marinas
2014-09-16 10:42 ` Catalin Marinas
2014-09-16 11:22 ` Christopher Covington
2014-09-16 11:22 ` Christopher Covington
2014-09-16 11:22 ` Christopher Covington
2014-09-16 11:03 ` Catalin Marinas
2014-09-16 11:03 ` Catalin Marinas
2014-09-16 11:03 ` Catalin Marinas
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=54134291.3040700@codeaurora.org \
--to=sboyd@codeaurora.org \
--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.