diff for duplicates of <20170412144109.GB6842@red-moon>

diff --git a/a/1.txt b/N1/1.txt
index 9716622..9f1c919 100644
--- a/a/1.txt
+++ b/N1/1.txt
@@ -2,50 +2,41 @@ On Wed, Apr 12, 2017 at 03:16:55PM +0100, Russell King - ARM Linux wrote:
 > On Wed, Apr 12, 2017 at 11:51:59PM +1000, Benjamin Herrenschmidt wrote:
 > > On Wed, 2017-04-12 at 12:31 +0100, Russell King - ARM Linux wrote:
 > > > default implementation should fail if it's not supportable on all
-> > > architectures.=A0 However, when we have existing drivers using an
+> > > architectures.  However, when we have existing drivers using an
 > > > interface that doesn't provide the semantics they already require,
 > > > then it makes no sense to effectively break these drivers on a range
 > > > of existing architectures.
-> > > =
-
+> > > 
 > > > The question really is - what's the best way to solve the problem
 > > > with
-> > > existing drivers without breaking them.=A0 I suspect that, sadly, the
+> > > existing drivers without breaking them.  I suspect that, sadly, the
 > > > only realistic way forward here is via the litter-drivers-with-ifdefs
 > > > approach since you don't like providing a default implementation that
 > > > is compatible with what these drivers are already doing.
-> > =
-
-> > Then make ioremap_nopost return NULL when the arch doesn't have =
-
+> > 
+> > Then make ioremap_nopost return NULL when the arch doesn't have 
 > > the right semantic.
-> > =
-
+> > 
 > > The driver than can *chose* to either silently fallback to ioremap,
 > > which has served us well for a long time despite being theorically in
 > > violation of the spec, or do funny things like read back some register
 > > after every config write to ensure ordering etc...
-> > =
-
+> > 
 > > I much prefer that approach than having some generic ioremap function
 > > that exposes a semantic that silently provides a weaker one on some
 > > architecture.
-> > =
-
+> > 
 > > At least we make the failure explicit, and the driver can take
 > > alternate (possibly sub-optimal) action if it chooses to do so.
-> =
-
+> 
 > The same points apply to things like pgprot_writecombine(),
 > pgprot_noncached(), pgprot_device().  Then there's also pgprot_nonposted()
 > that this series also introduces.
-> =
-
+> 
 > If ioremap_nopost() is not possible on an architecture, then
 > pgprot_nonposted() won't be possible either - but you've made no
 > mention of that so far.
-> =
-
+> 
 > Just like the proposed ioremap_nopost(), pgprot_nonposted() is given a
 > default implementation that uses pgprot_noncached().  Maybe we should
 > also make pci_remap_iospace() fail if pgprot_nonposted() is not defined
@@ -58,9 +49,4 @@ patch series - that will be trimmed when the asm-generic include is
 removed from arches according to this discussion).
 
 Thanks,
-Lorenzo
-
-_______________________________________________
-linux-arm-kernel mailing list
-linux-arm-kernel@lists.infradead.org
-http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
\ No newline at end of file
+Lorenzo
\ No newline at end of file
diff --git a/a/content_digest b/N1/content_digest
index 9274249..e9165da 100644
--- a/a/content_digest
+++ b/N1/content_digest
@@ -54,31 +54,7 @@
   " Benjamin Herrenschmidt <benh\@kernel.crashing.org>",
   " Matt Turner <mattst88\@gmail.com>",
   " Haavard Skinnemoen <hskinnemoen\@gmail.com>",
