[PATCH 11/14] arm64: dts: Add initial device tree support for EXYNOS7

[Mark Rutland]

On Thu, Aug 28, 2014 at 06:33:13PM +0100, Rob Herring wrote:
> On Thu, Aug 28, 2014 at 12:27 PM, Marc Zyngier <marc.zyngier at arm.com> wrote:
> > On 28/08/14 18:03, Mark Rutland wrote:
> >
> >> From 67104ad5a56e4c18f9c41f06af028b7561740afd Mon Sep 17 00:00:00 2001
> >> From: Mark Rutland <mark.rutland at 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.
> >
> >> 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 at arm.com>
> >> Cc: Marc Zyngier <marc.zyngier at arm.com>
> >
> > 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.