[PATCH v5 1/5] arm64: arch_timer: Add device tree binding for A-008585 erratum

[PATCH v5 1/5] arm64: arch_timer: Add device tree binding for A-008585 erratum

[Scott Wood]

This erratum describes a bug in logic outside the core, so MIDR can't be
used to identify its presence, and reading an SoC-specific revision
register from common arch timer code would be awkward.  So, describe it
in the device tree.

Signed-off-by: Scott Wood <oss@buserror.net>
Acked-by: Rob Herring <robh@kernel.org>
---
 Documentation/devicetree/bindings/arm/arch_timer.txt | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/arch_timer.txt b/Documentation/devicetree/bindings/arm/arch_timer.txt
index e774128..ef5fbe9 100644
--- a/Documentation/devicetree/bindings/arm/arch_timer.txt
+++ b/Documentation/devicetree/bindings/arm/arch_timer.txt
@@ -25,6 +25,12 @@ to deliver its interrupts via SPIs.
 - always-on : a boolean property. If present, the timer is powered through an
   always-on power domain, therefore it never loses context.
 
+- fsl,erratum-a008585 : A boolean property. Indicates the presence of
+  QorIQ erratum A-008585, which says that reading the counter is
+  unreliable unless the same value is returned by back-to-back reads.
+  This also affects writes to the tval register, due to the implicit
+  counter read.
+
 ** Optional properties:
 
 - arm,cpu-registers-not-fw-configured : Firmware does not initialize
-- 
2.7.4

[PATCH v5 2/5] arm64: dts: Add timer erratum property for LS2080A and LS1043A

[Scott Wood]

Signed-off-by: Scott Wood <oss@buserror.net>
---
 arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi | 1 +
 arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi | 1 +
 2 files changed, 2 insertions(+)

diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi b/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi
index e669fbd..952531d 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi
@@ -123,6 +123,7 @@
 			     <1 14 0x1>, /* Physical Non-Secure PPI */
 			     <1 11 0x1>, /* Virtual PPI */
 			     <1 10 0x1>; /* Hypervisor PPI */
