From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Russell King - ARM Linux <linux@armlinux.org.uk>
Cc: Jonas Bonn <jonas@southpole.se>, Rich Felker <dalias@libc.org>,
linux-pci@vger.kernel.org, Will Deacon <will.deacon@arm.com>,
David Howells <dhowells@redhat.com>,
Max Filippov <jcmvbkbc@gmail.com>,
Paul Mackerras <paulus@samba.org>,
Huacai Chen <chenhc@lemote.com>,
Guan Xuetao <gxt@mprc.pku.edu.cn>,
Thomas Gleixner <tglx@linutronix.de>,
Hans-Christian Egtvedt <egtvedt@samfundet.no>,
linux-arch@vger.kernel.org,
Jesper Nilsson <jesper.nilsson@axis.com>,
Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>,
Yoshinori Sato <ysato@users.sourceforge.jp>,
Michael Ellerman <mpe@ellerman.id.au>,
Helge Deller <deller@gmx.de>,
"James E.J. Bottomley" <jejb@parisc-linux.org>,
Ingo Molnar <mingo@redhat.com>,
Geert Uytterhoeven <geert@linux-m68k.org>,
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>
Subject: Re: [PATCH v3 00/32] PCI: fix config and I/O Address space memory mappings
Date: Thu, 13 Apr 2017 10:53:00 +1000 [thread overview]
Message-ID: <1492044780.7236.87.camel@kernel.crashing.org> (raw)
In-Reply-To: <20170412224555.GB17774@n2100.armlinux.org.uk>
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=
WARNING: multiple messages have this Message-ID (diff)
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Russell King - ARM Linux <linux@armlinux.org.uk>
Cc: Jonas Bonn <jonas@southpole.se>, Rich Felker <dalias@libc.org>,
linux-pci@vger.kernel.org, Will Deacon <will.deacon@arm.com>,
David Howells <dhowells@redhat.com>,
Max Filippov <jcmvbkbc@gmail.com>,
Paul Mackerras <paulus@samba.org>,
Huacai Chen <chenhc@lemote.com>,
Guan Xuetao <gxt@mprc.pku.edu.cn>,
Thomas Gleixner <tglx@linutronix.de>,
Hans-Christian Egtvedt <egtvedt@samfundet.no>,
linux-arch@vger.kernel.org,
Jesper Nilsson <jesper.nilsson@axis.com>,
Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>,
Yoshinori Sato <ysato@users.sourceforge.jp>,
Michael Ellerman <mpe@ellerman.id.au>,
Helge Deller <deller@gmx.de>,
"James E.J. Bottomley" <jejb@parisc-linux.org>,
Ingo Molnar <mingo@redhat.com>,
Geert Uytterhoeven <geert@linux-m68k.org>,
Catalin Marinas <catalin.marinas@arm.com>,
Matt Turner <mattst88@gmail.com>,
Haavard Skinnemoen <hskinnemoen@gmail.com>,
Fenghua Yu <fenghua.yu>
Subject: Re: [PATCH v3 00/32] PCI: fix config and I/O Address space memory mappings
Date: Thu, 13 Apr 2017 10:53:00 +1000 [thread overview]
Message-ID: <1492044780.7236.87.camel@kernel.crashing.org> (raw)
In-Reply-To: <20170412224555.GB17774@n2100.armlinux.org.uk>
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
WARNING: multiple messages have this Message-ID (diff)
From: benh@kernel.crashing.org (Benjamin Herrenschmidt)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v3 00/32] PCI: fix config and I/O Address space memory mappings
Date: Thu, 13 Apr 2017 10:53:00 +1000 [thread overview]
Message-ID: <1492044780.7236.87.camel@kernel.crashing.org> (raw)
In-Reply-To: <20170412224555.GB17774@n2100.armlinux.org.uk>
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.
next prev parent reply other threads:[~2017-04-13 0:53 UTC|newest]
Thread overview: 171+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-04-11 12:28 [PATCH v3 00/32] PCI: fix config and I/O Address space memory mappings Lorenzo Pieralisi
2017-04-11 12:28 ` Lorenzo Pieralisi
2017-04-11 12:28 ` Lorenzo Pieralisi
2017-04-11 12:28 ` [PATCH v3 01/32] PCI: remove __weak tag from pci_remap_iospace() Lorenzo Pieralisi
2017-04-11 12:28 ` Lorenzo Pieralisi
2017-04-11 12:28 ` Lorenzo Pieralisi
2017-04-11 12:28 ` [PATCH v3 02/32] asm-generic/pgtable.h: introduce pgprot_nonposted remap attribute Lorenzo Pieralisi
2017-04-11 12:28 ` Lorenzo Pieralisi
2017-04-11 12:28 ` Lorenzo Pieralisi
2017-04-11 12:28 ` [PATCH v3 03/32] PCI: fix pci_remap_iospace() " Lorenzo Pieralisi
2017-04-11 12:28 ` Lorenzo Pieralisi
2017-04-11 12:28 ` Lorenzo Pieralisi
2017-04-11 12:28 ` [PATCH v3 04/32] asm-generic: add ioremap_nopost() remap interface Lorenzo Pieralisi
2017-04-11 12:28 ` Lorenzo Pieralisi
2017-04-11 12:28 ` Lorenzo Pieralisi
2017-04-11 13:39 ` Benjamin Herrenschmidt
2017-04-11 13:39 ` Benjamin Herrenschmidt
2017-04-11 13:39 ` Benjamin Herrenschmidt
2017-04-11 14:31 ` Lorenzo Pieralisi
2017-04-11 14:31 ` Lorenzo Pieralisi
2017-04-11 14:31 ` Lorenzo Pieralisi
2017-04-11 23:14 ` Benjamin Herrenschmidt
2017-04-11 23:14 ` Benjamin Herrenschmidt
2017-04-11 23:14 ` Benjamin Herrenschmidt
2017-04-12 10:00 ` Lorenzo Pieralisi
2017-04-12 10:00 ` Lorenzo Pieralisi
2017-04-12 10:00 ` Lorenzo Pieralisi
2017-04-12 11:20 ` Russell King - ARM Linux
2017-04-12 11:20 ` Russell King - ARM Linux
2017-04-12 11:20 ` Russell King - ARM Linux
2017-04-18 15:49 ` Lorenzo Pieralisi
2017-04-18 15:49 ` Lorenzo Pieralisi
2017-04-18 15:49 ` Lorenzo Pieralisi
2017-04-18 16:31 ` Bjorn Helgaas
2017-04-18 16:31 ` Bjorn Helgaas
2017-04-18 16:31 ` Bjorn Helgaas
2017-04-18 22:43 ` Benjamin Herrenschmidt
2017-04-18 22:43 ` Benjamin Herrenschmidt
2017-04-18 22:43 ` Benjamin Herrenschmidt
2017-04-11 12:28 ` [PATCH v3 05/32] alpha: include default ioremap_nopost() implementation Lorenzo Pieralisi
2017-04-11 12:28 ` Lorenzo Pieralisi
2017-04-11 12:28 ` [PATCH v3 06/32] avr32: " Lorenzo Pieralisi
2017-04-11 12:28 ` Lorenzo Pieralisi
2017-04-11 13:55 ` Nicolas Ferre
2017-04-11 13:55 ` Nicolas Ferre
2017-04-11 13:55 ` Nicolas Ferre
2017-04-11 13:55 ` Nicolas Ferre
2017-04-11 12:28 ` [PATCH v3 07/32] arc: " Lorenzo Pieralisi
2017-04-11 12:28 ` Lorenzo Pieralisi
2017-04-11 12:28 ` [PATCH v3 08/32] cris: " Lorenzo Pieralisi
2017-04-11 12:28 ` Lorenzo Pieralisi
2017-04-11 13:15 ` Jesper Nilsson
2017-04-11 13:15 ` Jesper Nilsson
2017-04-11 13:15 ` Jesper Nilsson
2017-04-11 12:28 ` [PATCH v3 09/32] frv: " Lorenzo Pieralisi
2017-04-11 12:28 ` Lorenzo Pieralisi
2017-04-11 12:28 ` [PATCH v3 10/32] hexagon: " Lorenzo Pieralisi
2017-04-11 12:28 ` Lorenzo Pieralisi
2017-04-11 12:28 ` Lorenzo Pieralisi
2017-04-11 12:28 ` Lorenzo Pieralisi
2017-04-11 12:28 ` [PATCH v3 11/32] ia64: " Lorenzo Pieralisi
2017-04-11 12:28 ` Lorenzo Pieralisi
2017-04-11 12:28 ` [PATCH v3 12/32] m32r: " Lorenzo Pieralisi
2017-04-11 12:28 ` Lorenzo Pieralisi
2017-04-11 12:28 ` [PATCH v3 13/32] m68k: " Lorenzo Pieralisi
2017-04-11 12:28 ` Lorenzo Pieralisi
2017-04-11 12:28 ` Lorenzo Pieralisi
2017-04-11 12:28 ` Lorenzo Pieralisi
2017-04-11 12:28 ` [PATCH v3 14/32] metag: " Lorenzo Pieralisi
2017-04-11 12:28 ` Lorenzo Pieralisi
2017-04-11 12:28 ` [PATCH v3 15/32] microblaze: " Lorenzo Pieralisi
2017-04-11 12:28 ` Lorenzo Pieralisi
2017-04-11 12:28 ` [PATCH v3 16/32] mips: " Lorenzo Pieralisi
2017-04-11 12:28 ` Lorenzo Pieralisi
2017-04-11 12:28 ` [PATCH v3 17/32] mn10300: " Lorenzo Pieralisi
2017-04-11 12:28 ` Lorenzo Pieralisi
2017-04-11 12:28 ` [PATCH v3 18/32] nios2: " Lorenzo Pieralisi
2017-04-11 12:28 ` Lorenzo Pieralisi
2017-04-11 12:28 ` [PATCH v3 19/32] openrisc: " Lorenzo Pieralisi
2017-04-11 12:28 ` Lorenzo Pieralisi
2017-04-11 12:29 ` [PATCH v3 20/32] parisc: " Lorenzo Pieralisi
2017-04-11 12:29 ` Lorenzo Pieralisi
2017-04-11 12:29 ` [PATCH v3 21/32] powerpc: " Lorenzo Pieralisi
2017-04-11 12:29 ` Lorenzo Pieralisi
2017-04-11 13:38 ` Benjamin Herrenschmidt
2017-04-11 13:38 ` Benjamin Herrenschmidt
2017-04-11 13:38 ` Benjamin Herrenschmidt
2017-04-11 13:38 ` Benjamin Herrenschmidt
2017-04-11 14:24 ` Lorenzo Pieralisi
2017-04-11 14:24 ` Lorenzo Pieralisi
2017-04-11 14:24 ` Lorenzo Pieralisi
2017-04-11 23:15 ` Benjamin Herrenschmidt
2017-04-11 23:15 ` Benjamin Herrenschmidt
2017-04-11 23:15 ` Benjamin Herrenschmidt
2017-04-11 23:15 ` Benjamin Herrenschmidt
2017-04-13 3:35 ` Michael Ellerman
2017-04-13 3:35 ` Michael Ellerman
2017-04-11 12:29 ` [PATCH v3 22/32] s390: " Lorenzo Pieralisi
2017-04-11 12:29 ` Lorenzo Pieralisi
2017-04-11 12:29 ` [PATCH v3 23/32] sh: " Lorenzo Pieralisi
2017-04-11 12:29 ` Lorenzo Pieralisi
2017-04-11 12:29 ` [PATCH v3 24/32] sparc: " Lorenzo Pieralisi
2017-04-11 12:29 ` Lorenzo Pieralisi
2017-04-11 12:29 ` [PATCH v3 25/32] tile: " Lorenzo Pieralisi
2017-04-11 12:29 ` Lorenzo Pieralisi
2017-04-11 12:29 ` [PATCH v3 26/32] unicore32: " Lorenzo Pieralisi
2017-04-11 12:29 ` Lorenzo Pieralisi
2017-04-11 12:29 ` [PATCH v3 27/32] x86: " Lorenzo Pieralisi
2017-04-11 12:29 ` Lorenzo Pieralisi
2017-04-11 12:29 ` [PATCH v3 28/32] xtensa: " Lorenzo Pieralisi
2017-04-11 12:29 ` Lorenzo Pieralisi
2017-04-11 12:29 ` [PATCH v3 29/32] arm64: implement ioremap_nopost() interface Lorenzo Pieralisi
2017-04-11 12:29 ` Lorenzo Pieralisi
2017-04-11 12:29 ` Lorenzo Pieralisi
2017-04-11 12:29 ` Lorenzo Pieralisi
2017-04-11 12:29 ` [PATCH v3 30/32] arm: " Lorenzo Pieralisi
2017-04-11 12:29 ` Lorenzo Pieralisi
2017-04-11 12:29 ` [PATCH v3 31/32] lib: fix Devres devm_ioremap_* offset parameter kerneldoc description Lorenzo Pieralisi
2017-04-11 12:29 ` Lorenzo Pieralisi
2017-04-11 12:29 ` Lorenzo Pieralisi
2017-04-11 12:29 ` [PATCH v3 32/32] lib: implement Devres ioremap_nopost() interface Lorenzo Pieralisi
2017-04-11 12:29 ` Lorenzo Pieralisi
2017-04-11 12:29 ` Lorenzo Pieralisi
2017-04-11 13:38 ` [PATCH v3 00/32] PCI: fix config and I/O Address space memory mappings Benjamin Herrenschmidt
2017-04-11 13:38 ` Benjamin Herrenschmidt
2017-04-11 13:38 ` Benjamin Herrenschmidt
2017-04-11 14:08 ` Lorenzo Pieralisi
2017-04-11 14:08 ` Lorenzo Pieralisi
2017-04-11 14:08 ` Lorenzo Pieralisi
2017-04-11 23:12 ` Benjamin Herrenschmidt
2017-04-11 23:12 ` Benjamin Herrenschmidt
2017-04-11 23:12 ` Benjamin Herrenschmidt
2017-04-12 9:44 ` Lorenzo Pieralisi
2017-04-12 9:44 ` Lorenzo Pieralisi
2017-04-12 9:44 ` Lorenzo Pieralisi
2017-04-12 13:48 ` Benjamin Herrenschmidt
2017-04-12 13:48 ` Benjamin Herrenschmidt
2017-04-12 13:48 ` Benjamin Herrenschmidt
2017-04-12 11:31 ` Russell King - ARM Linux
2017-04-12 11:31 ` Russell King - ARM Linux
2017-04-12 11:31 ` Russell King - ARM Linux
2017-04-12 13:51 ` Benjamin Herrenschmidt
2017-04-12 13:51 ` Benjamin Herrenschmidt
2017-04-12 13:51 ` Benjamin Herrenschmidt
2017-04-12 14:16 ` Russell King - ARM Linux
2017-04-12 14:16 ` Russell King - ARM Linux
2017-04-12 14:16 ` Russell King - ARM Linux
2017-04-12 14:41 ` Lorenzo Pieralisi
2017-04-12 14:41 ` Lorenzo Pieralisi
2017-04-12 14:41 ` Lorenzo Pieralisi
2017-04-12 22:30 ` Benjamin Herrenschmidt
2017-04-12 22:30 ` Benjamin Herrenschmidt
2017-04-12 22:30 ` Benjamin Herrenschmidt
2017-04-12 22:45 ` Russell King - ARM Linux
2017-04-12 22:45 ` Russell King - ARM Linux
2017-04-12 22:45 ` Russell King - ARM Linux
2017-04-13 0:53 ` Benjamin Herrenschmidt [this message]
2017-04-13 0:53 ` Benjamin Herrenschmidt
2017-04-13 0:53 ` Benjamin Herrenschmidt
2017-04-18 8:57 ` Lorenzo Pieralisi
2017-04-18 8:57 ` Lorenzo Pieralisi
2017-04-18 8:57 ` Lorenzo Pieralisi
2017-04-18 10:36 ` Benjamin Herrenschmidt
2017-04-18 10:36 ` Benjamin Herrenschmidt
2017-04-18 10:36 ` Benjamin Herrenschmidt
2017-04-18 11:03 ` Lorenzo Pieralisi
2017-04-18 11:03 ` Lorenzo Pieralisi
2017-04-18 11:03 ` Lorenzo Pieralisi
2017-04-18 22:38 ` Benjamin Herrenschmidt
2017-04-18 22:38 ` Benjamin Herrenschmidt
2017-04-18 22:38 ` Benjamin Herrenschmidt
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1492044780.7236.87.camel@kernel.crashing.org \
--to=benh@kernel.crashing.org \
--cc=arnd@arndb.de \
--cc=bhelgaas@google.com \
--cc=catalin.marinas@arm.com \
--cc=chenhc@lemote.com \
--cc=chris@zankel.net \
--cc=cmetcalf@mellanox.com \
--cc=dalias@libc.org \
--cc=davem@davemloft.net \
--cc=deller@gmx.de \
--cc=dhowells@redhat.com \
--cc=egtvedt@samfundet.no \
--cc=fenghua.yu@intel.com \
--cc=geert@linux-m68k.org \
--cc=gxt@mprc.pku.edu.cn \
--cc=heiko.carstens@de.ibm.com \
--cc=hskinnemoen@gmail.com \
--cc=ink@jurassic.park.msu.ru \
--cc=james.hogan@imgtec.com \
--cc=jcmvbkbc@gmail.com \
--cc=jejb@parisc-linux.org \
--cc=jesper.nilsson@axis.com \
--cc=jonas@southpole.se \
--cc=lftan@altera.com \
--cc=linux-arch@vger.kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=linux@armlinux.org.uk \
--cc=lorenzo.pieralisi@arm.com \
--cc=mattst88@gmail.com \
--cc=mcgrof@kernel.org \
--cc=mingo@redhat.com \
--cc=monstr@monstr.eu \
--cc=mpe@ellerman.id.au \
--cc=nks@flawful.org \
--cc=paulus@samba.org \
--cc=ralf@linux-mips.org \
--cc=rkuo@codeaurora.org \
--cc=rth@twiddle.net \
--cc=schwidefsky@de.ibm.com \
--cc=shorne@gmail.com \
--cc=starvik@axis.com \
--cc=stefan.kristiansson@saunalahti.fi \
--cc=tglx@linutronix.de \
--cc=tony.luck@intel.com \
--cc=vgupta@synopsys.com \
--cc=will.deacon@arm.com \
--cc=ysato@users.sourceforge.jp \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.