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

diff --git a/a/1.txt b/N1/1.txt
index c70c4e9..e4c67e4 100644
--- a/a/1.txt
+++ b/N1/1.txt
@@ -2,41 +2,50 @@ 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.  However, when we have existing drivers using an
+> > > architectures.=A0 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.  I suspect that, sadly, the
+> > > existing drivers without breaking them.=A0 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
@@ -50,3 +59,8 @@ 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
diff --git a/a/content_digest b/N1/content_digest
index 4b80229..7bff5a3 100644
--- a/a/content_digest
+++ b/N1/content_digest
@@ -31,48 +31,81 @@
   Benjamin Herrenschmidt <benh@kernel.crashing.org>
   Matt Turner <mattst88@gmail.com>
   Haavard Skinnemoen <hskinnemoen@gmail.com>
- " Fenghua Yu <fenghua.yu@intel.com>James\0"
+  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"
  "\00:1\0"
  "b\0"
  "On Wed, Apr 12, 2017 at 03:16:55PM +0100, Russell King - ARM Linux wrote:\n"
  "> 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.\302\240 However, when we have existing drivers using an\n"
+ "> > > architectures.=A0 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.\302\240 I suspect that, sadly, the\n"
+ "> > > existing drivers without breaking them.=A0 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"
- "> > 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"
+ "\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"
@@ -85,6 +118,11 @@
  "removed from arches according to this discussion).\n"
  "\n"
  "Thanks,\n"
- Lorenzo
+ "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
 
-7b163d86e0b1e7d4cc0b1133eb115d5235150fd1fc72f7a94171a4bef277e8ff
+6e765bc8acb8bf7cc218b1875ea463bdeafa5f75ed47f597add56fc1f8105bc6
