On Thu, Aug 28, 2014 at 06:33:13PM +0100, Rob Herring wrote:

On Thu, Aug 28, 2014 at 12:27 PM, Marc Zyngier [off-list ref] wrote:

quoted

On 28/08/14 18:03, Mark Rutland wrote:

quoted

From 67104ad5a56e4c18f9c41f06af028b7561740afd Mon Sep 17 00:00:00 2001
From: Mark Rutland <mark.rutland@arm.com>
Date: Thu, 28 Aug 2014 17:41:03 +0100
Subject: [PATCH] Doc: dt: arch_timer: discourage clock-frequency use

The ARM Generic Timer (AKA the architected timer, arm_arch_timer)
features a CPU register (CNTFRQ) which firmware is intended to
initialize, and non-secure software can read to determine the frequency
of the timer. On CPUs with secure state, this register cannot be written
from non-secure states.

The firmware of early SoCs featuring the timer did not correctly
initialize CNTFRQ correctly on all CPUs, requiring the frequency to be
described in DT as a workaround. This workaround is not complete however
as CNTFRQ is exposed to all software in a privileged non-secure mode,
including KVM guests. The firmware and DTs for recent SoCs have followed

I believe Xen is also affected by this.

quoted

the example set by these early SoCs.

This patch updates the arch timer binding documentation to make it
clearer that the use of the clock-frequency property is a poor
work-around. The MMIO generic timer binding is similarly updated, though
this is less of a concern as there is generally no need to expose the
MMIO timers to guest OSs.

Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Cc: Marc Zyngier <redacted>

Short of more explicit threats:

Why not also add WARNs (and mark for stable). People tend to notice
and fix those. If not the vendors, those pesky customers always
complain (the same ones that get concerned about BogoMIPS values being
too low).

I had a go a while back but it was a bit painful becuase the MMIO and
cpu timer code is intertwined, and a clock-frequency property on the
MMIO timers isn't all that problematic (though admittedly still a
workaround for FW not initialising something it was intended to).

I was hoping I'd have the chance to split the driver in two first, so as
to sidestep that. I'll take another look.

Mark.