diff for duplicates of <1467355905.32358.31.camel@buserror.net>

diff --git a/a/1.txt b/N1/1.txt
index 20202eb..1762201 100644
--- a/a/1.txt
+++ b/N1/1.txt
@@ -20,13 +20,13 @@ On Mon, 2016-06-27 at 14:13 +0100, Marc Zyngier wrote:
 > > > > clk);
 > > > > +		cval_new = __arch_counter_get_cntvct();
 > > > Don't you need to guarantee the order of accesses here?
-> > I'm not 100% sure.??The erratum workaround sample code doesn't show any
+> > I'm not 100% sure.  The erratum workaround sample code doesn't show any
 > > barriers, and adding more barriers could make it harder for the loop to
-> > successfully complete.??There's already a barrier after the write, so the
+> > successfully complete.  There's already a barrier after the write, so the
 > > only
 > > concern should be whether the timer read could be reordered after the
 > > timer
-> > write, which could cause the loop to exit even if the write was bad.??Do
+> > write, which could cause the loop to exit even if the write was bad.  Do
 > > you
 > > know if A53 or A57 will reorder a counter read relative to a tval write?
 > I can't see any absolute guarantee that they wouldn't be reordered (but
@@ -34,7 +34,7 @@ On Mon, 2016-06-27 at 14:13 +0100, Marc Zyngier wrote:
 > the side of caution here.
 
 Adding another isb() before arch_timer_reg_write() causes the loop to not
-complete with any reasonable timeout. ?A testing loop (that repeatedly writes
+complete with any reasonable timeout.  A testing loop (that repeatedly writes
 to TVAL (using the workaround code), reads it back, and checks that the value
 read back is not greater than the value that was written) shows that the
 workaround without the extra isb() is effective -- lots of assertions without
@@ -42,3 +42,9 @@ the workaround, and none with it -- but I'll go with the cval workaround
 instead.
 
 -Scott
+
+
+_______________________________________________
+linux-arm-kernel mailing list
+linux-arm-kernel@lists.infradead.org
+http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
diff --git a/a/content_digest b/N1/content_digest
index a137dec..61feb56 100644
--- a/a/content_digest
+++ b/N1/content_digest
@@ -2,10 +2,15 @@
  "ref\020160513112441.200f4349@arm.com\0"
  "ref\01466559926.22191.203.camel@buserror.net\0"
  "ref\05771267D.7030102@arm.com\0"
- "From\0oss@buserror.net (Scott Wood)\0"
- "Subject\0[PATCH v2 1/2] ARM64: arch_timer: Work around QorIQ Erratum A-008585\0"
+ "From\0Scott Wood <oss@buserror.net>\0"
+ "Subject\0Re: [PATCH v2 1/2] ARM64: arch_timer: Work around QorIQ Erratum A-008585\0"
  "Date\0Fri, 01 Jul 2016 01:51:45 -0500\0"
- "To\0linux-arm-kernel@lists.infradead.org\0"
+ "To\0Marc Zyngier <marc.zyngier@arm.com>\0"
+ "Cc\0Catalin Marinas <catalin.marinas@arm.com>"
+  Will Deacon <will.deacon@arm.com>
+  stuart.yoder@nxp.com
+  linux-arm-kernel@lists.infradead.org
+ " devicetree@vger.kernel.org\0"
  "\00:1\0"
  "b\0"
  "On Mon, 2016-06-27 at 14:13 +0100, Marc Zyngier wrote:\n"
@@ -30,13 +35,13 @@
  "> > > > clk);\n"
  "> > > > +\t\tcval_new = __arch_counter_get_cntvct();\n"
  "> > > Don't you need to guarantee the order of accesses here?\n"
- "> > I'm not 100% sure.??The erratum workaround sample code doesn't show any\n"
+ "> > I'm not 100% sure.\302\240\302\240The erratum workaround sample code doesn't show any\n"
  "> > barriers, and adding more barriers could make it harder for the loop to\n"
- "> > successfully complete.??There's already a barrier after the write, so the\n"
+ "> > successfully complete.\302\240\302\240There's already a barrier after the write, so the\n"
  "> > only\n"
  "> > concern should be whether the timer read could be reordered after the\n"
  "> > timer\n"
- "> > write, which could cause the loop to exit even if the write was bad.??Do\n"
+ "> > write, which could cause the loop to exit even if the write was bad.\302\240\302\240Do\n"
  "> > you\n"
  "> > know if A53 or A57 will reorder a counter read relative to a tval write?\n"
  "> I can't see any absolute guarantee that they wouldn't be reordered (but\n"
@@ -44,13 +49,19 @@
  "> the side of caution here.\n"
  "\n"
  "Adding another isb() before arch_timer_reg_write() causes the loop to not\n"
- "complete with any reasonable timeout. ?A testing loop (that repeatedly writes\n"
+ "complete with any reasonable timeout. \302\240A testing loop (that repeatedly writes\n"
  "to TVAL (using the workaround code), reads it back, and checks that the value\n"
  "read back is not greater than the value that was written) shows that the\n"
  "workaround without the extra isb() is effective -- lots of assertions without\n"
  "the workaround, and none with it -- but I'll go with the cval workaround\n"
  "instead.\n"
  "\n"
- -Scott
+ "-Scott\n"
+ "\n"
+ "\n"
+ "_______________________________________________\n"
+ "linux-arm-kernel mailing list\n"
+ "linux-arm-kernel@lists.infradead.org\n"
+ http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
 
-c512cb3ab5e3423d1b089c44e6a4dc444dc688fda08db365e3fb4ab671cd2c67
+2427a3d0299d1ef52ae58b34156c0af05d9505805f87c58aeb256f3dc7134970
