On Fri, Nov 28, 2014 at 02:44:12PM +0000, Will Deacon wrote:

On Fri, Nov 28, 2014 at 02:35:32PM +0000, Mark Rutland wrote:

quoted

On Fri, Nov 28, 2014 at 02:29:13PM +0000, Catalin Marinas wrote:

quoted

On Thu, Nov 27, 2014 at 01:43:09PM +0000, Mark Rutland wrote:

quoted

On Thu, Nov 27, 2014 at 12:12:15PM +0000, Catalin Marinas wrote:

quoted

On Thu, Nov 27, 2014 at 11:50:43AM +0000, Mark Rutland wrote:

quoted

On Tue, Nov 25, 2014 at 12:16:56PM +0000, Chunyan Zhang wrote:

quoted

+
+       timer {
+               compatible = "arm,armv8-timer";
+               interrupts = <1 13 0xff01>,
+                            <1 14 0xff01>,
+                            <1 11 0xff01>,
+                            <1 10 0xff01>;
+               clock-frequency = <26000000>;

Please remove the clock-frequency property. Your FW should initialise
CNTFRQ_EL0 on all CPUs (certainly PSCI 0.2 requires that you do this).

Since this comes up regularly, I think we need a dev_warn() in the arch
timer driver when CONFIG_ARM64.

I'll ack such a patch ;)

How rude would this be?

diff --git a/drivers/clocksource/arm_arch_timer.c b/drivers/clocksource/arm_arch_timer.c
index 2133f9d59d06..aaaf3433ccb9 100644
--- a/drivers/clocksource/arm_arch_timer.c
+++ b/drivers/clocksource/arm_arch_timer.c

@@ -371,7 +371,8 @@ arch_timer_detect_rate(void __iomem *cntbase, struct device_node *np)

		return;
 
	/* Try to determine the frequency from the device tree or CNTFRQ */
-	if (of_property_read_u32(np, "clock-frequency", &arch_timer_rate)) {
+	if (IS_ENABLED(CONFIG_ARM64) ||
+	    of_property_read_u32(np, "clock-frequency", &arch_timer_rate)) {
		if (cntbase)
			arch_timer_rate = readl_relaxed(cntbase + CNTFRQ);
		else

Probably too rude, given it doesn't WARN() the user.

We override broken hardware ID registers all the time in device-tree without
dumping stack. Why is this any different?

I'm not for dumping the stack, it's not relevant (just more noise).

quoted

We should be extremely loud if we see the clock-frequency property on an
arm64 system. Whether or not we should ignore the property is another
matter.

I don't really see the point in ignoring it. We will see broken hardware
[1] and this is just preventing ourselves from working around it. I'd much
rather have arch-timers with a "clock-frequence" property than have some
other timer instead because the kernel driver is being stubborn.

I agree that sooner or later we'll need a workaround (we already did for
Juno). My point is that many consider such overriding behaviour to be
the default - i.e. don't bother writing any sane value in CNTFRQ in
firmware at boot because Linux can cope without. It gets worse when
companies develop their firmware long before starting to upstream kernel
patches, so too late to fix it.

[1] A previous version of the Juno firmware, for example.

What about CONFIG_BROKEN_FIRMWARE, default off?

In the meantime I think we can be more tolerant:

diff --git a/drivers/clocksource/arm_arch_timer.c b/drivers/clocksource/arm_arch_timer.c
index 2133f9d59d06..87f67a93fcc7 100644
--- a/drivers/clocksource/arm_arch_timer.c
+++ b/drivers/clocksource/arm_arch_timer.c

@@ -376,6 +376,8 @@ arch_timer_detect_rate(void __iomem *cntbase, struct device_node *np)
 			arch_timer_rate = readl_relaxed(cntbase + CNTFRQ);
 		else
 			arch_timer_rate = arch_timer_get_cntfrq();
+	} else if (IS_ENABLED(CONFIG_ARM64)) {
+		pr_warn("Architected timer frequency overridden by DT (broken firmware?)\n");
 	}
 
 	/* Check the timer frequency. */