-  " Fenghua Yu <fenghua.yu\@intel.com>",
-  " James Hogan <james.hogan\@imgtec.com>",
-  " Chris Metcalf <cmetcalf\@mellanox.com>",
-  " Arnd Bergmann <arnd\@arndb.de>",
-  " Heiko Carstens <heiko.carstens\@de.ibm.com>",
-  " Stefan Kristiansson <stefan.kristiansson\@saunalahti.fi>",
-  " Mikael Starvik <starvik\@axis.com>",
-  " Ivan Kokshaysky <ink\@jurassic.park.msu.ru>",
-  " Bjorn Helgaas <bhelgaas\@google.com>",
-  " Stafford Horne <shorne\@gmail.com>",
-  " linux-arm-kernel\@lists.infradead.org",
-  " Richard Henderson <rth\@twiddle.net>",
-  " Chris Zankel <chris\@zankel.net>",
-  " Michal Simek <monstr\@monstr.eu>",
-  " Tony Luck <tony.luck\@intel.com>",
-  " linux-pci\@vger.kernel.org",
-  " Vineet Gupta <vgupta\@synopsys.com>",
-  " linux-kernel\@vger.kernel.org",
-  " Ralf Baechle <ralf\@linux-mips.org>",
-  " Richard Kuo <rkuo\@codeaurora.org>",
-  " Niklas Cassel <nks\@flawful.org>",
-  " Luis R. Rodriguez <mcgrof\@kernel.org>",
-  " Martin Schwidefsky <schwidefsky\@de.ibm.com>",
-  " Ley Foon Tan <lftan\@altera.com>",
-  " David S. Miller <davem\@davemloft.net>\0"
+  " Fenghua Yu <fenghua.yu\@intel.com>James\0"
 ]
 [
   "\0000:1\0"
@@ -91,50 +67,41 @@
   "> On Wed, Apr 12, 2017 at 11:51:59PM +1000, Benjamin Herrenschmidt wrote:\n",
   "> > On Wed, 2017-04-12 at 12:31 +0100, Russell King - ARM Linux wrote:\n",
   "> > > default implementation should fail if it's not supportable on all\n",
-  "> > > architectures.=A0 However, when we have existing drivers using an\n",
+  "> > > architectures.\302\240 However, when we have existing drivers using an\n",
   "> > > interface that doesn't provide the semantics they already require,\n",
   "> > > then it makes no sense to effectively break these drivers on a range\n",
   "> > > of existing architectures.\n",
-  "> > > =\n",
-  "\n",
+  "> > > \n",
   "> > > The question really is - what's the best way to solve the problem\n",
   "> > > with\n",
-  "> > > existing drivers without breaking them.=A0 I suspect that, sadly, the\n",
+  "> > > existing drivers without breaking them.\302\240 I suspect that, sadly, the\n",
   "> > > only realistic way forward here is via the litter-drivers-with-ifdefs\n",
   "> > > approach since you don't like providing a default implementation that\n",
   "> > > is compatible with what these drivers are already doing.\n",
-  "> > =\n",
-  "\n",
-  "> > Then make ioremap_nopost return NULL when the arch doesn't have =\n",
-  "\n",
+  "> > \n",
+  "> > Then make ioremap_nopost return NULL when the arch doesn't have \n",
   "> > the right semantic.\n",
-  "> > =\n",
-  "\n",
+  "> > \n",
   "> > The driver than can *chose* to either silently fallback to ioremap,\n",
   "> > which has served us well for a long time despite being theorically in\n",
   "> > violation of the spec, or do funny things like read back some register\n",
   "> > after every config write to ensure ordering etc...\n",
-  "> > =\n",
-  "\n",
+  "> > \n",
   "> > I much prefer that approach than having some generic ioremap function\n",
   "> > that exposes a semantic that silently provides a weaker one on some\n",
   "> > architecture.\n",
-  "> > =\n",
-  "\n",
+  "> > \n",
   "> > At least we make the failure explicit, and the driver can take\n",
   "> > alternate (possibly sub-optimal) action if it chooses to do so.\n",
-  "> =\n",
-  "\n",
+  "> \n",
   "> The same points apply to things like pgprot_writecombine(),\n",
   "> pgprot_noncached(), pgprot_device().  Then there's also pgprot_nonposted()\n",
   "> that this series also introduces.\n",
-  "> =\n",
-  "\n",
+  "> \n",
   "> If ioremap_nopost() is not possible on an architecture, then\n",
   "> pgprot_nonposted() won't be possible either - but you've made no\n",
   "> mention of that so far.\n",
-  "> =\n",
-  "\n",
+  "> \n",
   "> Just like the proposed ioremap_nopost(), pgprot_nonposted() is given a\n",
   "> default implementation that uses pgprot_noncached().  Maybe we should\n",
   "> also make pci_remap_iospace() fail if pgprot_nonposted() is not defined\n",
@@ -147,12 +114,7 @@
   "removed from arches according to this discussion).\n",
   "\n",
   "Thanks,\n",
-  "Lorenzo\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"
+  "Lorenzo"
 ]
 
-6e765bc8acb8bf7cc218b1875ea463bdeafa5f75ed47f597add56fc1f8105bc6
+7b163d86e0b1e7d4cc0b1133eb115d5235150fd1fc72f7a94171a4bef277e8ff
