From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Cc: Jonas Bonn <jonas@southpole.se>, Rich Felker <dalias@libc.org>,
linux-pci@vger.kernel.org, Will Deacon <will.deacon@arm.com>,
"James E.J. Bottomley" <jejb@parisc-linux.org>,
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>,
Yoshinori Sato <ysato@users.sourceforge.jp>,
Michael Ellerman <mpe@ellerman.id.au>,
Helge Deller <deller@gmx.de>,
Russell King - ARM Linux <linux@armlinux.org.uk>,
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: Tue, 18 Apr 2017 20:36:48 +1000 [thread overview]
Message-ID: <1492511808.25766.91.camel@kernel.crashing.org> (raw)
In-Reply-To: <20170418085732.GA23882@red-moon>
T24gVHVlLCAyMDE3LTA0LTE4IGF0IDA5OjU3ICswMTAwLCBMb3JlbnpvIFBpZXJhbGlzaSB3cm90
ZToKPiBJIGNhbiBhZGQgYSBkZWZpbmVkKHBncHJvdF9ub25wb3N0ZWQpIHRvIHBjaV9yZW1hcF9p
b3NwYWNlKCkgaWYgdGhhdCdzCj4gbm90IHRvbyB1Z2x5IChJIHN1c3BlY3QgQmpvcm4gaXMgdGhy
aWxsZWQgYWJvdXQgaXQgOikpLCB0aGF0IHBsdXMKPiB0aGUgS2NvbmZpZyBvcHRpb24gZm9yIGlv
cmVtYXBfbm9wb3N0KCkgc2hvdWxkIGNvbXBsZXRlIHRoaXMgc2VyaWVzLgo+IAo+IGludCBwY2lf
cmVtYXBfaW9zcGFjZShjb25zdCBzdHJ1Y3QgcmVzb3VyY2UgKnJlcywgcGh5c19hZGRyX3QgcGh5
c19hZGRyKQo+IHsKPiAjaWYgZGVmaW5lZChQQ0lfSU9CQVNFKSAmJiBkZWZpbmVkKENPTkZJR19N
TVUpICYmIGRlZmluZWQocGdwcm90X25vbnBvc3RlZCkKPiDCoMKgwqDCoMKgwqDCoMKgdW5zaWdu
ZWQgbG9uZyB2YWRkciA9ICh1bnNpZ25lZCBsb25nKVBDSV9JT0JBU0UgKyByZXMtPnN0YXJ0Owo+
IAo+IMKgwqDCoMKgwqDCoMKgwqBpZiAoIShyZXMtPmZsYWdzICYgSU9SRVNPVVJDRV9JTykpCj4g
wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqByZXR1cm4gLUVJTlZBTDsKPiAKPiDCoMKg
wqDCoMKgwqDCoMKgaWYgKHJlcy0+ZW5kID4gSU9fU1BBQ0VfTElNSVQpCj4gwqDCoMKgwqDCoMKg
wqDCoMKgwqDCoMKgwqDCoMKgwqByZXR1cm4gLUVJTlZBTAo+IMKgwqDCoMKgwqDCoMKgwqByZXR1
cm4gaW9yZW1hcF9wYWdlX3JhbmdlKHZhZGRyLCB2YWRkciArIHJlc291cmNlX3NpemUocmVzKSwg
cGh5c19hZGRyLAo+IMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg
wqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBwZ3Byb3Rfbm9ucG9zdGVkKFBBR0VfS0VSTkVMKSk7Cj4g
I2Vsc2UKPiDCoMKgwqDCoMKgwqDCoMKgLyogdGhpcyBhcmNoaXRlY3R1cmUgZG9lcyBub3QgaGF2
ZSBtZW1vcnkgbWFwcGVkIEkvTyBzcGFjZSwKPiDCoMKgwqDCoMKgwqDCoMKgwqDCoCBzbyB0aGlz
IGZ1bmN0aW9uIHNob3VsZCBuZXZlciBiZSBjYWxsZWQgKi8KPiDCoMKgwqDCoMKgwqDCoMKgV0FS
Tl9PTkNFKDEsICJUaGlzIGFyY2hpdGVjdHVyZSBkb2VzIG5vdCBzdXBwb3J0IG1lbW9yeSBtYXBw
ZWQgSS9PXG4iKTsKPiDCoMKgwqDCoMKgwqDCoMKgcmV0dXJuIC1FTk9ERVY7Cj4gI2VuZGlmCgpU
aGUgYWJvdmUgd291bGQgZWZmZWN0aXZlbHkgZGlzYWJsZSBtbWFwJ2luZyBvZiBJTyBzcGFjZSBm
b3IgYW55CmFyY2hpdGVjdHVyZSB0aGF0IGRvZXNuJ3QgaGF2ZSBwZ3Byb3Rfbm9ucG9zdGVkLi4u
IHNvIGV2ZXJ5Ym9keSBleGNlcHQKQVJNLiBUaHVzIGJyZWFraW5nIGEgbnVtYmVyIG9mIHN5c3Rl
bXMgdGhhdCBoYXZlIGJlZW4gd29ya2luZyBmaW5lIGZvcgp5ZWFycy4KCkkgZmFpbCB0byBzZWUg
dGhlIHBvaW50Li4uLgoKSSB0aGluayB5b3UgYXJlIGdpdmluZyB0aGUgd2hvbGUgbm9uLXBvc3Rl
ZCBzdHVmZiB3YXkgbW9yZSBpbXBvcnRhbmNlCnRoYW4gaXQgZGVzZXJ2ZXMuIEl0J3Mgb3JpZ2lu
YWxseSBhIGtsdWRnZSBJbnRlbCBkaWQgdG8gUENJIGJlY2F1c2UgaXQKd2VsbCB3aXRoIHRoZWly
IHN5bmNocm9ub3VzIElPIHNwYWNlLCB3aGljaCB3YXMgaXRzZWxmIGEgcmVtbmFudCBvZgpwcmUt
aGlzdG9yeSB0aGF0IHNob3VsZCBoYXZlIGxvbmcgZGllZC4KCkluIHRoZSBzcGVjaWZpYyBjYXNl
IG9mIFBDSSAoYWdhaW4gSSdtIG5vdCB0YWxraW5nIGFib3V0IHRoZSBnZW5lcmFsCmNhc2Ugb2Yg
cGdwcm90L2lvcmVtYXBfbm9ucG9zdGVkKSwgd2UgaGF2ZSByb3V0aW5lbHkgYmVlbiAidmlvbGF0
aW5nIgp0aGF0IHJ1bGUsIGF0IGxlYXN0IG9uIHRoZSBDUFUgLT4gUENJIEJyaWRnZSBwYXRoICh0
aGUgUENJIGJyaWRnZQppdHNlbGYgdGVuZHMgdG8gcmVzcGVjdCBpdCB0aG91Z2ggSSd2ZSBzZWVu
IGV4Y2VwdGlvbnMpIGZvciBkZWNhZGVzCndpdGhvdXQgYW55IGFkdmVyc2UgZWZmZWN0LgoKSSBk
b24ndCB0aGluayB0aGVyZSdzIG11Y2ggY29kZSAoaWYgYW55KSBvdXQgdGhlcmUgd2hpY2ggYWN0
dWFsbHkKcmVsaWVzIG9uIHRoZSBub24tcG9zdGVkIGNoYXJhY3RlcmlzdGljcyBvZiBJTyBzcGFj
ZS4KCkkgZG9uJ3QgY2FyZSAqdGhhdCogbXVjaCBtaW5kIHlvdSwgd2UgZHJvcHBlZCBJTyBzcGFj
ZSBvbiBQQ0kgd2l0aApQT1dFUjgsIGJ1dCBpdCB3b3VsZCBicmVhayBzdHVmZiBvbiBleGlzdGlu
ZyBvbGRlciBtYWNoaW5lcyBzdWNoIGFzClBvd2VyTWFjcyBmb3Igbm8gZ29vZCByZWFzb24uCgpJ
J2QgcmF0aGVyIHdlIGRvY3VtZW50IHRoYXQgbW1hcCdpbmcgSU8gc3BhY2UgdmlhIHN5c2ZzIGRv
ZXNuJ3QgZnVsbHkKcmVzcGVjdCB0aGUgIm5vbi1wb3N0ZWQiIHNlbWFudGljcyBvZiBJTyBhbmQg
YmUgZG9uZSB3aXRoIGl0LgoKSXMgdGhlcmUgYW55IG90aGVyIHByYWN0aWNhbCB1c2Ugb2Ygbm9u
LXBvc3RlZCBtYXBwaW5ncyA/IENvbmZpZyBzcGFjZQpJIHN1cHBvc2UsIHRob3VnaCBoZXJlIG1v
c3RseSBQQ0kgaG9zdCBicmlkZ2VzIGhhbmRsZSBpdCBieSBkb2luZyBhCnJlYWQgYmFjayBpbiB0
aGUgY29uZmlnIG9wcy4uLgoKQ2hlZXJzLApCZW4uCgoKX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX18KbGludXgtYXJtLWtlcm5lbCBtYWlsaW5nIGxpc3QKbGlu
dXgtYXJtLWtlcm5lbEBsaXN0cy5pbmZyYWRlYWQub3JnCmh0dHA6Ly9saXN0cy5pbmZyYWRlYWQu
b3JnL21haWxtYW4vbGlzdGluZm8vbGludXgtYXJtLWtlcm5lbAo=
WARNING: multiple messages have this Message-ID (diff)
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Cc: Jonas Bonn <jonas@southpole.se>, Rich Felker <dalias@libc.org>,
linux-pci@vger.kernel.org, Will Deacon <will.deacon@arm.com>,
"James E.J. Bottomley" <jejb@parisc-linux.org>,
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>,
Yoshinori Sato <ysato@users.sourceforge.jp>,
Michael Ellerman <mpe@ellerman.id.au>,
Helge Deller <deller@gmx.de>,
Russell King - ARM Linux <linux@armlinux.org.uk>,
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>
Subject: Re: [PATCH v3 00/32] PCI: fix config and I/O Address space memory mappings
Date: Tue, 18 Apr 2017 20:36:48 +1000 [thread overview]
Message-ID: <1492511808.25766.91.camel@kernel.crashing.org> (raw)
In-Reply-To: <20170418085732.GA23882@red-moon>
On Tue, 2017-04-18 at 09:57 +0100, Lorenzo Pieralisi wrote:
> I can add a defined(pgprot_nonposted) to pci_remap_iospace() if that's
> not too ugly (I suspect Bjorn is thrilled about it :)), that plus
> 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;
>
> if (!(res->flags & IORESOURCE_IO))
> return -EINVAL;
>
> if (res->end > IO_SPACE_LIMIT)
> return -EINVAL
> return ioremap_page_range(vaddr, vaddr + resource_size(res), phys_addr,
> pgprot_nonposted(PAGE_KERNEL));
> #else
> /* this architecture does not have memory mapped I/O space,
> so this function should never be called */
> WARN_ONCE(1, "This architecture does not support memory mapped I/O\n");
> return -ENODEV;
> #endif
The above would effectively disable mmap'ing of IO space for any
architecture that doesn't have pgprot_nonposted... so everybody except
ARM. Thus breaking a number of systems that have been working fine for
years.
I fail to see the point....
I think you are giving the whole non-posted stuff way more importance
than it deserves. It's originally a kludge Intel did to PCI because it
well with their synchronous IO space, which was itself a remnant of
pre-history that should have long died.
In the specific case of PCI (again I'm not talking about the general
case of pgprot/ioremap_nonposted), we have routinely been "violating"
that rule, at least on the CPU -> PCI Bridge path (the PCI bridge
itself tends to respect it though I've seen exceptions) for decades
without any adverse effect.
I don't think there's much code (if any) out there which actually
relies on the non-posted characteristics of IO space.
I don't care *that* much mind you, we dropped IO space on PCI with
POWER8, but it would break stuff on existing older machines such as
PowerMacs for no good reason.
I'd rather we document that mmap'ing IO space via sysfs doesn't fully
respect the "non-posted" semantics of IO and be done with it.
Is there any other practical use of non-posted mappings ? Config space
I suppose, though here mostly PCI host bridges handle it by doing a
read back in the config ops...
Cheers,
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: Tue, 18 Apr 2017 20:36:48 +1000 [thread overview]
Message-ID: <1492511808.25766.91.camel@kernel.crashing.org> (raw)
In-Reply-To: <20170418085732.GA23882@red-moon>
On Tue, 2017-04-18 at 09:57 +0100, Lorenzo Pieralisi wrote:
> I can add a defined(pgprot_nonposted) to pci_remap_iospace() if that's
> not too ugly (I suspect Bjorn is thrilled about it :)), that plus
> 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;
>
> ????????if (!(res->flags & IORESOURCE_IO))
> ????????????????return -EINVAL;
>
> ????????if (res->end > IO_SPACE_LIMIT)
> ????????????????return -EINVAL
> ????????return ioremap_page_range(vaddr, vaddr + resource_size(res), phys_addr,
> ????????????????????????????????? pgprot_nonposted(PAGE_KERNEL));
> #else
> ????????/* this architecture does not have memory mapped I/O space,
> ?????????? so this function should never be called */
> ????????WARN_ONCE(1, "This architecture does not support memory mapped I/O\n");
> ????????return -ENODEV;
> #endif
The above would effectively disable mmap'ing of IO space for any
architecture that doesn't have pgprot_nonposted... so everybody except
ARM. Thus breaking a number of systems that have been working fine for
years.
I fail to see the point....
I think you are giving the whole non-posted stuff way more importance
than it deserves. It's originally a kludge Intel did to PCI because it
well with their synchronous IO space, which was itself a remnant of
pre-history that should have long died.
In the specific case of PCI (again I'm not talking about the general
case of pgprot/ioremap_nonposted), we have routinely been "violating"
that rule, at least on the CPU -> PCI Bridge path (the PCI bridge
itself tends to respect it though I've seen exceptions) for decades
without any adverse effect.
I don't think there's much code (if any) out there which actually
relies on the non-posted characteristics of IO space.
I don't care *that* much mind you, we dropped IO space on PCI with
POWER8, but it would break stuff on existing older machines such as
PowerMacs for no good reason.
I'd rather we document that mmap'ing IO space via sysfs doesn't fully
respect the "non-posted" semantics of IO and be done with it.
Is there any other practical use of non-posted mappings ? Config space
I suppose, though here mostly PCI host bridges handle it by doing a
read back in the config ops...
Cheers,
Ben.
next prev parent reply other threads:[~2017-04-18 10:36 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
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 [this message]
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=1492511808.25766.91.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.