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

diff --git a/a/1.txt b/N1/1.txt
index 799e8fb..cda60fe 100644
--- a/a/1.txt
+++ b/N1/1.txt
@@ -3,57 +3,42 @@ 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 inde=
-ed
+> > > *incorrect* if posting happens. We do live with that "bug" today indeed
 > > > 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, shou=
-ld
+> > > 
+> > > This is why I insist that pgprot_nopost() if it exists globally, should
 > > > return NULL when the semantic cannot be provided.
-> > =
-
-> > Now you're not talking sense.=A0=A0pgprot_nopost() does _not_ return a =
-pointer.
+> > 
+> > Now you're not talking sense.  pgprot_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 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
+> 
+> > > > > 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
 > > > > > 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).
@@ -65,7 +50,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 =3D (unsigned long)PCI_IOBASE + res->start;
+	unsigned long vaddr = (unsigned long)PCI_IOBASE + res->start;
 
 	if (!(res->flags & IORESOURCE_IO))
 		return -EINVAL;
@@ -80,9 +65,4 @@ int pci_remap_iospace(const struct resource *res, phys_addr_t phys_addr)
 	WARN_ONCE(1, "This architecture does not support memory mapped I/O\n");
 	return -ENODEV;
 #endif
-}
-
-_______________________________________________
-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
+}
\ No newline at end of file
diff --git a/a/content_digest b/N1/content_digest
index dd4450b..08c0d66 100644
--- a/a/content_digest
+++ b/N1/content_digest
@@ -64,30 +64,7 @@
   " Catalin Marinas <catalin.marinas\@arm.com>",
   " 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>",
-  " 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>\0"
 ]
 [
   "\0000:1\0"
@@ -101,57 +78,42 @@
   "> > 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 inde=\n",
-  "ed\n",
+  "> > > *incorrect* if posting happens. We do live with that \"bug\" today indeed\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",
-  "\n",
-  "> > > This is why I insist that pgprot_nopost() if it exists globally, shou=\n",
-  "ld\n",
+  "> > > \n",
+  "> > > This is why I insist that pgprot_nopost() if it exists globally, should\n",
   "> > > return NULL when the semantic cannot be provided.\n",
-  "> > =\n",
-  "\n",
-  "> > Now you're not talking sense.=A0=A0pgprot_nopost() does _not_ return a =\n",
-  "pointer.\n",
+  "> > \n",
+  "> > Now you're not talking sense.\302\240\302\240pgprot_nopost() does _not_ return a 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",
-  "\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",
+  "> \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",
   "> > > > > 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",
@@ -163,7 +125,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 =3D (unsigned long)PCI_IOBASE + res->start;\n",
+  "\tunsigned long vaddr = (unsigned long)PCI_IOBASE + res->start;\n",
   "\n",
   "\tif (!(res->flags & IORESOURCE_IO))\n",
   "\t\treturn -EINVAL;\n",
@@ -178,12 +140,7 @@
   "\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"
+  "}"
 ]
 
-3f37263bebcea0061c026d57aaeeb01926aeff5350b5a6e39d091032570e77c8
+f30ae5277d409591ae61d3c9cbd80ded2598c195aa2558e2fd1c113cf5191b38
