diff for duplicates of <20170418085732.GA23882@red-moon>

diff --git a/a/1.txt b/N1/1.txt
index 0ddca4c..5056b5b 100644
--- a/a/1.txt
+++ b/N1/1.txt
@@ -3,42 +3,57 @@ On Thu, Apr 13, 2017 at 10:53:00AM +1000, Benjamin Herrenschmidt wrote:
 > > On Thu, Apr 13, 2017 at 08:30:40AM +1000, Benjamin Herrenschmidt wrote:
 > > > My point with nopost() is that it's never ok to silently downgrade it.
 > > > Code written with the assumption that there is no posting will be
-> > > *incorrect* if posting happens. We do live with that "bug" today indeed
+> > > *incorrect* if posting happens. We do live with that "bug" today inde=
+ed
 > > > but once we have that accessors we might start growing more code that
 > > > relies on the specific attribute that things aren't posted and will be
 > > > wrong on all the archs providing the default implementation.
-> > > 
-> > > This is why I insist that pgprot_nopost() if it exists globally, should
+> > > =
+
+> > > This is why I insist that pgprot_nopost() if it exists globally, shou=
+ld
 > > > return NULL when the semantic cannot be provided.
-> > 
-> > Now you're not talking sense.  pgprot_nopost() does _not_ return a pointer.
+> > =
+
+> > Now you're not talking sense.=A0=A0pgprot_nopost() does _not_ return a =
+pointer.
 > > You're talking here as if you're still talking about ioremap_nopost().
 > > So, I think you're confused.
-> 
+> =
+
 > Nah, just "typo", I meant ioremap_nopost.
-> 
-> > > > > 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
+> =
+
+> > > > > Just like the proposed ioremap_nopost(), pgprot_nonposted() is gi=
+ven a
+> > > > > default implementation that uses pgprot_noncached().=A0 Maybe we =
+should
+> > > > > also make pci_remap_iospace() fail if pgprot_nonposted() is not d=
+efined
 > > > > > by the architecture?
-> > > 
+> > > =
+
 > > > Or we *document* that mmap of IO space can result in something that is
 > > > partially non-posted.
-> > 
+> > =
+
 > > Oh, so we _can_ provide an interface that has weaker semantics than it
 > > should provided we document it.
-> > 
+> > =
+
 > > It's insane to have different behaviours from these two interfaces, yet
 > > you seem to have said exactly that in your reply.
 > >
 > > It's actually worse than that - what you've just said is that it's okay
 > > for userspace to map IO space with weaker semantics than the PCI
 > > specification states, but it's not okay for kernel space to do that.
-> 
+> =
+
 > That is not what I'm saying. What I'm saying is that it's not ok to
 > provide a generic mapping attribute that silently happens to be weaker
 > than documented on some architectures.
-> 
+> =
+
 > The PCI part is orthogonal. How do you handle PCI in absence of that
 > attribute is a separate problem (which is probably a matter of just
 > documenting things).
@@ -50,7 +65,7 @@ the Kconfig option for ioremap_nopost() should complete this series.
 int pci_remap_iospace(const struct resource *res, phys_addr_t phys_addr)
 {
 #if defined(PCI_IOBASE) && defined(CONFIG_MMU) && defined(pgprot_nonposted)
-	unsigned long vaddr = (unsigned long)PCI_IOBASE + res->start;
+	unsigned long vaddr =3D (unsigned long)PCI_IOBASE + res->start;
 
 	if (!(res->flags & IORESOURCE_IO))
 		return -EINVAL;
@@ -66,3 +81,8 @@ int pci_remap_iospace(const struct resource *res, phys_addr_t phys_addr)
 	return -ENODEV;
 #endif
 }
+
+_______________________________________________
+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 861bbe5..51f2c07 100644
--- a/a/content_digest
+++ b/N1/content_digest
@@ -35,7 +35,30 @@
   Catalin Marinas <catalin.marinas@arm.com>
   Matt Turner <mattst88@gmail.com>
   Haavard Skinnemoen <hskinnemoen@gmail.com>
- " Fenghua Yu <fenghua>\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>
+  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 Thu, Apr 13, 2017 at 10:53:00AM +1000, Benjamin Herrenschmidt wrote:\n"
@@ -43,42 +66,57 @@
  "> > On Thu, Apr 13, 2017 at 08:30:40AM +1000, Benjamin Herrenschmidt wrote:\n"
  "> > > My point with nopost() is that it's never ok to silently downgrade it.\n"
  "> > > Code written with the assumption that there is no posting will be\n"
