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

diff --git a/a/1.txt b/N1/1.txt
index 00054fc..3025daa 100644
--- a/a/1.txt
+++ b/N1/1.txt
@@ -4,64 +4,80 @@ 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)
 > > > +{
-> > > +       return ioremap_nocache(offset, size);
+> > > +=A0=A0=A0=A0=A0=A0=A0return 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 = ioremap_post(...);
+> +	base =3D ioremap_post(...);
 > +#else
-> 	base = ioremap(...);
+> 	base =3D 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
@@ -82,3 +98,8 @@ progress).
 
 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 3496f11..897248b 100644
--- a/a/content_digest
+++ b/N1/content_digest
@@ -28,7 +28,31 @@
   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 12:20:22PM +0100, Russell King - ARM Linux wrote:\n"
@@ -37,64 +61,80 @@
  "> > > +static inline void __iomem *ioremap_nopost(phys_addr_t offset,\n"
  "> > > size_t size)\n"
  "> > > +{\n"
- "> > > +\302\240\302\240\302\240\302\240\302\240\302\240\302\240return ioremap_nocache(offset, size);\n"
+ "> > > +=A0=A0=A0=A0=A0=A0=A0return 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 = ioremap_post(...);\n"
+ "> +\tbase =3D ioremap_post(...);\n"
  "> +#else\n"
- "> \tbase = ioremap(...);\n"
+ "> \tbase =3D 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"
@@ -114,6 +154,11 @@
  "progress).\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
 
-8a8ed3a43a3c929812297e47227ccd9546d1fcf79ca3a861a279b1880c75041a
+14ab6ba596fad95ab23af73d040f27c67b5096847e5be69ae64841a849011ca3
