diff for duplicates of <20170418154937.GA1006@red-moon>

diff --git a/a/1.txt b/N1/1.txt
index aa5e4b8..6565768 100644
--- a/a/1.txt
+++ b/N1/1.txt
@@ -4,80 +4,64 @@ On Wed, Apr 12, 2017 at 12:20:22PM +0100, Russell King - ARM Linux wrote:
 > > > +static inline void __iomem *ioremap_nopost(phys_addr_t offset,
 > > > size_t size)
 > > > +{
-> > > +=A0=A0=A0=A0=A0=A0=A0return ioremap_nocache(offset, size);
+> > > +       return ioremap_nocache(offset, size);
 > > > +}
 > > > +
-> > =
-
+> > 
 > > No this is wrong as I explained.
-> > =
-
+> > 
 > > This is a semantic that simply *cannot* be generically provided accross
 > > architectures as a mapping attribute.
-> > =
-
+> > 
 > > The solution to your problem lies elsewhere.
-> =
-
+> 
 > I disagree.  Sure, it may not be supportable across all architectures,
 > but we're not introducing something brand new here.
-> =
-
+> 
 > What we're trying to do is to fix some _existing_ drivers that are
 > already using ioremap() to map the PCI IO and configuration spaces.
 > Maybe it would help if those drivers were part of this patch set,
 > rather than the patch set just introducing a whole new architecture
 > interface without really showing where the problem drivers are.
-> =
-
+> 
 > The issue here is that if we make this new ioremap_nopost() fail by
 > returning NULL if an architecture does not provide an implementation,
 > then these drivers are going to start failing on such architectures.
-> =
-
+> 
 > It is only safe to do that where we know for certain that the drivers
 > are not used - but I don't think that's the case here (it's difficult
 > to tell, because no drivers are updated in this series, so we don't
 > know which are going to be affected.)
-> =
-
+> 
 > So, the question is:
-> =
-
+> 
 > - is it better to provide a default implementation which provides the
 >   functionality that existing drivers are _already_ using, albiet not
 >   entirely correctly.
-> =
-
+> 
 > or:
-> =
-
+> 
 > - is it better to break drivers on architectures when they're converted
 >   to fix up this issue.
-> =
-
+> 
 > What, I suppose, we could do is not bother with a default implementation,
 > but instead litter drivers with:
-> =
-
+> 
 > +#ifdef ioremap_post
-> +	base =3D ioremap_post(...);
+> +	base = ioremap_post(...);
 > +#else
-> 	base =3D ioremap(...);
+> 	base = ioremap(...);
 > +#endif
-> =
-
+> 
 > which gets around your objection - not providing a default that's weaker
 > than required, but also not breaking the drivers.  The problem is that
 > we end up littering drivers with ifdefs.
-> =
-
+> 
 > However, I'm willing to bet that the architectures that you're saying
 > will not be able to support the weaker semantic won't have any need to
 > use these drivers, or if they do, the drivers will need the method of
 > accessing stuff like PCI IO and configuration spaces radically altered.
-> =
-
+> 
 > So, maybe the best solution is to not provide any kind of default
 > implementation, add a HAVE_IOREMAP_POST Kconfig symbol, have architectures
 > select that when they do provide ioremap_post(), and make the drivers
@@ -97,9 +81,4 @@ like it to be PCI specific, just adding an option on the table to make
 progress).
 
 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 ff578bf..4f61e47 100644
--- a/a/content_digest
+++ b/N1/content_digest
@@ -45,31 +45,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"
@@ -84,80 +60,64 @@
   "> > > +static inline void __iomem *ioremap_nopost(phys_addr_t offset,\n",
   "> > > size_t size)\n",
   "> > > +{\n",
-  "> > > +=A0=A0=A0=A0=A0=A0=A0return ioremap_nocache(offset, size);\n",
+  "> > > +\302\240\302\240\302\240\302\240\302\240\302\240\302\240return ioremap_nocache(offset, size);\n",
   "> > > +}\n",
   "> > > +\n",
