diff for duplicates of <1492005119.7236.62.camel@kernel.crashing.org>

diff --git a/a/1.txt b/N1/1.txt
index 7af38c8..55ca01d 100644
--- a/a/1.txt
+++ b/N1/1.txt
@@ -1,28 +1,37 @@
-T24gV2VkLCAyMDE3LTA0LTEyIGF0IDEyOjMxICswMTAwLCBSdXNzZWxsIEtpbmcgLSBBUk0gTGlu
-dXggd3JvdGU6Cj4gZGVmYXVsdCBpbXBsZW1lbnRhdGlvbiBzaG91bGQgZmFpbCBpZiBpdCdzIG5v
-dCBzdXBwb3J0YWJsZSBvbiBhbGwKPiBhcmNoaXRlY3R1cmVzLsKgIEhvd2V2ZXIsIHdoZW4gd2Ug
-aGF2ZSBleGlzdGluZyBkcml2ZXJzIHVzaW5nIGFuCj4gaW50ZXJmYWNlIHRoYXQgZG9lc24ndCBw
-cm92aWRlIHRoZSBzZW1hbnRpY3MgdGhleSBhbHJlYWR5IHJlcXVpcmUsCj4gdGhlbiBpdCBtYWtl
-cyBubyBzZW5zZSB0byBlZmZlY3RpdmVseSBicmVhayB0aGVzZSBkcml2ZXJzIG9uIGEgcmFuZ2UK
-PiBvZiBleGlzdGluZyBhcmNoaXRlY3R1cmVzLgo+IAo+IFRoZSBxdWVzdGlvbiByZWFsbHkgaXMg
-LSB3aGF0J3MgdGhlIGJlc3Qgd2F5IHRvIHNvbHZlIHRoZSBwcm9ibGVtCj4gd2l0aAo+IGV4aXN0
-aW5nIGRyaXZlcnMgd2l0aG91dCBicmVha2luZyB0aGVtLsKgIEkgc3VzcGVjdCB0aGF0LCBzYWRs
-eSwgdGhlCj4gb25seSByZWFsaXN0aWMgd2F5IGZvcndhcmQgaGVyZSBpcyB2aWEgdGhlIGxpdHRl
-ci1kcml2ZXJzLXdpdGgtaWZkZWZzCj4gYXBwcm9hY2ggc2luY2UgeW91IGRvbid0IGxpa2UgcHJv
-dmlkaW5nIGEgZGVmYXVsdCBpbXBsZW1lbnRhdGlvbiB0aGF0Cj4gaXMgY29tcGF0aWJsZSB3aXRo
-IHdoYXQgdGhlc2UgZHJpdmVycyBhcmUgYWxyZWFkeSBkb2luZy4KClRoZW4gbWFrZSBpb3JlbWFw
-X25vcG9zdCByZXR1cm4gTlVMTCB3aGVuIHRoZSBhcmNoIGRvZXNuJ3QgaGF2ZSAKdGhlIHJpZ2h0
-IHNlbWFudGljLgoKVGhlIGRyaXZlciB0aGFuIGNhbiAqY2hvc2UqIHRvIGVpdGhlciBzaWxlbnRs
-eSBmYWxsYmFjayB0byBpb3JlbWFwLAp3aGljaCBoYXMgc2VydmVkIHVzIHdlbGwgZm9yIGEgbG9u
-ZyB0aW1lIGRlc3BpdGUgYmVpbmcgdGhlb3JpY2FsbHkgaW4KdmlvbGF0aW9uIG9mIHRoZSBzcGVj
-LCBvciBkbyBmdW5ueSB0aGluZ3MgbGlrZSByZWFkIGJhY2sgc29tZSByZWdpc3RlcgphZnRlciBl
-dmVyeSBjb25maWcgd3JpdGUgdG8gZW5zdXJlIG9yZGVyaW5nIGV0Yy4uLgoKSSBtdWNoIHByZWZl
-ciB0aGF0IGFwcHJvYWNoIHRoYW4gaGF2aW5nIHNvbWUgZ2VuZXJpYyBpb3JlbWFwIGZ1bmN0aW9u
-CnRoYXQgZXhwb3NlcyBhIHNlbWFudGljIHRoYXQgc2lsZW50bHkgcHJvdmlkZXMgYSB3ZWFrZXIg
-b25lIG9uIHNvbWUKYXJjaGl0ZWN0dXJlLgoKQXQgbGVhc3Qgd2UgbWFrZSB0aGUgZmFpbHVyZSBl
-eHBsaWNpdCwgYW5kIHRoZSBkcml2ZXIgY2FuIHRha2UKYWx0ZXJuYXRlIChwb3NzaWJseSBzdWIt
-b3B0aW1hbCkgYWN0aW9uIGlmIGl0IGNob29zZXMgdG8gZG8gc28uCgpDaGVlcnMsCkJlbi4KCgpf
-X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpsaW51eC1hcm0t
-a2VybmVsIG1haWxpbmcgbGlzdApsaW51eC1hcm0ta2VybmVsQGxpc3RzLmluZnJhZGVhZC5vcmcK
-aHR0cDovL2xpc3RzLmluZnJhZGVhZC5vcmcvbWFpbG1hbi9saXN0aW5mby9saW51eC1hcm0ta2Vy
-bmVsCg==
\ No newline at end of file
+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
+> 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
+> 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 
+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.
+
+Cheers,
+Ben.
+
+
+_______________________________________________
+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
diff --git a/a/content_digest b/N1/content_digest
index fab2676..ba7a0e3 100644
--- a/a/content_digest
+++ b/N1/content_digest
@@ -49,30 +49,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.yu>\0"
 ]
 [
   "\0000:1\0"
@@ -81,34 +58,43 @@
   "b\0"
 ]
 [
-  "T24gV2VkLCAyMDE3LTA0LTEyIGF0IDEyOjMxICswMTAwLCBSdXNzZWxsIEtpbmcgLSBBUk0gTGlu\n",
-  "dXggd3JvdGU6Cj4gZGVmYXVsdCBpbXBsZW1lbnRhdGlvbiBzaG91bGQgZmFpbCBpZiBpdCdzIG5v\n",
-  "dCBzdXBwb3J0YWJsZSBvbiBhbGwKPiBhcmNoaXRlY3R1cmVzLsKgIEhvd2V2ZXIsIHdoZW4gd2Ug\n",
-  "aGF2ZSBleGlzdGluZyBkcml2ZXJzIHVzaW5nIGFuCj4gaW50ZXJmYWNlIHRoYXQgZG9lc24ndCBw\n",
-  "cm92aWRlIHRoZSBzZW1hbnRpY3MgdGhleSBhbHJlYWR5IHJlcXVpcmUsCj4gdGhlbiBpdCBtYWtl\n",
-  "cyBubyBzZW5zZSB0byBlZmZlY3RpdmVseSBicmVhayB0aGVzZSBkcml2ZXJzIG9uIGEgcmFuZ2UK\n",
-  "PiBvZiBleGlzdGluZyBhcmNoaXRlY3R1cmVzLgo+IAo+IFRoZSBxdWVzdGlvbiByZWFsbHkgaXMg\n",
-  "LSB3aGF0J3MgdGhlIGJlc3Qgd2F5IHRvIHNvbHZlIHRoZSBwcm9ibGVtCj4gd2l0aAo+IGV4aXN0\n",
-  "aW5nIGRyaXZlcnMgd2l0aG91dCBicmVha2luZyB0aGVtLsKgIEkgc3VzcGVjdCB0aGF0LCBzYWRs\n",
-  "eSwgdGhlCj4gb25seSByZWFsaXN0aWMgd2F5IGZvcndhcmQgaGVyZSBpcyB2aWEgdGhlIGxpdHRl\n",
-  "ci1kcml2ZXJzLXdpdGgtaWZkZWZzCj4gYXBwcm9hY2ggc2luY2UgeW91IGRvbid0IGxpa2UgcHJv\n",
-  "dmlkaW5nIGEgZGVmYXVsdCBpbXBsZW1lbnRhdGlvbiB0aGF0Cj4gaXMgY29tcGF0aWJsZSB3aXRo\n",
-  "IHdoYXQgdGhlc2UgZHJpdmVycyBhcmUgYWxyZWFkeSBkb2luZy4KClRoZW4gbWFrZSBpb3JlbWFw\n",
-  "X25vcG9zdCByZXR1cm4gTlVMTCB3aGVuIHRoZSBhcmNoIGRvZXNuJ3QgaGF2ZSAKdGhlIHJpZ2h0\n",
-  "IHNlbWFudGljLgoKVGhlIGRyaXZlciB0aGFuIGNhbiAqY2hvc2UqIHRvIGVpdGhlciBzaWxlbnRs\n",
-  "eSBmYWxsYmFjayB0byBpb3JlbWFwLAp3aGljaCBoYXMgc2VydmVkIHVzIHdlbGwgZm9yIGEgbG9u\n",
-  "ZyB0aW1lIGRlc3BpdGUgYmVpbmcgdGhlb3JpY2FsbHkgaW4KdmlvbGF0aW9uIG9mIHRoZSBzcGVj\n",
-  "LCBvciBkbyBmdW5ueSB0aGluZ3MgbGlrZSByZWFkIGJhY2sgc29tZSByZWdpc3RlcgphZnRlciBl\n",
-  "dmVyeSBjb25maWcgd3JpdGUgdG8gZW5zdXJlIG9yZGVyaW5nIGV0Yy4uLgoKSSBtdWNoIHByZWZl\n",
-  "ciB0aGF0IGFwcHJvYWNoIHRoYW4gaGF2aW5nIHNvbWUgZ2VuZXJpYyBpb3JlbWFwIGZ1bmN0aW9u\n",
-  "CnRoYXQgZXhwb3NlcyBhIHNlbWFudGljIHRoYXQgc2lsZW50bHkgcHJvdmlkZXMgYSB3ZWFrZXIg\n",
-  "b25lIG9uIHNvbWUKYXJjaGl0ZWN0dXJlLgoKQXQgbGVhc3Qgd2UgbWFrZSB0aGUgZmFpbHVyZSBl\n",
-  "eHBsaWNpdCwgYW5kIHRoZSBkcml2ZXIgY2FuIHRha2UKYWx0ZXJuYXRlIChwb3NzaWJseSBzdWIt\n",
-  "b3B0aW1hbCkgYWN0aW9uIGlmIGl0IGNob29zZXMgdG8gZG8gc28uCgpDaGVlcnMsCkJlbi4KCgpf\n",
-  "X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpsaW51eC1hcm0t\n",
-  "a2VybmVsIG1haWxpbmcgbGlzdApsaW51eC1hcm0ta2VybmVsQGxpc3RzLmluZnJhZGVhZC5vcmcK\n",
-  "aHR0cDovL2xpc3RzLmluZnJhZGVhZC5vcmcvbWFpbG1hbi9saXN0aW5mby9saW51eC1hcm0ta2Vy\n",
-  "bmVsCg=="
+  "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",
+  "> 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",
+  "> 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",
+  "> 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",
+  "the right semantic.\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",
+  "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",
+  "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",
+  "Cheers,\n",
+  "Ben.\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"
 ]
 
-e2d71e53c63578fff6b13a0f826a3928ad7a2930118ccf84079cecc08a448e89
+b04edaf58a924edac0833da6861de0c7e9ed343b99371fcd7c3ebf2d76251653
