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@xxxxxxx> wrote: > > On 28/08/14 18:03, Mark Rutland wrote: > > > >> From 67104ad5a56e4c18f9c41f06af028b7561740afd Mon Sep 17 00:00:00 2001 > >> From: Mark Rutland <mark.rutland@xxxxxxx> > >> 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@xxxxxxx> > >> Cc: Marc Zyngier <marc.zyngier@xxxxxxx> > > > > 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. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