-  "> > =\n",
-  "\n",
+  "> > \n",
   "> > No this is wrong as I explained.\n",
-  "> > =\n",
-  "\n",
+  "> > \n",
   "> > This is a semantic that simply *cannot* be generically provided accross\n",
   "> > architectures as a mapping attribute.\n",
-  "> > =\n",
-  "\n",
+  "> > \n",
   "> > The solution to your problem lies elsewhere.\n",
-  "> =\n",
-  "\n",
+  "> \n",
   "> I disagree.  Sure, it may not be supportable across all architectures,\n",
   "> but we're not introducing something brand new here.\n",
-  "> =\n",
-  "\n",
+  "> \n",
   "> What we're trying to do is to fix some _existing_ drivers that are\n",
   "> already using ioremap() to map the PCI IO and configuration spaces.\n",
   "> Maybe it would help if those drivers were part of this patch set,\n",
   "> rather than the patch set just introducing a whole new architecture\n",
   "> interface without really showing where the problem drivers are.\n",
-  "> =\n",
-  "\n",
+  "> \n",
   "> The issue here is that if we make this new ioremap_nopost() fail by\n",
   "> returning NULL if an architecture does not provide an implementation,\n",
   "> then these drivers are going to start failing on such architectures.\n",
-  "> =\n",
-  "\n",
+  "> \n",
   "> It is only safe to do that where we know for certain that the drivers\n",
   "> are not used - but I don't think that's the case here (it's difficult\n",
   "> to tell, because no drivers are updated in this series, so we don't\n",
   "> know which are going to be affected.)\n",
-  "> =\n",
-  "\n",
+  "> \n",
   "> So, the question is:\n",
-  "> =\n",
-  "\n",
+  "> \n",
   "> - is it better to provide a default implementation which provides the\n",
   ">   functionality that existing drivers are _already_ using, albiet not\n",
   ">   entirely correctly.\n",
-  "> =\n",
-  "\n",
+  "> \n",
   "> or:\n",
-  "> =\n",
-  "\n",
+  "> \n",
   "> - is it better to break drivers on architectures when they're converted\n",
   ">   to fix up this issue.\n",
-  "> =\n",
-  "\n",
+  "> \n",
   "> What, I suppose, we could do is not bother with a default implementation,\n",
   "> but instead litter drivers with:\n",
-  "> =\n",
-  "\n",
+  "> \n",
   "> +#ifdef ioremap_post\n",
-  "> +\tbase =3D ioremap_post(...);\n",
+  "> +\tbase = ioremap_post(...);\n",
   "> +#else\n",
-  "> \tbase =3D ioremap(...);\n",
+  "> \tbase = ioremap(...);\n",
   "> +#endif\n",
-  "> =\n",
-  "\n",
+  "> \n",
   "> which gets around your objection - not providing a default that's weaker\n",
   "> than required, but also not breaking the drivers.  The problem is that\n",
   "> we end up littering drivers with ifdefs.\n",
-  "> =\n",
-  "\n",
+  "> \n",
   "> However, I'm willing to bet that the architectures that you're saying\n",
   "> will not be able to support the weaker semantic won't have any need to\n",
   "> use these drivers, or if they do, the drivers will need the method of\n",
   "> accessing stuff like PCI IO and configuration spaces radically altered.\n",
-  "> =\n",
-  "\n",
+  "> \n",
   "> So, maybe the best solution is to not provide any kind of default\n",
   "> implementation, add a HAVE_IOREMAP_POST Kconfig symbol, have architectures\n",
   "> select that when they do provide ioremap_post(), and make the drivers\n",
@@ -177,12 +137,7 @@
   "progress).\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"
 ]
 
-14ab6ba596fad95ab23af73d040f27c67b5096847e5be69ae64841a849011ca3
+8a8ed3a43a3c929812297e47227ccd9546d1fcf79ca3a861a279b1880c75041a