- "> > > *incorrect* if posting happens. We do live with that \"bug\" today indeed\n"
+ "> > > *incorrect* if posting happens. We do live with that \"bug\" today inde=\n"
+ "ed\n"
  "> > > but once we have that accessors we might start growing more code that\n"
  "> > > relies on the specific attribute that things aren't posted and will be\n"
  "> > > wrong on all the archs providing the default implementation.\n"
- "> > > \n"
- "> > > This is why I insist that pgprot_nopost() if it exists globally, should\n"
+ "> > > =\n"
+ "\n"
+ "> > > This is why I insist that pgprot_nopost() if it exists globally, shou=\n"
+ "ld\n"
  "> > > return NULL when the semantic cannot be provided.\n"
- "> > \n"
- "> > Now you're not talking sense.\302\240\302\240pgprot_nopost() does _not_ return a pointer.\n"
+ "> > =\n"
+ "\n"
+ "> > Now you're not talking sense.=A0=A0pgprot_nopost() does _not_ return a =\n"
+ "pointer.\n"
  "> > You're talking here as if you're still talking about ioremap_nopost().\n"
  "> > So, I think you're confused.\n"
- "> \n"
+ "> =\n"
+ "\n"
  "> Nah, just \"typo\", I meant ioremap_nopost.\n"
- "> \n"
- "> > > > > Just like the proposed ioremap_nopost(), pgprot_nonposted() is given a\n"
- "> > > > > default implementation that uses pgprot_noncached().\302\240 Maybe we should\n"
- "> > > > > also make pci_remap_iospace() fail if pgprot_nonposted() is not defined\n"
+ "> =\n"
+ "\n"
+ "> > > > > Just like the proposed ioremap_nopost(), pgprot_nonposted() is gi=\n"
+ "ven a\n"
+ "> > > > > default implementation that uses pgprot_noncached().=A0 Maybe we =\n"
+ "should\n"
+ "> > > > > also make pci_remap_iospace() fail if pgprot_nonposted() is not d=\n"
+ "efined\n"
  "> > > > > by the architecture?\n"
- "> > > \n"
+ "> > > =\n"
+ "\n"
  "> > > Or we *document* that mmap of IO space can result in something that is\n"
  "> > > partially non-posted.\n"
- "> > \n"
+ "> > =\n"
+ "\n"
  "> > Oh, so we _can_ provide an interface that has weaker semantics than it\n"
  "> > should provided we document it.\n"
- "> > \n"
+ "> > =\n"
+ "\n"
  "> > It's insane to have different behaviours from these two interfaces, yet\n"
  "> > you seem to have said exactly that in your reply.\n"
  "> >\n"
  "> > It's actually worse than that - what you've just said is that it's okay\n"
  "> > for userspace to map IO space with weaker semantics than the PCI\n"
  "> > specification states, but it's not okay for kernel space to do that.\n"
- "> \n"
+ "> =\n"
+ "\n"
  "> That is not what I'm saying. What I'm saying is that it's not ok to\n"
  "> provide a generic mapping attribute that silently happens to be weaker\n"
  "> than documented on some architectures.\n"
- "> \n"
+ "> =\n"
+ "\n"
  "> The PCI part is orthogonal. How do you handle PCI in absence of that\n"
  "> attribute is a separate problem (which is probably a matter of just\n"
  "> documenting things).\n"
@@ -90,7 +128,7 @@
  "int pci_remap_iospace(const struct resource *res, phys_addr_t phys_addr)\n"
  "{\n"
  "#if defined(PCI_IOBASE) && defined(CONFIG_MMU) && defined(pgprot_nonposted)\n"
- "\tunsigned long vaddr = (unsigned long)PCI_IOBASE + res->start;\n"
+ "\tunsigned long vaddr =3D (unsigned long)PCI_IOBASE + res->start;\n"
  "\n"
  "\tif (!(res->flags & IORESOURCE_IO))\n"
  "\t\treturn -EINVAL;\n"
@@ -105,6 +143,11 @@
  "\tWARN_ONCE(1, \"This architecture does not support memory mapped I/O\\n\");\n"
  "\treturn -ENODEV;\n"
  "#endif\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
 
-f30ae5277d409591ae61d3c9cbd80ded2598c195aa2558e2fd1c113cf5191b38
+3f37263bebcea0061c026d57aaeeb01926aeff5350b5a6e39d091032570e77c8
