linux-kernel - [PATCH] RFC: nomadik: expand timesource to 63 bits

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 11 Nov 2010 10:05:56 +0100
From:	Linus Walleij <linus.walleij@...ricsson.com>
To:	linux-kernel@...r.kernel.org, Thomas Gleixner <tglx@...utronix.de>,
	Nicolas Pitre <nico@...xnic.net>
Cc:	linux-arm-kernel@...ts.infradead.org,
	Linus Walleij <linus.walleij@...ricsson.com>,
	Colin Cross <ccross@...gle.com>,
	Rabin Vincent <rabin.vincent@...ricsson.com>
Subject: [PATCH] RFC: nomadik: expand timesource to 63 bits

After wraparound-problems in sched_clock() we expand the 32bit
timer in the MTU from 32 to 63 bits so the scheduling and
timeline is more stable. At current max operating frequency for
the MTU, 133 MHz, this should be sufficient for rougly 2200
years.

Cc: Colin Cross <ccross@...gle.com>
Cc: Rabin Vincent <rabin.vincent@...ricsson.com>
Signed-off-by: Linus Walleij <linus.walleij@...ricsson.com>
---
tglx, nico: can you help out on reviewing this?

The solution in this patch is based on the similar approach
taken by the Tegra platform in arch/arm/mach-tegra/timer.c.

Orion on the other hand will only expand the timer to 63
bits in the sched_clock() function in arch/arm/plat-orion/time.c

What we need to know is whether it's OK to simply blow up
clocksource to 63 bits like this. In that case this
simplification should also apply to Orion, meaning that it
would base it's sched_clock() on the clocksource, using
simply clocksource_cyc2ns() cutting down the code
significantly.

My main obstacle is that I cannot really determine whether
clocksource.read() will be called often enough for the
cnt32_to_63 algorithm.

If this won't work the Tegra platform probably needs fixing
too.

We had a rather heated debate about this internally already
so I'm seeking the advice of the elders.
---
 arch/arm/plat-nomadik/timer.c |    5 +++--
 1 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/arch/arm/plat-nomadik/timer.c b/arch/arm/plat-nomadik/timer.c
index aedf9c1..e887bf8 100644
--- a/arch/arm/plat-nomadik/timer.c
+++ b/arch/arm/plat-nomadik/timer.c
@@ -16,6 +16,7 @@
 #include <linux/clk.h>
 #include <linux/jiffies.h>
 #include <linux/err.h>
+#include <linux/cnt32_to_63.h>
 #include <asm/mach/time.h>
 
 #include <plat/mtu.h>
@@ -34,14 +35,14 @@ static cycle_t nmdk_read_timer_dummy(struct clocksource *cs)
 /* clocksource: MTU decrements, so we negate the value being read. */
 static cycle_t nmdk_read_timer(struct clocksource *cs)
 {
-	return -readl(mtu_base + MTU_VAL(0));
+	return cnt32_to_63(-readl(mtu_base + MTU_VAL(0)));
 }
 
 static struct clocksource nmdk_clksrc = {
 	.name		= "mtu_0",
 	.rating		= 200,
 	.read		= nmdk_read_timer_dummy,
-	.mask		= CLOCKSOURCE_MASK(32),
+	.mask		= CLOCKSOURCE_MASK(63),
 	.flags		= CLOCK_SOURCE_IS_CONTINUOUS,
 };
 
-- 
1.6.3.3

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/