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

diff --git a/a/1.txt b/N1/1.txt
index 6810d61..f645c1d 100644
--- a/a/1.txt
+++ b/N1/1.txt
@@ -1,60 +1,76 @@
-T24gV2VkLCAyMDE3LTA0LTEyIGF0IDIzOjQ1ICswMTAwLCBSdXNzZWxsIEtpbmcgLSBBUk0gTGlu
-dXggd3JvdGU6Cj4gT24gVGh1LCBBcHIgMTMsIDIwMTcgYXQgMDg6MzA6NDBBTSArMTAwMCwgQmVu
-amFtaW4gSGVycmVuc2NobWlkdCB3cm90ZToKPiA+IE15IHBvaW50IHdpdGggbm9wb3N0KCkgaXMg
-dGhhdCBpdCdzIG5ldmVyIG9rIHRvIHNpbGVudGx5IGRvd25ncmFkZSBpdC4KPiA+IENvZGUgd3Jp
-dHRlbiB3aXRoIHRoZSBhc3N1bXB0aW9uIHRoYXQgdGhlcmUgaXMgbm8gcG9zdGluZyB3aWxsIGJl
-Cj4gPiAqaW5jb3JyZWN0KiBpZiBwb3N0aW5nIGhhcHBlbnMuIFdlIGRvIGxpdmUgd2l0aCB0aGF0
-ICJidWciIHRvZGF5IGluZGVlZAo+ID4gYnV0IG9uY2Ugd2UgaGF2ZSB0aGF0IGFjY2Vzc29ycyB3
-ZSBtaWdodCBzdGFydCBncm93aW5nIG1vcmUgY29kZSB0aGF0Cj4gPiByZWxpZXMgb24gdGhlIHNw
-ZWNpZmljIGF0dHJpYnV0ZSB0aGF0IHRoaW5ncyBhcmVuJ3QgcG9zdGVkIGFuZCB3aWxsIGJlCj4g
-PiB3cm9uZyBvbiBhbGwgdGhlIGFyY2hzIHByb3ZpZGluZyB0aGUgZGVmYXVsdCBpbXBsZW1lbnRh
-dGlvbi4KPiA+IAo+ID4gVGhpcyBpcyB3aHkgSSBpbnNpc3QgdGhhdCBwZ3Byb3Rfbm9wb3N0KCkg
-aWYgaXQgZXhpc3RzIGdsb2JhbGx5LCBzaG91bGQKPiA+IHJldHVybiBOVUxMIHdoZW4gdGhlIHNl
-bWFudGljIGNhbm5vdCBiZSBwcm92aWRlZC4KPiAKPiBOb3cgeW91J3JlIG5vdCB0YWxraW5nIHNl
-bnNlLsKgwqBwZ3Byb3Rfbm9wb3N0KCkgZG9lcyBfbm90XyByZXR1cm4gYSBwb2ludGVyLgo+IFlv
-dSdyZSB0YWxraW5nIGhlcmUgYXMgaWYgeW91J3JlIHN0aWxsIHRhbGtpbmcgYWJvdXQgaW9yZW1h
-cF9ub3Bvc3QoKS4KPiBTbywgSSB0aGluayB5b3UncmUgY29uZnVzZWQuCgpOYWgsIGp1c3QgInR5
-cG8iLCBJIG1lYW50IGlvcmVtYXBfbm9wb3N0LgoKPiA+ID4gPiBKdXN0IGxpa2UgdGhlIHByb3Bv
-c2VkIGlvcmVtYXBfbm9wb3N0KCksIHBncHJvdF9ub25wb3N0ZWQoKSBpcyBnaXZlbiBhCj4gPiA+
-ID4gZGVmYXVsdCBpbXBsZW1lbnRhdGlvbiB0aGF0IHVzZXMgcGdwcm90X25vbmNhY2hlZCgpLsKg
-IE1heWJlIHdlIHNob3VsZAo+ID4gPiA+IGFsc28gbWFrZSBwY2lfcmVtYXBfaW9zcGFjZSgpIGZh
-aWwgaWYgcGdwcm90X25vbnBvc3RlZCgpIGlzIG5vdCBkZWZpbmVkCj4gPiA+ID4gYnkgdGhlIGFy
-Y2hpdGVjdHVyZT8KPiA+IAo+ID4gT3Igd2UgKmRvY3VtZW50KiB0aGF0IG1tYXAgb2YgSU8gc3Bh
-Y2UgY2FuIHJlc3VsdCBpbiBzb21ldGhpbmcgdGhhdCBpcwo+ID4gcGFydGlhbGx5IG5vbi1wb3N0
-ZWQuCj4gCj4gT2gsIHNvIHdlIF9jYW5fIHByb3ZpZGUgYW4gaW50ZXJmYWNlIHRoYXQgaGFzIHdl
-YWtlciBzZW1hbnRpY3MgdGhhbiBpdAo+IHNob3VsZCBwcm92aWRlZCB3ZSBkb2N1bWVudCBpdC4K
-PiAKPiBJdCdzIGluc2FuZSB0byBoYXZlIGRpZmZlcmVudCBiZWhhdmlvdXJzIGZyb20gdGhlc2Ug
-dHdvIGludGVyZmFjZXMsIHlldAo+IHlvdSBzZWVtIHRvIGhhdmUgc2FpZCBleGFjdGx5IHRoYXQg
-aW4geW91ciByZXBseS4KPgo+IEl0J3MgYWN0dWFsbHkgd29yc2UgdGhhbiB0aGF0IC0gd2hhdCB5
-b3UndmUganVzdCBzYWlkIGlzIHRoYXQgaXQncyBva2F5Cj4gZm9yIHVzZXJzcGFjZSB0byBtYXAg
-SU8gc3BhY2Ugd2l0aCB3ZWFrZXIgc2VtYW50aWNzIHRoYW4gdGhlIFBDSQo+IHNwZWNpZmljYXRp
-b24gc3RhdGVzLCBidXQgaXQncyBub3Qgb2theSBmb3Iga2VybmVsIHNwYWNlIHRvIGRvIHRoYXQu
-CgpUaGF0IGlzIG5vdCB3aGF0IEknbSBzYXlpbmcuIFdoYXQgSSdtIHNheWluZyBpcyB0aGF0IGl0
-J3Mgbm90IG9rIHRvCnByb3ZpZGUgYSBnZW5lcmljIG1hcHBpbmcgYXR0cmlidXRlIHRoYXQgc2ls
-ZW50bHkgaGFwcGVucyB0byBiZSB3ZWFrZXIKdGhhbiBkb2N1bWVudGVkIG9uIHNvbWUgYXJjaGl0
-ZWN0dXJlcy4KClRoZSBQQ0kgcGFydCBpcyBvcnRob2dvbmFsLiBIb3cgZG8geW91IGhhbmRsZSBQ
-Q0kgaW4gYWJzZW5jZSBvZiB0aGF0CmF0dHJpYnV0ZSBpcyBhIHNlcGFyYXRlIHByb2JsZW0gKHdo
-aWNoIGlzIHByb2JhYmx5IGEgbWF0dGVyIG9mIGp1c3QKZG9jdW1lbnRpbmcgdGhpbmdzKS4KCkJU
-Vy4gSXMgY29uZmlnIHNwYWNlIGFsc28gbm9uLXBvc3RlZCBvbiBJbnRlbCB3aXRoIG1tY29uZmln
-ID8gSSBkaWRuJ3QKdGhpbmsgdGhleSBjb3VsZCBkbyBub24gcG9zdGVkIE1NSU8gc3RvcmVzLCBi
-dXQgbWF5YmUgSSdtIHdyb25nLgoKPiBFc3BlY2lhbGx5IGFzIHVzZXJzcGFjZSBjYW4ndCBrbm93
-IHdoYXQgc2VtYW50aWNzIGl0cyBnb2luZyB0byBlbmQgdXAKPiB3aXRoLCB0aGlzIHNlZW1zIHRv
-IGJlIGEgdmVyeSBzdHJhbmdlIHN0YW5jZSB0byB0YWtlLgoKVGhhdCdzIHdoeSB3ZSBkb2N1bWVu
-dCB0aGF0IHRoZSB1c2Vyc3BhY2UgaW50ZXJmYWNlIGZvciAqUENJKiBpcwpyZWxheGVkLgoKPiBJ
-J2Qgc2F5IHRoYXQgaWYgd2UgY2FuJ3Qgb2ZmZXIgdGhlIG5vLXBvc3RpbmcgYmVoYXZpb3VyIHRo
-YXQgUENJCj4gc3BlY2lmaWVzLCB0aGVuIHdlIHNob3VsZG4ndCBiZSBleHBvc2luZyBJTyBtYXBw
-aW5ncyB0byB1c2Vyc3BhY2UuCgpJIHN0cm9uZ2x5IGRpc2FncmVlLiBXZSd2ZSBiZWVuIGRvaW5n
-IGl0IGZvciBkZWNhZGVzIGFuZCBpdCB3b3JrcwpmaW5lIGluIHByZXR0eSBtdWNoIGFsbCBjYXNl
-cy4KCk5vdGUgYWxzbyB0aGF0IHNvbWUgcGxhdGZvcm1zIChpbmNsdWRpbmcgc29tZSBwb3dlcnBj
-IGFmYWlrKSBkbyBwcm92aWRlCnRoZSBub24tcG9zdGVkIGJlaGF2aW91ciwgc2ltcGx5IG5vdCBh
-cyBhIG1hcHBpbmcgYXR0cmlidXRlLiBJbnRlcm5hbApmYWJyaWNzIGFyZW4ndCBuZWNlc3Nhcmls
-eSBkb2luZyBwb3N0ZWQgd3JpdGVzIGFuZCBzb21lIGJyaWRnZXMgd2lsbApob2xkIHRoZSByZXNw
-b25zZSBmb3Igbm9uLXBvc3RlZCByZXF1ZXN0cy4KCkFueXdheSwgSSBkb24ndCBvYmplY3QgdG8g
-dHJ5aW5nIHRvIGltcHJvdmUgY29tcGxpYW5jZSB3aXRoIHRoZSBzcGVjCm9uIGFyY2ggdGhhdCBo
-YXZlIHN1Y2ggYSBtYXBwaW5nIGF0dHJpYnV0ZS4gQnV0IEkgZG8gb2JqZWN0IHRvIGhhdmluZwph
-IGdlbmVyaWMgbWFwcGluZyBhdHRyaWJ1dGUgKHRoYXQgaXNuJ3QgZnVuZGFtZW50YWxseSBhIFBD
-SSB0aGluZykgdGhhdApzaWxlbnRseSBkb3duZ3JhZGVzIHRvIHNvbWV0aGluZyB3ZWFrZXIuCgpC
-ZW4uCgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KbGlu
-dXgtYXJtLWtlcm5lbCBtYWlsaW5nIGxpc3QKbGludXgtYXJtLWtlcm5lbEBsaXN0cy5pbmZyYWRl
-YWQub3JnCmh0dHA6Ly9saXN0cy5pbmZyYWRlYWQub3JnL21haWxtYW4vbGlzdGluZm8vbGludXgt
-YXJtLWtlcm5lbAo=
\ No newline at end of file
+On Wed, 2017-04-12 at 23:45 +0100, Russell King - ARM Linux 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
+> > 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
+> > return NULL when the semantic cannot be provided.
+> 
+> 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 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).
+
+BTW. Is config space also non-posted on Intel with mmconfig ? I didn't
+think they could do non posted MMIO stores, but maybe I'm wrong.
+
+> Especially as userspace can't know what semantics its going to end up
+> with, this seems to be a very strange stance to take.
+
+That's why we document that the userspace interface for *PCI* is
+relaxed.
+
+> I'd say that if we can't offer the no-posting behaviour that PCI
+> specifies, then we shouldn't be exposing IO mappings to userspace.
+
+I strongly disagree. We've been doing it for decades and it works
+fine in pretty much all cases.
+
+Note also that some platforms (including some powerpc afaik) do provide
+the non-posted behaviour, simply not as a mapping attribute. Internal
+fabrics aren't necessarily doing posted writes and some bridges will
+hold the response for non-posted requests.
+
+Anyway, I don't object to trying to improve compliance with the spec
+on arch that have such a mapping attribute. But I do object to having
+a generic mapping attribute (that isn't fundamentally a PCI thing) that
+silently downgrades to something weaker.
+
+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 257b76a..c1e01cc 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.yu>\0"
 ]
 [
   "\0000:1\0"
@@ -96,66 +73,82 @@
   "b\0"
 ]
 [
-  "T24gV2VkLCAyMDE3LTA0LTEyIGF0IDIzOjQ1ICswMTAwLCBSdXNzZWxsIEtpbmcgLSBBUk0gTGlu\n",
-  "dXggd3JvdGU6Cj4gT24gVGh1LCBBcHIgMTMsIDIwMTcgYXQgMDg6MzA6NDBBTSArMTAwMCwgQmVu\n",
-  "amFtaW4gSGVycmVuc2NobWlkdCB3cm90ZToKPiA+IE15IHBvaW50IHdpdGggbm9wb3N0KCkgaXMg\n",
-  "dGhhdCBpdCdzIG5ldmVyIG9rIHRvIHNpbGVudGx5IGRvd25ncmFkZSBpdC4KPiA+IENvZGUgd3Jp\n",
-  "dHRlbiB3aXRoIHRoZSBhc3N1bXB0aW9uIHRoYXQgdGhlcmUgaXMgbm8gcG9zdGluZyB3aWxsIGJl\n",
-  "Cj4gPiAqaW5jb3JyZWN0KiBpZiBwb3N0aW5nIGhhcHBlbnMuIFdlIGRvIGxpdmUgd2l0aCB0aGF0\n",
-  "ICJidWciIHRvZGF5IGluZGVlZAo+ID4gYnV0IG9uY2Ugd2UgaGF2ZSB0aGF0IGFjY2Vzc29ycyB3\n",
-  "ZSBtaWdodCBzdGFydCBncm93aW5nIG1vcmUgY29kZSB0aGF0Cj4gPiByZWxpZXMgb24gdGhlIHNw\n",
-  "ZWNpZmljIGF0dHJpYnV0ZSB0aGF0IHRoaW5ncyBhcmVuJ3QgcG9zdGVkIGFuZCB3aWxsIGJlCj4g\n",
-  "PiB3cm9uZyBvbiBhbGwgdGhlIGFyY2hzIHByb3ZpZGluZyB0aGUgZGVmYXVsdCBpbXBsZW1lbnRh\n",
-  "dGlvbi4KPiA+IAo+ID4gVGhpcyBpcyB3aHkgSSBpbnNpc3QgdGhhdCBwZ3Byb3Rfbm9wb3N0KCkg\n",
-  "aWYgaXQgZXhpc3RzIGdsb2JhbGx5LCBzaG91bGQKPiA+IHJldHVybiBOVUxMIHdoZW4gdGhlIHNl\n",
-  "bWFudGljIGNhbm5vdCBiZSBwcm92aWRlZC4KPiAKPiBOb3cgeW91J3JlIG5vdCB0YWxraW5nIHNl\n",
-  "bnNlLsKgwqBwZ3Byb3Rfbm9wb3N0KCkgZG9lcyBfbm90XyByZXR1cm4gYSBwb2ludGVyLgo+IFlv\n",
-  "dSdyZSB0YWxraW5nIGhlcmUgYXMgaWYgeW91J3JlIHN0aWxsIHRhbGtpbmcgYWJvdXQgaW9yZW1h\n",
-  "cF9ub3Bvc3QoKS4KPiBTbywgSSB0aGluayB5b3UncmUgY29uZnVzZWQuCgpOYWgsIGp1c3QgInR5\n",
-  "cG8iLCBJIG1lYW50IGlvcmVtYXBfbm9wb3N0LgoKPiA+ID4gPiBKdXN0IGxpa2UgdGhlIHByb3Bv\n",
-  "c2VkIGlvcmVtYXBfbm9wb3N0KCksIHBncHJvdF9ub25wb3N0ZWQoKSBpcyBnaXZlbiBhCj4gPiA+\n",
-  "ID4gZGVmYXVsdCBpbXBsZW1lbnRhdGlvbiB0aGF0IHVzZXMgcGdwcm90X25vbmNhY2hlZCgpLsKg\n",
-  "IE1heWJlIHdlIHNob3VsZAo+ID4gPiA+IGFsc28gbWFrZSBwY2lfcmVtYXBfaW9zcGFjZSgpIGZh\n",
-  "aWwgaWYgcGdwcm90X25vbnBvc3RlZCgpIGlzIG5vdCBkZWZpbmVkCj4gPiA+ID4gYnkgdGhlIGFy\n",
-  "Y2hpdGVjdHVyZT8KPiA+IAo+ID4gT3Igd2UgKmRvY3VtZW50KiB0aGF0IG1tYXAgb2YgSU8gc3Bh\n",
-  "Y2UgY2FuIHJlc3VsdCBpbiBzb21ldGhpbmcgdGhhdCBpcwo+ID4gcGFydGlhbGx5IG5vbi1wb3N0\n",
-  "ZWQuCj4gCj4gT2gsIHNvIHdlIF9jYW5fIHByb3ZpZGUgYW4gaW50ZXJmYWNlIHRoYXQgaGFzIHdl\n",
-  "YWtlciBzZW1hbnRpY3MgdGhhbiBpdAo+IHNob3VsZCBwcm92aWRlZCB3ZSBkb2N1bWVudCBpdC4K\n",
-  "PiAKPiBJdCdzIGluc2FuZSB0byBoYXZlIGRpZmZlcmVudCBiZWhhdmlvdXJzIGZyb20gdGhlc2Ug\n",
-  "dHdvIGludGVyZmFjZXMsIHlldAo+IHlvdSBzZWVtIHRvIGhhdmUgc2FpZCBleGFjdGx5IHRoYXQg\n",
-  "aW4geW91ciByZXBseS4KPgo+IEl0J3MgYWN0dWFsbHkgd29yc2UgdGhhbiB0aGF0IC0gd2hhdCB5\n",
-  "b3UndmUganVzdCBzYWlkIGlzIHRoYXQgaXQncyBva2F5Cj4gZm9yIHVzZXJzcGFjZSB0byBtYXAg\n",
-  "SU8gc3BhY2Ugd2l0aCB3ZWFrZXIgc2VtYW50aWNzIHRoYW4gdGhlIFBDSQo+IHNwZWNpZmljYXRp\n",
-  "b24gc3RhdGVzLCBidXQgaXQncyBub3Qgb2theSBmb3Iga2VybmVsIHNwYWNlIHRvIGRvIHRoYXQu\n",
-  "CgpUaGF0IGlzIG5vdCB3aGF0IEknbSBzYXlpbmcuIFdoYXQgSSdtIHNheWluZyBpcyB0aGF0IGl0\n",
-  "J3Mgbm90IG9rIHRvCnByb3ZpZGUgYSBnZW5lcmljIG1hcHBpbmcgYXR0cmlidXRlIHRoYXQgc2ls\n",
-  "ZW50bHkgaGFwcGVucyB0byBiZSB3ZWFrZXIKdGhhbiBkb2N1bWVudGVkIG9uIHNvbWUgYXJjaGl0\n",
-  "ZWN0dXJlcy4KClRoZSBQQ0kgcGFydCBpcyBvcnRob2dvbmFsLiBIb3cgZG8geW91IGhhbmRsZSBQ\n",
-  "Q0kgaW4gYWJzZW5jZSBvZiB0aGF0CmF0dHJpYnV0ZSBpcyBhIHNlcGFyYXRlIHByb2JsZW0gKHdo\n",
-  "aWNoIGlzIHByb2JhYmx5IGEgbWF0dGVyIG9mIGp1c3QKZG9jdW1lbnRpbmcgdGhpbmdzKS4KCkJU\n",
-  "Vy4gSXMgY29uZmlnIHNwYWNlIGFsc28gbm9uLXBvc3RlZCBvbiBJbnRlbCB3aXRoIG1tY29uZmln\n",
-  "ID8gSSBkaWRuJ3QKdGhpbmsgdGhleSBjb3VsZCBkbyBub24gcG9zdGVkIE1NSU8gc3RvcmVzLCBi\n",
-  "dXQgbWF5YmUgSSdtIHdyb25nLgoKPiBFc3BlY2lhbGx5IGFzIHVzZXJzcGFjZSBjYW4ndCBrbm93\n",
-  "IHdoYXQgc2VtYW50aWNzIGl0cyBnb2luZyB0byBlbmQgdXAKPiB3aXRoLCB0aGlzIHNlZW1zIHRv\n",
-  "IGJlIGEgdmVyeSBzdHJhbmdlIHN0YW5jZSB0byB0YWtlLgoKVGhhdCdzIHdoeSB3ZSBkb2N1bWVu\n",
-  "dCB0aGF0IHRoZSB1c2Vyc3BhY2UgaW50ZXJmYWNlIGZvciAqUENJKiBpcwpyZWxheGVkLgoKPiBJ\n",
-  "J2Qgc2F5IHRoYXQgaWYgd2UgY2FuJ3Qgb2ZmZXIgdGhlIG5vLXBvc3RpbmcgYmVoYXZpb3VyIHRo\n",
-  "YXQgUENJCj4gc3BlY2lmaWVzLCB0aGVuIHdlIHNob3VsZG4ndCBiZSBleHBvc2luZyBJTyBtYXBw\n",
-  "aW5ncyB0byB1c2Vyc3BhY2UuCgpJIHN0cm9uZ2x5IGRpc2FncmVlLiBXZSd2ZSBiZWVuIGRvaW5n\n",
-  "IGl0IGZvciBkZWNhZGVzIGFuZCBpdCB3b3JrcwpmaW5lIGluIHByZXR0eSBtdWNoIGFsbCBjYXNl\n",
-  "cy4KCk5vdGUgYWxzbyB0aGF0IHNvbWUgcGxhdGZvcm1zIChpbmNsdWRpbmcgc29tZSBwb3dlcnBj\n",
-  "IGFmYWlrKSBkbyBwcm92aWRlCnRoZSBub24tcG9zdGVkIGJlaGF2aW91ciwgc2ltcGx5IG5vdCBh\n",
-  "cyBhIG1hcHBpbmcgYXR0cmlidXRlLiBJbnRlcm5hbApmYWJyaWNzIGFyZW4ndCBuZWNlc3Nhcmls\n",
-  "eSBkb2luZyBwb3N0ZWQgd3JpdGVzIGFuZCBzb21lIGJyaWRnZXMgd2lsbApob2xkIHRoZSByZXNw\n",
-  "b25zZSBmb3Igbm9uLXBvc3RlZCByZXF1ZXN0cy4KCkFueXdheSwgSSBkb24ndCBvYmplY3QgdG8g\n",
-  "dHJ5aW5nIHRvIGltcHJvdmUgY29tcGxpYW5jZSB3aXRoIHRoZSBzcGVjCm9uIGFyY2ggdGhhdCBo\n",
-  "YXZlIHN1Y2ggYSBtYXBwaW5nIGF0dHJpYnV0ZS4gQnV0IEkgZG8gb2JqZWN0IHRvIGhhdmluZwph\n",
-  "IGdlbmVyaWMgbWFwcGluZyBhdHRyaWJ1dGUgKHRoYXQgaXNuJ3QgZnVuZGFtZW50YWxseSBhIFBD\n",
-  "SSB0aGluZykgdGhhdApzaWxlbnRseSBkb3duZ3JhZGVzIHRvIHNvbWV0aGluZyB3ZWFrZXIuCgpC\n",
-  "ZW4uCgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KbGlu\n",
-  "dXgtYXJtLWtlcm5lbCBtYWlsaW5nIGxpc3QKbGludXgtYXJtLWtlcm5lbEBsaXN0cy5pbmZyYWRl\n",
-  "YWQub3JnCmh0dHA6Ly9saXN0cy5pbmZyYWRlYWQub3JnL21haWxtYW4vbGlzdGluZm8vbGludXgt\n",
-  "YXJtLWtlcm5lbAo="
+  "On Wed, 2017-04-12 at 23:45 +0100, Russell King - ARM Linux wrote:\n",
+  "> 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",
+  "> > 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",
+  "> > 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",
+  "> You're talking here as if you're still talking about ioremap_nopost().\n",
+  "> So, I think you're confused.\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",
+  "> > > > by the architecture?\n",
+  "> > \n",
+  "> > Or we *document* that mmap of IO space can result in something that is\n",
+  "> > partially non-posted.\n",
+  "> \n",
+  "> Oh, so we _can_ provide an interface that has weaker semantics than it\n",
+  "> should provided we document it.\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",
+  "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",
+  "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",
+  "\n",
+  "BTW. Is config space also non-posted on Intel with mmconfig ? I didn't\n",
+  "think they could do non posted MMIO stores, but maybe I'm wrong.\n",
+  "\n",
+  "> Especially as userspace can't know what semantics its going to end up\n",
+  "> with, this seems to be a very strange stance to take.\n",
+  "\n",
+  "That's why we document that the userspace interface for *PCI* is\n",
+  "relaxed.\n",
+  "\n",
+  "> I'd say that if we can't offer the no-posting behaviour that PCI\n",
+  "> specifies, then we shouldn't be exposing IO mappings to userspace.\n",
+  "\n",
+  "I strongly disagree. We've been doing it for decades and it works\n",
+  "fine in pretty much all cases.\n",
+  "\n",
+  "Note also that some platforms (including some powerpc afaik) do provide\n",
+  "the non-posted behaviour, simply not as a mapping attribute. Internal\n",
+  "fabrics aren't necessarily doing posted writes and some bridges will\n",
+  "hold the response for non-posted requests.\n",
+  "\n",
+  "Anyway, I don't object to trying to improve compliance with the spec\n",
+  "on arch that have such a mapping attribute. But I do object to having\n",
+  "a generic mapping attribute (that isn't fundamentally a PCI thing) that\n",
+  "silently downgrades to something weaker.\n",
+  "\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"
 ]
 
-425f06f19f45116de3379654c4cc84631de7c332e30bbae567c4097772b5678b
+d8db22d9d85141428d135bb90c16100a079510cab5bcc6f61f30abc263a36003