+		fsl,erratum-a008585;
 	};
 
 	pmu {
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi b/arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi
index 21023a3..9d3ac19 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi
@@ -195,6 +195,7 @@
 			     <1 14 0x8>, /* Physical Non-Secure PPI, active-low */
 			     <1 11 0x8>, /* Virtual PPI, active-low */
 			     <1 10 0x8>; /* Hypervisor PPI, active-low */
+		fsl,erratum-a008585;
 	};
 
 	pmu {
-- 
2.7.4

[PATCH v5 3/5] arm64: arch_timer: Work around QorIQ Erratum A-008585

[Scott Wood]

Erratum A-008585 says that the ARM generic timer counter "has the
potential to contain an erroneous value for a small number of core
clock cycles every time the timer value changes".  Accesses to TVAL
(both read and write) are also affected due to the implicit counter
read.  Accesses to CVAL are not affected.

The workaround is to reread TVAL and count registers until successive reads
return the same value, and when writing TVAL to retry until counter
reads before and after the write return the same value.

This erratum can be found on LS1043A and LS2080A.

Signed-off-by: Scott Wood <oss@buserror.net>
---
v5:
- Export arch_timer_read_ool_enabled so that get_cycles() can be called
  from modules.

v4:
- Undef ARCH_TIMER_REG_READ after use

v3:
- Used cval rather than a loop for the write side of the erratum
- Added a Kconfig control
- Moved the device tree binding into its own patch
- Added erratum to silicon-errata.txt
- Changed function names to contain the erratum name
- Factored out the setting of erratum versions of set_next_event
  to improve readability
- Added a comment clarifying that the timeout is arbitrary

v2:
Significant rework based on feedback, including using static_key,
disabling VDSO counter access rather than adding the workaround to the
VDSO, and uninlining the loops.

Dropped the separate property for indicating that writes to TVAL are
affected, as I believe that's just a side effect of the implicit
counter read being corrupted, and thus a chip that is affected by one
will always be affected by the other.

Dropped the arm32 portion as it seems there was confusion about whether
LS1021A is affected.  Currently I am being told that it is not
affected.

I considered writing to CVAL rather than looping on TVAL writes, but
that would still have required separate set_next_event() code for the
erratum, and adding CVAL to the enum would have required a bunch of
extra handlers in switch statements (even where unused, due to compiler
warnings about unhandled enum values) including in an arm32 header.  It
seemed better to avoid the arm32 interaction and new untested
accessors.
---
 Documentation/arm64/silicon-errata.txt |   2 +
 arch/arm64/include/asm/arch_timer.h    |  50 +++++++++++++---
 drivers/clocksource/Kconfig            |  10 ++++
 drivers/clocksource/arm_arch_timer.c   | 104 +++++++++++++++++++++++++++++++++
 4 files changed, 157 insertions(+), 9 deletions(-)

diff --git a/Documentation/arm64/silicon-errata.txt b/Documentation/arm64/silicon-errata.txt
index ccc6032..405da11 100644
--- a/Documentation/arm64/silicon-errata.txt
+++ b/Documentation/arm64/silicon-errata.txt
@@ -61,3 +61,5 @@ stable kernels.
 | Cavium         | ThunderX GICv3  | #23154          | CAVIUM_ERRATUM_23154    |
 | Cavium         | ThunderX Core   | #27456          | CAVIUM_ERRATUM_27456    |
 | Cavium         | ThunderX SMMUv2 | #27704          | N/A		       |
+|                |                 |                 |                         |
+| Freescale/NXP  | LS2080A/LS1043A | A-008585        | FSL_ERRATUM_A008585     |
diff --git a/arch/arm64/include/asm/arch_timer.h b/arch/arm64/include/asm/arch_timer.h
index fbe0ca3..927dc6f 100644
--- a/arch/arm64/include/asm/arch_timer.h
+++ b/arch/arm64/include/asm/arch_timer.h
@@ -23,10 +23,36 @@
 
 #include <linux/bug.h>
 #include <linux/init.h>
+#include <linux/jump_label.h>
 #include <linux/types.h>
 
 #include <clocksource/arm_arch_timer.h>
 
+extern struct static_key_false arch_timer_read_ool_enabled;
+
+#define ARCH_TIMER_REG_READ(reg, func) \
+extern u64 func##_ool(void); \
+static inline u64 __##func(void) \
+{ \
+	u64 val; \
+	asm volatile("mrs %0, " reg : "=r" (val)); \
+	return val; \
+} \
+static inline u64 _##func(void) \
+{ \
+	if (IS_ENABLED(CONFIG_FSL_ERRATUM_A008585) && \
+	    static_branch_unlikely(&arch_timer_read_ool_enabled)) \
+		return func##_ool(); \
+	else \
+		return __##func(); \
+}
+
+ARCH_TIMER_REG_READ("cntp_tval_el0", arch_timer_get_ptval)
+ARCH_TIMER_REG_READ("cntv_tval_el0", arch_timer_get_vtval)
+ARCH_TIMER_REG_READ("cntvct_el0", arch_counter_get_cntvct)
+
+#undef ARCH_TIMER_REG_READ
+
 /*
  * These register accessors are marked inline so the compiler can
  * nicely work out which register we want, and chuck away the rest of
@@ -58,6 +84,16 @@ void arch_timer_reg_write_cp15(int access, enum arch_timer_reg reg, u32 val)
 	isb();
 }
 
+static __always_inline void arch_timer_cval_write_cp15(int access, u64 val)
+{
+	if (access == ARCH_TIMER_PHYS_ACCESS)
+		asm volatile("msr cntp_cval_el0, %0" : : "r" (val));
+	else if (access == ARCH_TIMER_VIRT_ACCESS)
+		asm volatile("msr cntv_cval_el0, %0" : : "r" (val));
+
+	isb();
+}
+
 static __always_inline
 u32 arch_timer_reg_read_cp15(int access, enum arch_timer_reg reg)
 {
@@ -66,19 +102,19 @@ u32 arch_timer_reg_read_cp15(int access, enum arch_timer_reg reg)
 	if (access == ARCH_TIMER_PHYS_ACCESS) {
 		switch (reg) {
 		case ARCH_TIMER_REG_CTRL:
-			asm volatile("mrs %0,  cntp_ctl_el0" : "=r" (val));
+			asm volatile("mrs %0, cntp_ctl_el0" : "=r" (val));
 			break;
 		case ARCH_TIMER_REG_TVAL:
-			asm volatile("mrs %0, cntp_tval_el0" : "=r" (val));
+			val = _arch_timer_get_ptval();
 			break;
 		}
 	} else if (access == ARCH_TIMER_VIRT_ACCESS) {
 		switch (reg) {
 		case ARCH_TIMER_REG_CTRL:
-			asm volatile("mrs %0,  cntv_ctl_el0" : "=r" (val));
+			asm volatile("mrs %0, cntv_ctl_el0" : "=r" (val));
 			break;
 		case ARCH_TIMER_REG_TVAL:
-			asm volatile("mrs %0, cntv_tval_el0" : "=r" (val));
+			val = _arch_timer_get_vtval();
 			break;
 		}
 	}
@@ -116,12 +152,8 @@ static inline u64 arch_counter_get_cntpct(void)
 
 static inline u64 arch_counter_get_cntvct(void)
 {
-	u64 cval;
-
 	isb();
-	asm volatile("mrs %0, cntvct_el0" : "=r" (cval));
-
-	return cval;
+	return _arch_counter_get_cntvct();
 }
 
 static inline int arch_timer_arch_init(void)
diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
index 5677886..8a753fd 100644
--- a/drivers/clocksource/Kconfig
+++ b/drivers/clocksource/Kconfig
@@ -305,6 +305,16 @@ config ARM_ARCH_TIMER_EVTSTREAM
 	  This must be disabled for hardware validation purposes to detect any
 	  hardware anomalies of missing events.
 
+config FSL_ERRATUM_A008585
+	bool "Workaround for Freescale/NXP Erratum A-008585"
+	default y
+	depends on ARM_ARCH_TIMER && ARM64
+	help
+	  This option enables a workaround for Freescale/NXP Erratum
+	  A-008585 ("ARM generic timer may contain an erroneous
+	  value").  The workaround will only be active if the
+	  fsl,erratum-a008585 property is found in the timer node.
+
 config ARM_GLOBAL_TIMER
 	bool "Support for the ARM global timer" if COMPILE_TEST
 	select CLKSRC_OF if OF
diff --git a/drivers/clocksource/arm_arch_timer.c b/drivers/clocksource/arm_arch_timer.c
index 5770054..2526543 100644
--- a/drivers/clocksource/arm_arch_timer.c
+++ b/drivers/clocksource/arm_arch_timer.c
@@ -94,6 +94,52 @@ early_param("clocksource.arm_arch_timer.evtstrm", early_evtstrm_cfg);
  * Architected system timer support.
  */
 
+#ifdef CONFIG_FSL_ERRATUM_A008585
+DEFINE_STATIC_KEY_FALSE(arch_timer_read_ool_enabled);
+EXPORT_SYMBOL_GPL(arch_timer_read_ool_enabled);
+
+/*
+ * __always_inline is used to ensure that func() is not an actual function
+ * pointer, which would result in the register accesses potentially being too
+ * far apart for the loop to work.
+ *
+ * The timeout is an arbitrary value well beyond the highest number
+ * of iterations the loop has been observed to take.
+ */
+static __always_inline u64 fsl_a008585_reread_counter(u64 (*func)(void))
+{
+	u64 cval_old, cval_new;
+	int timeout = 200;
+
+	do {
+		isb();
+		cval_old = func();
+		cval_new = func();
+		timeout--;
+	} while (unlikely(cval_old != cval_new) && timeout);
+
+	WARN_ON_ONCE(!timeout);
+	return cval_new;
+}
+
+u64 arch_counter_get_cntvct_ool(void)
+{
+	return fsl_a008585_reread_counter(__arch_counter_get_cntvct);
+}
+EXPORT_SYMBOL(arch_counter_get_cntvct_ool);
+
+u64 arch_timer_get_vtval_ool(void)
+{
+	return fsl_a008585_reread_counter(__arch_timer_get_vtval);
+}
+
+u64 arch_timer_get_ptval_ool(void)
+{
+	return fsl_a008585_reread_counter(__arch_timer_get_ptval);
+}
+
+#endif /* CONFIG_FSL_ERRATUM_A008585 */
+
 static __always_inline
 void arch_timer_reg_write(int access, enum arch_timer_reg reg, u32 val,
 			  struct clock_event_device *clk)
@@ -243,6 +289,35 @@ static __always_inline void set_next_event(const int access, unsigned long evt,
 	arch_timer_reg_write(access, ARCH_TIMER_REG_CTRL, ctrl, clk);
 }
 
+#ifdef CONFIG_FSL_ERRATUM_A008585
+static __always_inline void fsl_a008585_set_next_event(const int access,
+		unsigned long evt, struct clock_event_device *clk)
+{
+	unsigned long ctrl;
+	u64 cval = evt + arch_counter_get_cntvct();
+
+	ctrl = arch_timer_reg_read(access, ARCH_TIMER_REG_CTRL, clk);
+	ctrl |= ARCH_TIMER_CTRL_ENABLE;
+	ctrl &= ~ARCH_TIMER_CTRL_IT_MASK;
+	arch_timer_cval_write_cp15(access, cval);
+	arch_timer_reg_write(access, ARCH_TIMER_REG_CTRL, ctrl, clk);
+}
+
+static int fsl_a008585_set_next_event_virt(unsigned long evt,
+					   struct clock_event_device *clk)
+{
+	fsl_a008585_set_next_event(ARCH_TIMER_VIRT_ACCESS, evt, clk);
+	return 0;
+}
+
+static int fsl_a008585_set_next_event_phys(unsigned long evt,
+					   struct clock_event_device *clk)
+{
+	fsl_a008585_set_next_event(ARCH_TIMER_PHYS_ACCESS, evt, clk);
+	return 0;
+}
+#endif /* CONFIG_FSL_ERRATUM_A008585 */
+
 static int arch_timer_set_next_event_virt(unsigned long evt,
 					  struct clock_event_device *clk)
 {
@@ -271,6 +346,19 @@ static int arch_timer_set_next_event_phys_mem(unsigned long evt,
 	return 0;
 }
 
+static void fsl_a008585_set_sne(struct clock_event_device *clk)
+{
+#ifdef CONFIG_FSL_ERRATUM_A008585
+	if (!static_branch_unlikely(&arch_timer_read_ool_enabled))
+		return;
+
+	if (arch_timer_uses_ppi == VIRT_PPI)
+		clk->set_next_event = fsl_a008585_set_next_event_virt;
+	else
+		clk->set_next_event = fsl_a008585_set_next_event_phys;
+#endif
+}
+
 static void __arch_timer_setup(unsigned type,
 			       struct clock_event_device *clk)
 {
@@ -299,6 +387,8 @@ static void __arch_timer_setup(unsigned type,
 		default:
 			BUG();
 		}
+
+		fsl_a008585_set_sne(clk);
 	} else {
 		clk->features |= CLOCK_EVT_FEAT_DYNIRQ;
 		clk->name = "arch_mem_timer";
@@ -515,6 +605,15 @@ static void __init arch_counter_register(unsigned type)
 			arch_timer_read_counter = arch_counter_get_cntvct;
 		else
 			arch_timer_read_counter = arch_counter_get_cntpct;
+
+#ifdef CONFIG_FSL_ERRATUM_A008585
+		/*
+		 * Don't use the vdso fastpath if errata require using
+		 * the out-of-line counter accessor.
+		 */
+		if (static_branch_unlikely(&arch_timer_read_ool_enabled))
+			clocksource_counter.name = "arch_sys_counter_ool";
+#endif
 	} else {
 		arch_timer_read_counter = arch_counter_get_cntvct_mem;
 
@@ -800,6 +899,11 @@ static int __init arch_timer_of_init(struct device_node *np)
 
 	arch_timer_c3stop = !of_property_read_bool(np, "always-on");
 
+#ifdef CONFIG_FSL_ERRATUM_A008585
+	if (of_property_read_bool(np, "fsl,erratum-a008585"))
+		static_branch_enable(&arch_timer_read_ool_enabled);
+#endif
+
 	/*
 	 * If we cannot rely on firmware initializing the timer registers then
 	 * we should use the physical timers instead.
-- 
2.7.4

[PATCH v5 3/5] arm64: arch_timer: Work around QorIQ Erratum A-008585

[Mark Rutland]

Hi,

The changes in arm64's <asm/arch_timer.h> are going to conflict with
some cleanup [1,2] that just landed in the arm64 for-next/core branch.

Could you please rebase atop of that?

On Fri, Sep 09, 2016 at 08:03:31PM -0500, Scott Wood wrote:
> Erratum A-008585 says that the ARM generic timer counter "has the
> potential to contain an erroneous value for a small number of core
> clock cycles every time the timer value changes".  Accesses to TVAL
> (both read and write) are also affected due to the implicit counter
> read.  Accesses to CVAL are not affected.
> 
> The workaround is to reread TVAL and count registers until successive reads
> return the same value, and when writing TVAL to retry until counter
> reads before and after the write return the same value.

This doesn't match the code, which doesn't seem to write TVAL at all,
and instead does the work manually, reading CNTVCT then writing to CVAL.
Please update the patch description.

[...]

> +extern struct static_key_false arch_timer_read_ool_enabled;
> +
> +#define ARCH_TIMER_REG_READ(reg, func) \
> +extern u64 func##_ool(void); \
> +static inline u64 __##func(void) \
> +{ \
> +	u64 val; \
> +	asm volatile("mrs %0, " reg : "=r" (val)); \
> +	return val; \
> +} \

Following recent cleanup, please use read_sysreg().

> +static inline u64 _##func(void) \
> +{ \
> +	if (IS_ENABLED(CONFIG_FSL_ERRATUM_A008585) && \
> +	    static_branch_unlikely(&arch_timer_read_ool_enabled)) \
> +		return func##_ool(); \
> +	else \
> +		return __##func(); \
> +}
> +
> +ARCH_TIMER_REG_READ("cntp_tval_el0", arch_timer_get_ptval)
> +ARCH_TIMER_REG_READ("cntv_tval_el0", arch_timer_get_vtval)
> +ARCH_TIMER_REG_READ("cntvct_el0", arch_counter_get_cntvct)
> +
> +#undef ARCH_TIMER_REG_READ

Rather than defining a number of inline functions here as wrappers for
read_sysreg(), can we pass the reg name down instead? e.g.

#if IS_ENABLED(CONFIG_FSL_ERRATUM_A008585)
extern struct static_key_false arch_timer_read_ool_enabled;
#define needs_fsl_a008585_workaround() \
	static_branch_unlikely(&arch_timer_read_ool_enabled)
#else
#define needs_fsl_a008585_workaround()	false
#endif

#define arch_timer_unstable_reg_read(reg)		\
({							\
	if (needs_fsl_a008585_workaround())		\
		return __fsl_a008585_read_##reg();	\
	else						\
		return read_sysreg(reg);		\
})

... with __fsl_a008585_read_{cntp_tval_el0,cntv_tval_el0,cntvct_el0}
defined appropriately in the driver code.

[...]

> +static __always_inline void arch_timer_cval_write_cp15(int access, u64 val)
> +{
> +	if (access == ARCH_TIMER_PHYS_ACCESS)
> +		asm volatile("msr cntp_cval_el0, %0" : : "r" (val));
> +	else if (access == ARCH_TIMER_VIRT_ACCESS)
> +		asm volatile("msr cntv_cval_el0, %0" : : "r" (val));
> +
> +	isb();
> +}

Please add ARCH_TIMER_REG_CVAL to enum arch_timer_reg, and move these
accesses into arch_timer_reg_write_cp15().

[...]

> +#ifdef CONFIG_FSL_ERRATUM_A008585
> +DEFINE_STATIC_KEY_FALSE(arch_timer_read_ool_enabled);
> +EXPORT_SYMBOL_GPL(arch_timer_read_ool_enabled);
> +
> +/*
> + * __always_inline is used to ensure that func() is not an actual function
> + * pointer, which would result in the register accesses potentially being too
> + * far apart for the loop to work.
> + *
> + * The timeout is an arbitrary value well beyond the highest number
> + * of iterations the loop has been observed to take.
> + */
> +static __always_inline u64 fsl_a008585_reread_counter(u64 (*func)(void))

Please:

* Rename this to __fsl_a008585_read_reg, as it's used for registers
  other than the counters.

* Make this a macro, to which the register name is passed in, such that
  it can use read_sysreg(), as with my suggestion above regarding how to
  restructure the function.

* Move this into the ifdef'd block in the arm64 header, leaving the
  callers where they are in the driver code.

> +{
> +	u64 cval_old, cval_new;

Nit: use 'old' and 'new', so as to not imply that this applies (only) to
CNT{V,P}_CVAL. 

> +	int timeout = 200;

Nit: s/timeout/retries/

> +
> +	do {
> +		isb();

What's the ISB for?

The core should order accesses to the same counter, and any ISB required
for ordering against other counters should already be present. So I
don't follow what this is trying to achieve.

If this is necessary, please add a comment explaining what it is
intended to ensure.

> +		cval_old = func();
> +		cval_new = func();
> +		timeout--;
> +	} while (unlikely(cval_old != cval_new) && timeout);
> +
> +	WARN_ON_ONCE(!timeout);
> +	return cval_new;
> +}
> +
> +u64 arch_counter_get_cntvct_ool(void)
> +{
> +	return fsl_a008585_reread_counter(__arch_counter_get_cntvct);
> +}
> +EXPORT_SYMBOL(arch_counter_get_cntvct_ool);
> +
> +u64 arch_timer_get_vtval_ool(void)
> +{
> +	return fsl_a008585_reread_counter(__arch_timer_get_vtval);
> +}
> +
> +u64 arch_timer_get_ptval_ool(void)
> +{
> +	return fsl_a008585_reread_counter(__arch_timer_get_ptval);
> +}

With the above suggestion, these will need to be renamed to something
like:

	__fsl_a008585_read_{cntvct_el0,cntv_tval_el0,cntp_tval_el0}

[...]

> +#ifdef CONFIG_FSL_ERRATUM_A008585
> +static __always_inline void fsl_a008585_set_next_event(const int access,
> +		unsigned long evt, struct clock_event_device *clk)
> +{
> +	unsigned long ctrl;
> +	u64 cval = evt + arch_counter_get_cntvct();
> +
> +	ctrl = arch_timer_reg_read(access, ARCH_TIMER_REG_CTRL, clk);
> +	ctrl |= ARCH_TIMER_CTRL_ENABLE;
> +	ctrl &= ~ARCH_TIMER_CTRL_IT_MASK;
> +	arch_timer_cval_write_cp15(access, cval);
> +	arch_timer_reg_write(access, ARCH_TIMER_REG_CTRL, ctrl, clk);
> +}
> +
> +static int fsl_a008585_set_next_event_virt(unsigned long evt,
> +					   struct clock_event_device *clk)
> +{
> +	fsl_a008585_set_next_event(ARCH_TIMER_VIRT_ACCESS, evt, clk);
> +	return 0;
> +}
> +
> +static int fsl_a008585_set_next_event_phys(unsigned long evt,
> +					   struct clock_event_device *clk)
> +{
> +	fsl_a008585_set_next_event(ARCH_TIMER_PHYS_ACCESS, evt, clk);
> +	return 0;
> +}
> +#endif /* CONFIG_FSL_ERRATUM_A008585 */
> +
>  static int arch_timer_set_next_event_virt(unsigned long evt,
>  					  struct clock_event_device *clk)
>  {
> @@ -271,6 +346,19 @@ static int arch_timer_set_next_event_phys_mem(unsigned long evt,
>  	return 0;
>  }
>  
> +static void fsl_a008585_set_sne(struct clock_event_device *clk)
> +{
> +#ifdef CONFIG_FSL_ERRATUM_A008585
> +	if (!static_branch_unlikely(&arch_timer_read_ool_enabled))
> +		return;
> +
> +	if (arch_timer_uses_ppi == VIRT_PPI)
> +		clk->set_next_event = fsl_a008585_set_next_event_virt;
> +	else
> +		clk->set_next_event = fsl_a008585_set_next_event_phys;
> +#endif
> +}
> +

I'm not keen on the magic hook to reset the function pointers, and the
additional phys/virt stubs seem pointless. Instead, can we fold this
into the existing set_next_event? e.g. have that do:

	if (needs_fsl_a008585_workaround() {
		fsl_a008585_set_next_event(access, evt, clk);
		return;
	}

... with a stub BUILD_BUG() fsl_a008585_set_next_event() when
!CONFIG_FSL_ERRATUM_A008585, and:

#ifndef needs_fsl_a008585_workaround
#define needs_fsl_a008585_workaround()	false
#endif

... in the driver, so as to not cause issues for 32-bit.

[...]

> +#ifdef CONFIG_FSL_ERRATUM_A008585
> +		/*
> +		 * Don't use the vdso fastpath if errata require using
> +		 * the out-of-line counter accessor.
> +		 */
> +		if (static_branch_unlikely(&arch_timer_read_ool_enabled))
> +			clocksource_counter.name = "arch_sys_counter_ool";

Can we move the next patch before this, and avoid messing with the name
entirely?

[...]

> @@ -800,6 +899,11 @@ static int __init arch_timer_of_init(struct device_node *np)
>  
>  	arch_timer_c3stop = !of_property_read_bool(np, "always-on");
>  
> +#ifdef CONFIG_FSL_ERRATUM_A008585
> +	if (of_property_read_bool(np, "fsl,erratum-a008585"))
> +		static_branch_enable(&arch_timer_read_ool_enabled);
> +#endif

Please log something, e.g.

	pr_info("Enabling workaround for FSL erratum A008585\n");

Thanks,
Mark.

[1] https://git.kernel.org/cgit/linux/kernel/git/mark/linux.git/commit/?h=arm64/read-write-sysreg&id=ad2d624a50b900a3148d74ed8597508bc472c12e
[2] https://git.kernel.org/cgit/linux/kernel/git/mark/linux.git/log/?h=arm64/read-write-sysreg
[3] https://git.kernel.org/cgit/linux/kernel/git/arm64/linux.git/log/?h=for-next/core

[PATCH v5 3/5] arm64: arch_timer: Work around QorIQ Erratum A-008585

[Will Deacon]

On Mon, Sep 12, 2016 at 12:36:15PM +0100, Mark Rutland wrote:
> The changes in arm64's <asm/arch_timer.h> are going to conflict with
> some cleanup [1,2] that just landed in the arm64 for-next/core branch.
> 
> Could you please rebase atop of that?

Well, we should figure out what tree this is going through first. There
are a mixture of arm, arm64, driver and dts changes here and not all
of it is carrying the appropriate acks for me to queue it.

Will

[PATCH v5 3/5] arm64: arch_timer: Work around QorIQ Erratum A-008585

[Mark Rutland]

On Mon, Sep 12, 2016 at 12:44:07PM +0100, Will Deacon wrote:
> On Mon, Sep 12, 2016 at 12:36:15PM +0100, Mark Rutland wrote:
> > The changes in arm64's <asm/arch_timer.h> are going to conflict with
> > some cleanup [1,2] that just landed in the arm64 for-next/core branch.
> > 
> > Could you please rebase atop of that?
> 
> Well, we should figure out what tree this is going through first. There
> are a mixture of arm, arm64, driver and dts changes here and not all
> of it is carrying the appropriate acks for me to queue it.

Given that mix, I had assumed that this would all go through the arm64
tree -- I see that Rob has already acked the binding, and I'm happy to
give my ack for the driver once that's in shape.

The dts change could go through arm-soc in parallel, I guess. It doesn't
look like arm-soc have been Cc'd for that, though.

Thanks,
Mark.

[PATCH v5 3/5] arm64: arch_timer: Work around QorIQ Erratum A-008585

[Mark Rutland]

On Mon, Sep 12, 2016 at 01:30:28PM +0100, Mark Rutland wrote:
> On Mon, Sep 12, 2016 at 12:44:07PM +0100, Will Deacon wrote:
> > On Mon, Sep 12, 2016 at 12:36:15PM +0100, Mark Rutland wrote:
> > > The changes in arm64's <asm/arch_timer.h> are going to conflict with
> > > some cleanup [1,2] that just landed in the arm64 for-next/core branch.
> > > 
> > > Could you please rebase atop of that?
> > 
> > Well, we should figure out what tree this is going through first. There
> > are a mixture of arm, arm64, driver and dts changes here and not all
> > of it is carrying the appropriate acks for me to queue it.
> 
> Given that mix, I had assumed that this would all go through the arm64
> tree -- I see that Rob has already acked the binding, and I'm happy to
> give my ack for the driver once that's in shape.

Now I see that I'd missed the arch/arm changes in patch 4, which lack a
relevant ack.

Given that, I don't know what to suggest.

Thanks,
Mark.

[PATCH v5 3/5] arm64: arch_timer: Work around QorIQ Erratum A-008585

[Marc Zyngier]

On 12/09/16 13:59, Mark Rutland wrote:
> On Mon, Sep 12, 2016 at 01:30:28PM +0100, Mark Rutland wrote:
>> On Mon, Sep 12, 2016 at 12:44:07PM +0100, Will Deacon wrote:
>>> On Mon, Sep 12, 2016 at 12:36:15PM +0100, Mark Rutland wrote:
>>>> The changes in arm64's <asm/arch_timer.h> are going to conflict with
>>>> some cleanup [1,2] that just landed in the arm64 for-next/core branch.
>>>>
>>>> Could you please rebase atop of that?
>>>
>>> Well, we should figure out what tree this is going through first. There
>>> are a mixture of arm, arm64, driver and dts changes here and not all
>>> of it is carrying the appropriate acks for me to queue it.
>>
>> Given that mix, I had assumed that this would all go through the arm64
>> tree -- I see that Rob has already acked the binding, and I'm happy to
>> give my ack for the driver once that's in shape.
> 
> Now I see that I'd missed the arch/arm changes in patch 4, which lack a
> relevant ack.
> 
> Given that, I don't know what to suggest.

I wouldn't mind delaying patch 4 until it gets acked by RMK, as it
doesn't impact the functionality.

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny...

[PATCH v5 3/5] arm64: arch_timer: Work around QorIQ Erratum A-008585

[Scott Wood]

On Mon, 2016-09-12 at 14:07 +0100, Marc Zyngier wrote:
> On 12/09/16 13:59, Mark Rutland wrote:
> > 
> > On Mon, Sep 12, 2016 at 01:30:28PM +0100, Mark Rutland wrote:
> > > 
> > > On Mon, Sep 12, 2016 at 12:44:07PM +0100, Will Deacon wrote:
> > > > 
> > > > On Mon, Sep 12, 2016 at 12:36:15PM +0100, Mark Rutland wrote:
> > > > > 
> > > > > The changes in arm64's <asm/arch_timer.h> are going to conflict with
> > > > > some cleanup [1,2] that just landed in the arm64 for-next/core
> > > > > branch.
> > > > > 
> > > > > Could you please rebase atop of that?
> > > > Well, we should figure out what tree this is going through first.
> > > > There
> > > > are a mixture of arm, arm64, driver and dts changes here and not all
> > > > of it is carrying the appropriate acks for me to queue it.
> > > Given that mix, I had assumed that this would all go through the arm64
> > > tree -- I see that Rob has already acked the binding, and I'm happy to
> > > give my ack for the driver once that's in shape.
> > Now I see that I'd missed the arch/arm changes in patch 4, which lack a
> > relevant ack.
> > 
> > Given that, I don't know what to suggest.
> I wouldn't mind delaying patch 4 until it gets acked by RMK, as it
> doesn't impact the functionality.

Mark asked me to move that patch before the workaround patch, to avoid ever
having to add more code that messes with the name. ?Should I keep the order as
is then?

-Scott

[PATCH v5 3/5] arm64: arch_timer: Work around QorIQ Erratum A-008585

[Mark Rutland]

On Sun, Sep 18, 2016 at 11:31:45PM -0500, Scott Wood wrote:
> On Mon, 2016-09-12 at 14:07 +0100, Marc Zyngier wrote:
> > On 12/09/16 13:59, Mark Rutland wrote:
> > > 
> > > On Mon, Sep 12, 2016 at 01:30:28PM +0100, Mark Rutland wrote:
> > > > 
> > > > On Mon, Sep 12, 2016 at 12:44:07PM +0100, Will Deacon wrote:
> > > > > 
> > > > > On Mon, Sep 12, 2016 at 12:36:15PM +0100, Mark Rutland wrote:
> > > > > > 
> > > > > > The changes in arm64's <asm/arch_timer.h> are going to conflict with
> > > > > > some cleanup [1,2] that just landed in the arm64 for-next/core
> > > > > > branch.
> > > > > > 
> > > > > > Could you please rebase atop of that?
> > > > > Well, we should figure out what tree this is going through first.
> > > > > There
> > > > > are a mixture of arm, arm64, driver and dts changes here and not all
> > > > > of it is carrying the appropriate acks for me to queue it.
> > > > Given that mix, I had assumed that this would all go through the arm64
> > > > tree -- I see that Rob has already acked the binding, and I'm happy to
> > > > give my ack for the driver once that's in shape.
> > > Now I see that I'd missed the arch/arm changes in patch 4, which lack a
> > > relevant ack.
> > > 
> > > Given that, I don't know what to suggest.
> > I wouldn't mind delaying patch 4 until it gets acked by RMK, as it
> > doesn't impact the functionality.
> 
> Mark asked me to move that patch before the workaround patch, to avoid ever
> having to add more code that messes with the name. ?Should I keep the order as
> is then?

Yes; at this stage I think we have to.

Thanks,
Mark.

[PATCH v5 3/5] arm64: arch_timer: Work around QorIQ Erratum A-008585

[Scott Wood]

On Mon, 2016-09-12 at 13:30 +0100, Mark Rutland wrote:
> On Mon, Sep 12, 2016 at 12:44:07PM +0100, Will Deacon wrote:
> > 
> > On Mon, Sep 12, 2016 at 12:36:15PM +0100, Mark Rutland wrote:
> > > 
> > > The changes in arm64's <asm/arch_timer.h> are going to conflict with
> > > some cleanup [1,2] that just landed in the arm64 for-next/core branch.
> > > 
> > > Could you please rebase atop of that?
> > Well, we should figure out what tree this is going through first. There
> > are a mixture of arm, arm64, driver and dts changes here and not all
> > of it is carrying the appropriate acks for me to queue it.
> Given that mix, I had assumed that this would all go through the arm64
> tree -- I see that Rob has already acked the binding, and I'm happy to
> give my ack for the driver once that's in shape.
> 
> The dts change could go through arm-soc in parallel, I guess. It doesn't
> look like arm-soc have been Cc'd for that, though.

The arm-soc section of MAINTAINERS says to e-mail linux-arm-kernel, which I
did. ?There doesn't appear to be a separate arm-soc mailing list, nor is there
a request to CC Olof/Arnd. ?I did CC Shawn Guo who has been handling the
device tree patches for these chips.

-Scott

[PATCH v5 3/5] arm64: arch_timer: Work around QorIQ Erratum A-008585

[Arnd Bergmann]

On Sunday, September 18, 2016 11:28:44 PM CEST Scott Wood wrote:
> On Mon, 2016-09-12 at 13:30 +0100, Mark Rutland wrote:
> > On Mon, Sep 12, 2016 at 12:44:07PM +0100, Will Deacon wrote:
> > > 
> > > On Mon, Sep 12, 2016 at 12:36:15PM +0100, Mark Rutland wrote:
> > > > 
> > > > The changes in arm64's <asm/arch_timer.h> are going to conflict with
> > > > some cleanup [1,2] that just landed in the arm64 for-next/core branch.
> > > > 
> > > > Could you please rebase atop of that?
> > > Well, we should figure out what tree this is going through first. There
> > > are a mixture of arm, arm64, driver and dts changes here and not all
> > > of it is carrying the appropriate acks for me to queue it.
> > Given that mix, I had assumed that this would all go through the arm64
> > tree -- I see that Rob has already acked the binding, and I'm happy to
> > give my ack for the driver once that's in shape.
> > 
> > The dts change could go through arm-soc in parallel, I guess. It doesn't
> > look like arm-soc have been Cc'd for that, though.
> 
> The arm-soc section of MAINTAINERS says to e-mail linux-arm-kernel, which I
> did.  There doesn't appear to be a separate arm-soc mailing list, nor is there
> a request to CC Olof/Arnd.  I did CC Shawn Guo who has been handling the
> device tree patches for these chips.

That is the right way to do it. If the DT change is a bugfix that should
get merged along with the rest, Shawn can also provide an Ack to have it
merged through the arm64 tree, ideally warning us if there might be any
conflicts with stuff that gets sent for arm-soc.

	Arnd

[PATCH v5 3/5] arm64: arch_timer: Work around QorIQ Erratum A-008585

[Shawn Guo]

On Sun, Sep 18, 2016 at 11:28:44PM -0500, Scott Wood wrote:
> On Mon, 2016-09-12 at 13:30 +0100, Mark Rutland wrote:
> > On Mon, Sep 12, 2016 at 12:44:07PM +0100, Will Deacon wrote:
> > > 
> > > On Mon, Sep 12, 2016 at 12:36:15PM +0100, Mark Rutland wrote:
> > > > 
> > > > The changes in arm64's <asm/arch_timer.h> are going to conflict with
> > > > some cleanup [1,2] that just landed in the arm64 for-next/core branch.
> > > > 
> > > > Could you please rebase atop of that?
> > > Well, we should figure out what tree this is going through first. There
> > > are a mixture of arm, arm64, driver and dts changes here and not all
> > > of it is carrying the appropriate acks for me to queue it.
> > Given that mix, I had assumed that this would all go through the arm64
> > tree -- I see that Rob has already acked the binding, and I'm happy to
> > give my ack for the driver once that's in shape.
> > 
> > The dts change could go through arm-soc in parallel, I guess. It doesn't
> > look like arm-soc have been Cc'd for that, though.
> 
> The arm-soc section of MAINTAINERS says to e-mail linux-arm-kernel, which I
> did. ?There doesn't appear to be a separate arm-soc mailing list, nor is there
> a request to CC Olof/Arnd. ?I did CC Shawn Guo who has been handling the
> device tree patches for these chips.

This is kind of new feature development, and there is no hard dependency
between driver and DTS changes.  In this case, we normally pick up the
DTS patch only after driver part get accepted.

Shawn

[PATCH v5 3/5] arm64: arch_timer: Work around QorIQ Erratum A-008585

[Scott Wood]

On Mon, 2016-09-12 at 12:36 +0100, Mark Rutland wrote:

> On Fri, Sep 09, 2016 at 08:03:31PM -0500, Scott Wood wrote:
> > +static __always_inline void arch_timer_cval_write_cp15(int access, u64
> > val)
> > +{
> > +	if (access == ARCH_TIMER_PHYS_ACCESS)
> > +		asm volatile("msr cntp_cval_el0, %0" : : "r" (val));
> > +	else if (access == ARCH_TIMER_VIRT_ACCESS)
> > +		asm volatile("msr cntv_cval_el0, %0" : : "r" (val));
> > +
> > +	isb();
> > +}
> Please add ARCH_TIMER_REG_CVAL to enum arch_timer_reg, and move these
> accesses into arch_timer_reg_write_cp15().

Adding ARCH_TIMER_REG_CVAL to the enum means we get warnings from bunch of
switch statements that don't actually need a CVAL implementation -- or else we
have to add untested CVAL accessors for arm32 and mmio. ?The arm32 part would
add another dependency on getting an ack from RMK, that can't be postponed as
easily as the archdata/vdso patch.

Since this is specific to an erratum rather than general cval support, I can
move the accesses into fsl_a008585_set_next_event (and convert to
write_sysreg).

> > 
> > +
> > +	do {
> > +		isb();
> What's the ISB for?
> 
> The core should order accesses to the same counter, and any ISB required
> for ordering against other counters should already be present. So I
> don't follow what this is trying to achieve.
> 
> If this is necessary, please add a comment explaining what it is
> intended to ensure.

I think it may have been a leftover from early patch versions when this
function was entirely replacing arch_counter_get_cntvct(). ?I'm not sure why I
put it in the loop, though.

> > @@ -271,6 +346,19 @@ static int
> > arch_timer_set_next_event_phys_mem(unsigned long evt,
> > ?	return 0;
> > ?}
> > ?
> > +static void fsl_a008585_set_sne(struct clock_event_device *clk)
> > +{
> > +#ifdef CONFIG_FSL_ERRATUM_A008585
> > +	if (!static_branch_unlikely(&arch_timer_read_ool_enabled))
> > +		return;
> > +
> > +	if (arch_timer_uses_ppi == VIRT_PPI)
> > +		clk->set_next_event = fsl_a008585_set_next_event_virt;
> > +	else
> > +		clk->set_next_event = fsl_a008585_set_next_event_phys;
> > +#endif
> > +}
> > +
> I'm not keen on the magic hook to reset the function pointers, and the
> additional phys/virt stubs seem pointless. Instead, can we fold this
> into the existing set_next_event? e.g. have that do:
> 
> 	if (needs_fsl_a008585_workaround() {
> 		fsl_a008585_set_next_event(access, evt, clk);
> 		return;
> 	}

OK. ?I had been trying to avoid messing with the standard set_next_event, but
it doesn't matter as much now that static branches are being used. ?In that
case we can avoid duplicating the ctrl code, and only replace the tval write.

-Scott

[PATCH v5 3/5] arm64: arch_timer: Work around QorIQ Erratum A-008585

[Mark Rutland]

On Sun, Sep 18, 2016 at 11:41:25PM -0500, Scott Wood wrote:
> On Mon, 2016-09-12 at 12:36 +0100, Mark Rutland wrote:
> > On Fri, Sep 09, 2016 at 08:03:31PM -0500, Scott Wood wrote:
> > > +static __always_inline void arch_timer_cval_write_cp15(int access, u64
> > > val)
> > > +{
> > > +	if (access == ARCH_TIMER_PHYS_ACCESS)
> > > +		asm volatile("msr cntp_cval_el0, %0" : : "r" (val));
> > > +	else if (access == ARCH_TIMER_VIRT_ACCESS)
> > > +		asm volatile("msr cntv_cval_el0, %0" : : "r" (val));
> > > +
> > > +	isb();
> > > +}
> > Please add ARCH_TIMER_REG_CVAL to enum arch_timer_reg, and move these
> > accesses into arch_timer_reg_write_cp15().
> 
> Adding ARCH_TIMER_REG_CVAL to the enum means we get warnings from bunch of
> switch statements that don't actually need a CVAL implementation -- or else we
> have to add untested CVAL accessors for arm32 and mmio. ?The arm32 part would
> add another dependency on getting an ack from RMK, that can't be postponed as
> easily as the archdata/vdso patch.

That's annoying. Never mind, then.

> Since this is specific to an erratum rather than general cval support, I can
> move the accesses into fsl_a008585_set_next_event (and convert to
> write_sysreg).

Ok. I think that's preferable given we have no other users.

> > > +static void fsl_a008585_set_sne(struct clock_event_device *clk)
> > > +{
> > > +#ifdef CONFIG_FSL_ERRATUM_A008585
> > > +	if (!static_branch_unlikely(&arch_timer_read_ool_enabled))
> > > +		return;
> > > +
> > > +	if (arch_timer_uses_ppi == VIRT_PPI)
> > > +		clk->set_next_event = fsl_a008585_set_next_event_virt;
> > > +	else
> > > +		clk->set_next_event = fsl_a008585_set_next_event_phys;
> > > +#endif
> > > +}
> > > +
> > I'm not keen on the magic hook to reset the function pointers, and the
> > additional phys/virt stubs seem pointless. Instead, can we fold this
> > into the existing set_next_event? e.g. have that do:
> > 
> > 	if (needs_fsl_a008585_workaround() {
> > 		fsl_a008585_set_next_event(access, evt, clk);
> > 		return;
> > 	}
> 
> OK. ?I had been trying to avoid messing with the standard set_next_event, but
> it doesn't matter as much now that static branches are being used. ?In that
> case we can avoid duplicating the ctrl code, and only replace the tval write.

Reconsidering my suggestion, I realise this will also affect the MMIO
timers, so that doesn't work.

So for the moment, I guess we have to keep fsl_a008585_set_next_event().

Thanks,
Mark.

[PATCH v5 3/5] arm64: arch_timer: Work around QorIQ Erratum A-008585

[Scott Wood]

On Mon, 2016-09-19 at 17:52 +0100, Mark Rutland wrote:
> > > > 
> > > > +static void fsl_a008585_set_sne(struct clock_event_device *clk)
> > > > +{
> > > > +#ifdef CONFIG_FSL_ERRATUM_A008585
> > > > +	if (!static_branch_unlikely(&arch_timer_read_ool_enabled))
> > > > +		return;
> > > > +
> > > > +	if (arch_timer_uses_ppi == VIRT_PPI)
> > > > +		clk->set_next_event =
> > > > fsl_a008585_set_next_event_virt;
> > > > +	else
> > > > +		clk->set_next_event =
> > > > fsl_a008585_set_next_event_phys;
> > > > +#endif
> > > > +}
> > > > +
> > > I'm not keen on the magic hook to reset the function pointers, and the
> > > additional phys/virt stubs seem pointless. Instead, can we fold this
> > > into the existing set_next_event? e.g. have that do:
> > > 
> > > 	if (needs_fsl_a008585_workaround() {
> > > 		fsl_a008585_set_next_event(access, evt, clk);
> > > 		return;
> > > 	}
> > OK. ?I had been trying to avoid messing with the standard set_next_event,
> > but
> > it doesn't matter as much now that static branches are being used. ?In
> > that
> > case we can avoid duplicating the ctrl code, and only replace the tval
> > write.
> Reconsidering my suggestion, I realise this will also affect the MMIO
> timers, so that doesn't work.
> 
> So for the moment, I guess we have to keep fsl_a008585_set_next_event().

What is the problem with MMIO timers? ?needs_fsl_a008585_workaround() should
always be false for them.

-Scott

[PATCH v5 3/5] arm64: arch_timer: Work around QorIQ Erratum A-008585

[Mark Rutland]

On Mon, Sep 19, 2016 at 12:01:29PM -0500, Scott Wood wrote:
> On Mon, 2016-09-19 at 17:52 +0100, Mark Rutland wrote:
> > > > > 
> > > > > +static void fsl_a008585_set_sne(struct clock_event_device *clk)
> > > > > +{
> > > > > +#ifdef CONFIG_FSL_ERRATUM_A008585
> > > > > +	if (!static_branch_unlikely(&arch_timer_read_ool_enabled))
> > > > > +		return;
> > > > > +
> > > > > +	if (arch_timer_uses_ppi == VIRT_PPI)
> > > > > +		clk->set_next_event =
> > > > > fsl_a008585_set_next_event_virt;
> > > > > +	else
> > > > > +		clk->set_next_event =
> > > > > fsl_a008585_set_next_event_phys;
> > > > > +#endif
> > > > > +}
> > > > > +
> > > > I'm not keen on the magic hook to reset the function pointers, and the
> > > > additional phys/virt stubs seem pointless. Instead, can we fold this
> > > > into the existing set_next_event? e.g. have that do:
> > > > 
> > > > 	if (needs_fsl_a008585_workaround() {
> > > > 		fsl_a008585_set_next_event(access, evt, clk);
> > > > 		return;
> > > > 	}
> > > OK. ?I had been trying to avoid messing with the standard set_next_event,
> > > but
> > > it doesn't matter as much now that static branches are being used. ?In
> > > that
> > > case we can avoid duplicating the ctrl code, and only replace the tval
> > > write.
> > Reconsidering my suggestion, I realise this will also affect the MMIO
> > timers, so that doesn't work.
> > 
> > So for the moment, I guess we have to keep fsl_a008585_set_next_event().
> 
> What is the problem with MMIO timers? ?needs_fsl_a008585_workaround() should
> always be false for them.

As suggested, needs_fsl_a008585_workaround() takes no parameter, and
set_next_event is called for both cp15/sysreg and MMIO timers. So it
would either be true for all, or false for all.

If it's true for all, we'd end up calling fsl_a008585_set_next_event()
for the MMIO timers too.

Thanks,
Mark.

[PATCH v5 3/5] arm64: arch_timer: Work around QorIQ Erratum A-008585

[Scott Wood]

On Mon, 2016-09-19 at 18:07 +0100, Mark Rutland wrote:
> On Mon, Sep 19, 2016 at 12:01:29PM -0500, Scott Wood wrote:
> > 
> > On Mon, 2016-09-19 at 17:52 +0100, Mark Rutland wrote:
> > > 
> > > > 
> > > > > 
> > > > > > 
> > > > > > 
> > > > > > +static void fsl_a008585_set_sne(struct clock_event_device *clk)
> > > > > > +{
> > > > > > +#ifdef CONFIG_FSL_ERRATUM_A008585
> > > > > > +	if
> > > > > > (!static_branch_unlikely(&arch_timer_read_ool_enabled))
> > > > > > +		return;
> > > > > > +
> > > > > > +	if (arch_timer_uses_ppi == VIRT_PPI)
> > > > > > +		clk->set_next_event =
> > > > > > fsl_a008585_set_next_event_virt;
> > > > > > +	else
> > > > > > +		clk->set_next_event =
> > > > > > fsl_a008585_set_next_event_phys;
> > > > > > +#endif
> > > > > > +}
> > > > > > +
> > > > > I'm not keen on the magic hook to reset the function pointers, and
> > > > > the
> > > > > additional phys/virt stubs seem pointless. Instead, can we fold this
> > > > > into the existing set_next_event? e.g. have that do:
> > > > > 
> > > > > 	if (needs_fsl_a008585_workaround() {
> > > > > 		fsl_a008585_set_next_event(access, evt, clk);
> > > > > 		return;
> > > > > 	}
> > > > OK. ?I had been trying to avoid messing with the standard
> > > > set_next_event,
> > > > but
> > > > it doesn't matter as much now that static branches are being used. ?In
> > > > that
> > > > case we can avoid duplicating the ctrl code, and only replace the tval
> > > > write.
> > > Reconsidering my suggestion, I realise this will also affect the MMIO
> > > timers, so that doesn't work.
> > > 
> > > So for the moment, I guess we have to keep fsl_a008585_set_next_event().
> > What is the problem with MMIO timers? ?needs_fsl_a008585_workaround()
> > should
> > always be false for them.
> As suggested, needs_fsl_a008585_workaround() takes no parameter, and
> set_next_event is called for both cp15/sysreg and MMIO timers. So it
> would either be true for all, or false for all.
> 
> If it's true for all, we'd end up calling fsl_a008585_set_next_event()
> for the MMIO timers too.

There should not be any MMIO timers on a system where
fsl_a008585_set_next_event() returns true.

-Scott

[PATCH v5 3/5] arm64: arch_timer: Work around QorIQ Erratum A-008585

[Mark Rutland]

On Mon, Sep 19, 2016 at 02:16:00PM -0500, Scott Wood wrote:
> On Mon, 2016-09-19 at 18:07 +0100, Mark Rutland wrote:
> > > > Reconsidering my suggestion, I realise this will also affect the MMIO
> > > > timers, so that doesn't work.
> > > > 
> > > > So for the moment, I guess we have to keep fsl_a008585_set_next_event().
> > > What is the problem with MMIO timers? ?needs_fsl_a008585_workaround()
> > > should
> > > always be false for them.
> > As suggested, needs_fsl_a008585_workaround() takes no parameter, and
> > set_next_event is called for both cp15/sysreg and MMIO timers. So it
> > would either be true for all, or false for all.
> > 
> > If it's true for all, we'd end up calling fsl_a008585_set_next_event()
> > for the MMIO timers too.
> 
> There should not be any MMIO timers on a system where
> fsl_a008585_set_next_event() returns true.

I'm generally not keen on relying on that.

For reference, are no MMIO timers implemented at all, or are they simply
not listed in the DT today?

Thanks,
Mark.

[PATCH v5 3/5] arm64: arch_timer: Work around QorIQ Erratum A-008585

[Scott Wood]

On Tue, 2016-09-20 at 10:35 +0100, Mark Rutland wrote:
> On Mon, Sep 19, 2016 at 02:16:00PM -0500, Scott Wood wrote:
> > 
> > On Mon, 2016-09-19 at 18:07 +0100, Mark Rutland wrote:
> > > 
> > > > 
> > > > > 
> > > > > Reconsidering my suggestion, I realise this will also affect the
> > > > > MMIO
> > > > > timers, so that doesn't work.
> > > > > 
> > > > > So for the moment, I guess we have to keep
> > > > > fsl_a008585_set_next_event().
> > > > What is the problem with MMIO timers? ?needs_fsl_a008585_workaround()
> > > > should
> > > > always be false for them.
> > > As suggested, needs_fsl_a008585_workaround() takes no parameter, and
> > > set_next_event is called for both cp15/sysreg and MMIO timers. So it
> > > would either be true for all, or false for all.
> > > 
> > > If it's true for all, we'd end up calling fsl_a008585_set_next_event()
> > > for the MMIO timers too.
> > There should not be any MMIO timers on a system where
> > fsl_a008585_set_next_event() returns true.
> I'm generally not keen on relying on that.
> 
> For reference, are no MMIO timers implemented at all, or are they simply
> not listed in the DT today?

As far as I can tell they're not implemented, but it's possible I'm just not
looking at the right documentation. ?

I agree though that depending on that isn't particularly pretty. ?I'll stick
with the current approach for set_next_event().

-Scott

[PATCH v5 4/5] arm/arm64: arch_timer: Use archdata to indicate vdso suitability

[Scott Wood]

Instead of comparing the name to a magic string, use archdata to
explicitly communicate whether the arch timer is suitable for
direct vdso access.

Signed-off-by: Scott Wood <oss@buserror.net>
Acked-by: Will Deacon <will.deacon@arm.com>
---
 arch/arm/Kconfig                     |  1 +
 arch/arm/include/asm/clocksource.h   |  8 ++++++++
 arch/arm/kernel/vdso.c               |  2 +-
 arch/arm64/Kconfig                   |  1 +
 arch/arm64/include/asm/clocksource.h |  8 ++++++++
 arch/arm64/kernel/vdso.c             |  2 +-
 drivers/clocksource/arm_arch_timer.c | 11 +++--------
 7 files changed, 23 insertions(+), 10 deletions(-)
 create mode 100644 arch/arm/include/asm/clocksource.h
 create mode 100644 arch/arm64/include/asm/clocksource.h

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index a9c4e48..b2113c2 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1,6 +1,7 @@
 config ARM
 	bool
 	default y
+	select ARCH_CLOCKSOURCE_DATA
 	select ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE
 	select ARCH_HAS_DEVMEM_IS_ALLOWED
 	select ARCH_HAS_ELF_RANDOMIZE
diff --git a/arch/arm/include/asm/clocksource.h b/arch/arm/include/asm/clocksource.h
new file mode 100644
index 0000000..0b350a7
--- /dev/null
+++ b/arch/arm/include/asm/clocksource.h
@@ -0,0 +1,8 @@
+#ifndef _ASM_CLOCKSOURCE_H
+#define _ASM_CLOCKSOURCE_H
+
+struct arch_clocksource_data {
+	bool vdso_direct;	/* Usable for direct VDSO access? */
+};
+
+#endif
diff --git a/arch/arm/kernel/vdso.c b/arch/arm/kernel/vdso.c
index 994e971..a0affd1 100644
--- a/arch/arm/kernel/vdso.c
+++ b/arch/arm/kernel/vdso.c
@@ -270,7 +270,7 @@ static bool tk_is_cntvct(const struct timekeeper *tk)
 	if (!IS_ENABLED(CONFIG_ARM_ARCH_TIMER))
 		return false;
 
-	if (strcmp(tk->tkr_mono.clock->name, "arch_sys_counter") != 0)
+	if (!tk->tkr_mono.clock->archdata.vdso_direct)
 		return false;
 
 	return true;
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index bc3f00f..c19a574 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -4,6 +4,7 @@ config ARM64
 	select ACPI_GENERIC_GSI if ACPI
 	select ACPI_REDUCED_HARDWARE_ONLY if ACPI
 	select ACPI_MCFG if ACPI
+	select ARCH_CLOCKSOURCE_DATA
 	select ARCH_HAS_DEVMEM_IS_ALLOWED
 	select ARCH_HAS_ACPI_TABLE_UPGRADE if ACPI
 	select ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE
diff --git a/arch/arm64/include/asm/clocksource.h b/arch/arm64/include/asm/clocksource.h
new file mode 100644
index 0000000..0b350a7
--- /dev/null
+++ b/arch/arm64/include/asm/clocksource.h
@@ -0,0 +1,8 @@
+#ifndef _ASM_CLOCKSOURCE_H
+#define _ASM_CLOCKSOURCE_H
+
+struct arch_clocksource_data {
+	bool vdso_direct;	/* Usable for direct VDSO access? */
+};
+
+#endif
diff --git a/arch/arm64/kernel/vdso.c b/arch/arm64/kernel/vdso.c
index 076312b..2fa7cf5 100644
--- a/arch/arm64/kernel/vdso.c
+++ b/arch/arm64/kernel/vdso.c
@@ -201,7 +201,7 @@ up_fail:
  */
 void update_vsyscall(struct timekeeper *tk)
 {
-	u32 use_syscall = strcmp(tk->tkr_mono.clock->name, "arch_sys_counter");
+	u32 use_syscall = !tk->tkr_mono.clock->archdata.vdso_direct;
 
 	++vdso_data->tb_seq_count;
 	smp_wmb();
diff --git a/drivers/clocksource/arm_arch_timer.c b/drivers/clocksource/arm_arch_timer.c
index 2526543..36d4ee1 100644
--- a/drivers/clocksource/arm_arch_timer.c
+++ b/drivers/clocksource/arm_arch_timer.c
@@ -606,23 +606,18 @@ static void __init arch_counter_register(unsigned type)
 		else
 			arch_timer_read_counter = arch_counter_get_cntpct;
 
+		clocksource_counter.archdata.vdso_direct = true;
+
 #ifdef CONFIG_FSL_ERRATUM_A008585
 		/*
 		 * Don't use the vdso fastpath if errata require using
 		 * the out-of-line counter accessor.
 		 */
 		if (static_branch_unlikely(&arch_timer_read_ool_enabled))
-			clocksource_counter.name = "arch_sys_counter_ool";
+			clocksource_counter.archdata.vdso_direct = false;
 #endif
 	} else {
 		arch_timer_read_counter = arch_counter_get_cntvct_mem;
-
-		/* If the clocksource name is "arch_sys_counter" the
-		 * VDSO will attempt to read the CP15-based counter.
-		 * Ensure this does not happen when CP15-based
-		 * counter is not available.
-		 */
-		clocksource_counter.name = "arch_mem_counter";
 	}
 
 	start_count = arch_timer_read_counter();
-- 
2.7.4

[PATCH v5 5/5] arm64: arch_timer: Add command line parameter for A-008585

[Scott Wood]

This allows KVM users to enable the workaround until a mechanism
is implemented to automatically communicate this information.

Signed-off-by: Scott Wood <oss@buserror.net>
---
 Documentation/kernel-parameters.txt  |  9 +++++++++
 drivers/clocksource/arm_arch_timer.c | 20 +++++++++++++++++++-
 2 files changed, 28 insertions(+), 1 deletion(-)

diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt
index a4f4d69..25037de 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -698,6 +698,15 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
 			loops can be debugged more effectively on production
 			systems.
 
+	clocksource.arm_arch_timer.fsl-a008585=
+			[ARM64]
+			Format: <bool>
+			Enable/disable the workaround of Freescale/NXP
+			erratum A-008585.  This can be useful for KVM
+			guests, if the guest device tree doesn't show the
+			erratum.  If unspecified, the workaround is
+			enabled based on the device tree.
+
 	clearcpuid=BITNUM [X86]
 			Disable CPUID feature X for the kernel. See
 			arch/x86/include/asm/cpufeatures.h for the valid bit
diff --git a/drivers/clocksource/arm_arch_timer.c b/drivers/clocksource/arm_arch_timer.c
index 36d4ee1..e70e530 100644
--- a/drivers/clocksource/arm_arch_timer.c
+++ b/drivers/clocksource/arm_arch_timer.c
@@ -98,6 +98,22 @@ early_param("clocksource.arm_arch_timer.evtstrm", early_evtstrm_cfg);
 DEFINE_STATIC_KEY_FALSE(arch_timer_read_ool_enabled);
 EXPORT_SYMBOL_GPL(arch_timer_read_ool_enabled);
 
+static int fsl_a008585_enable = -1;
+
+static int __init early_fsl_a008585_cfg(char *buf)
+{
+	int ret;
+	bool val;
+
+	ret = strtobool(buf, &val);
+	if (ret)
+		return ret;
+
+	fsl_a008585_enable = val;
+	return 0;
+}
+early_param("clocksource.arm_arch_timer.fsl-a008585", early_fsl_a008585_cfg);
+
 /*
  * __always_inline is used to ensure that func() is not an actual function
  * pointer, which would result in the register accesses potentially being too
@@ -895,7 +911,9 @@ static int __init arch_timer_of_init(struct device_node *np)
 	arch_timer_c3stop = !of_property_read_bool(np, "always-on");
 
 #ifdef CONFIG_FSL_ERRATUM_A008585
-	if (of_property_read_bool(np, "fsl,erratum-a008585"))
+	if (fsl_a008585_enable < 0)
+		fsl_a008585_enable = of_property_read_bool(np, "fsl,erratum-a008585");
+	if (fsl_a008585_enable)
 		static_branch_enable(&arch_timer_read_ool_enabled);
 #endif
 
-- 
2.7.4