All of lore.kernel.org
 help / color / mirror / Atom feed
From: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
To: Benjamin Herrenschmidt <benh@kernel.crashing.org>
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 <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: Wed, 12 Apr 2017 10:44:54 +0100	[thread overview]
Message-ID: <20170412094454.GA31143@red-moon> (raw)
In-Reply-To: <1491952371.7236.22.camel@kernel.crashing.org>

On Wed, Apr 12, 2017 at 09:12:51AM +1000, Benjamin Herrenschmidt wrote:
> On Tue, 2017-04-11 at 15:08 +0100, Lorenzo Pieralisi wrote:
> > On Tue, Apr 11, 2017 at 11:38:26PM +1000, Benjamin Herrenschmidt wrote:
> > > On Tue, 2017-04-11 at 13:28 +0100, Lorenzo Pieralisi wrote:
> > > > This patch series[1] is a v3 of a previous version:
> > > > =

> > > > v2: https://lkml.org/lkml/2017/3/27/220
> > > =

> > > I am not a fan of this at All.
> > > =

> > > That whole concept of "ioremap_nopost" is simply not applicable to the
> > > majority of architectures and certainly not in a way that can apply to
> > > arbitrary mappings.
> > > =

> > > It's also very wrong to provide a "default" operation whose semantics
> > > are weaker than what it's supposed to implement. Very wrong actually.
> > > People will use it assuming the non-posted behaviour and things will
> > > break in subtle way when it cannot be provided.
> > =

> > Well, what's very wrong for you it is not very wrong for others
> > (it is just v3, that's fine, see thread below).
> =

> Maybe, but I don't see in what universe it is ok to have something
> defined for the stronger ordering semantics it provide silently
> fallback to weaker semantics.

I agree :). The drivers I am patching use ioremap() already that's
why falling back to ioremap_nocache() seemed reasonable, but again
I agree with you here.

> > I can easily make ioremap_nopost() mirror ioremap_uc() (ie return
> > NULL unless overriden so that basically you can't use in on an arch
> > that can't provide its semantics) but then that becomes very wrong
> > for other reviewers.
> =

> Those reviewers are WRONG :-)
> =

> > https://lkml.org/lkml/2017/4/6/396
> > =

> > > What exactly are you trying to fix here ?
> > =

> > I wrote in the commit logs and cover letter what I am fixing here.
> =

> Right right, what *actual bug you have observed* are you trying to fix
> ?

I have not observed any bug and I never claimed that. It started here:

http://lists.infradead.org/pipermail/linux-arm-kernel/2017-January/477353.h=
tml

If you prefer I am making ARM/ARM64 PCI host bridge drivers
specifications compliant, given that it is architecturally
required.

> I'm pretty such close to all non-x86 archs had that "problem" since the
> dawn of time and it has never hurt anybody.

Good but I still do not see why I would not make this PCI/ARM architecture
compliant.

> That said, I don't think it makes sense to "solve" it by creating a
> "generic" mapping semantic that is basically impossible to implement on
> most architectures out there (and cannot be emulated).
> =

> This is a problem to be solved by the bridge itself. If ARM has a
> mapping attribute to make stores non-posted, keep this an ARM specific
> attribute at this stage I'd say.

I can't. Some PCI host bridge drivers (DT) are shared between ARM/ARM64
and live in drivers (and are also reused on some arches eg microblaze)
and they use ioremap() to map config space.

So the idea behind this series was to add an interface (that is
overriden on ARM/ARM64), it started as a PCI specific interface (v1) and
evolved to ioremap_nopost() (v2).

Thanks,
Lorenzo

> > Anyway:
> > =

> > "The PCI specifications (Rev 3.0, 3.2.5 "Transaction Ordering and
> > Posting") mandate non-posted configuration transactions. As further
> > highlighted in the PCIe specifications (4.0 - Rev0.3, "Ordering
> > Considerations for the Enhanced Configuration Access Mechanism"),
> > through ECAM and ECAM-derivative configuration mechanism, the memory
> > mapped transactions from the host CPU into Configuration Requests on the
> > PCI express fabric may create ordering problems for software because
> > writes to memory address are typically posted transactions (unless the
> > architecture can enforce through virtual address mapping non-posted
> > write transactions behaviour) but writes to Configuration Space are not
> > posted on the PCI express fabric."
> > =

> > On ARM64:
> > =

> > "This rule is reinforced by the ARM v8 architecture reference manual
> > (issue A.k, Early Write Acknowledgment) that explicitly recommends
> > that No Early Write Acknowledgment attribute should be used to map
> > PCI configuration (write) transactions."
> > =

> > > If a given PCIe host bridge (architecture specific) require a special
> > > sauce to provide the illusion of non-posting, then implement this in
> > > the actual root complex code.
> > > =

> > > BTW. I'm pretty sure we "accidentally" made config writes posted at
> > > least to the PHB on a number of powerpc systems forever and we *never*
> > > had a problem because of it ;)
> > =

> > Ok so we should ignore the PCIe specifications and ARM v8 reference
> > manual waiting for a kernel bug to appear ? Is that what you suggest
> > doing ?
> > =

> > Lorenzo
> > =

> > > > v2 -> v3:
> > > > 	- Created a default ioremap_nopost() implementation in a
> > > > separate
> > > > 	=A0=A0asm-generic header and patched all arches to make use of it
> > > > 	- Removed PCI drivers patches from the series to simplify the
> > > > 	=A0=A0review, they will be posted separately once the
> > > > ioremap_nopost()
> > > > 	=A0=A0interface is settled
> > > > 	- Fixed devm_ioremap_* BUS offset comments and implemented
> > > > 	=A0=A0nopost interface on top of it
> > > > 	- Added collected tags
> > > > =

> > > > v1: https://lkml.org/lkml/2017/2/27/228
> > > > =

> > > > v1 -> v2:
> > > > 	- Changed pci_remap_cfgspace() to more generic ioremap_nopost()
> > > > 	=A0=A0interface
> > > > 	- Added pgprot_nonposted
> > > > 	- Fixed build errors on arches not relying on asm-generic
> > > > headers
> > > > 	- Added PCI versatile host controller driver patch
> > > > 	- Added missing config space remapping to hisilicon host
> > > > controller
> > > > =

> > > > ---------------------
> > > > Original cover letter
> > > > ---------------------
> > > > =

> > > > PCI local bus specifications (Rev3.0, 3.2.5 "Transaction Ordering
> > > > and Posting") strictly require PCI configuration and I/O Address
> > > > space
> > > > write transactions to be non-posted.
> > > > =

> > > > Current crop of DT/ACPI PCI host controllers drivers relies on
> > > > the ioremap interface to map ECAM and ECAM-derivative PCI config
> > > > regions and pci_remap_iospace() to create a VMA for mapping
> > > > PCI host bridge I/O Address space transactions to CPU virtual addre=
ss
> > > > space.
> > > > =

> > > > On some platforms (ie ARM/ARM64) ioremap fails to comply with the P=
CI
> > > > configuration non-posted write transactions requirement, because it
> > > > provides a memory mapping that issues "bufferable" or, in PCI terms
> > > > "posted" write transactions. Likewise, the current
> > > > pci_remap_iospace()
> > > > implementation maps the physical address range that the PCI
> > > > translates
> > > > to I/O space cycles to virtual address space through pgprot_device()
> > > > attributes that on eg ARM64 provides a memory mapping issuing
> > > > posted writes transactions, which is not PCI specifications
> > > > compliant.
> > > > =

> > > > This patch series[1] addresses both issues in one go:
> > > > =

> > > > - It updates the pci_remap_iospace() function to use a page mapping
> > > > =A0 that guarantees non-posted write transactions for I/O space
> > > > addresses
> > > > - It adds a kernel API to remap PCI config space resources, so that
> > > > =A0 architecture can override it with a mapping implementation that
> > > > =A0 guarantees PCI specifications compliancy wrt non-posted write
> > > > =A0 configuration transactions
> > > > - It updates all PCI host controller implementations (and the gener=
ic
> > > > =A0 ECAM layer) to use the newly introduced mapping interface
> > > > =

> > > > Tested on Juno ECAM based interface (DT/ACPI).
> > > > =

> > > > Non-ECAM PCI host controller drivers patches need checking to make
> > > > sure that:
> > > > =

> > > > - I patched the correct resource region mapping for config space
> > > > - There are not any other ways to ensure posted-write completion
> > > > =A0 in the respective pci_ops that make the relevant patch unnecess=
ary
> > > > =

> > > > [1]
> > > > git://git.kernel.org/pub/scm/linux/kernel/git/lpieralisi/linux.git
> > > > pci/config-io-mappings-fix-v3
> > > > =

> > > > Lorenzo Pieralisi (32):
> > > > =A0 PCI: remove __weak tag from pci_remap_iospace()
> > > > =A0 asm-generic/pgtable.h: introduce pgprot_nonposted remap attribu=
te
> > > > =A0 PCI: fix pci_remap_iospace() remap attribute
> > > > =A0 asm-generic: add ioremap_nopost() remap interface
> > > > =A0 alpha: include default ioremap_nopost() implementation
> > > > =A0 avr32: include default ioremap_nopost() implementation
> > > > =A0 arc: include default ioremap_nopost() implementation
> > > > =A0 cris: include default ioremap_nopost() implementation
> > > > =A0 frv: include default ioremap_nopost() implementation
> > > > =A0 hexagon: include default ioremap_nopost() implementation
> > > > =A0 ia64: include default ioremap_nopost() implementation
> > > > =A0 m32r: include default ioremap_nopost() implementation
> > > > =A0 m68k: include default ioremap_nopost() implementation
> > > > =A0 metag: include default ioremap_nopost() implementation
> > > > =A0 microblaze: include default ioremap_nopost() implementation
> > > > =A0 mips: include default ioremap_nopost() implementation
> > > > =A0 mn10300: include default ioremap_nopost() implementation
> > > > =A0 nios2: include default ioremap_nopost() implementation
> > > > =A0 openrisc: include default ioremap_nopost() implementation
> > > > =A0 parisc: include default ioremap_nopost() implementation
> > > > =A0 powerpc: include default ioremap_nopost() implementation
> > > > =A0 s390: include default ioremap_nopost() implementation
> > > > =A0 sh: include default ioremap_nopost() implementation
> > > > =A0 sparc: include default ioremap_nopost() implementation
> > > > =A0 tile: include default ioremap_nopost() implementation
> > > > =A0 unicore32: include default ioremap_nopost() implementation
> > > > =A0 x86: include default ioremap_nopost() implementation
> > > > =A0 xtensa: include default ioremap_nopost() implementation
> > > > =A0 arm64: implement ioremap_nopost() interface
> > > > =A0 arm: implement ioremap_nopost() interface
> > > > =A0 lib: fix Devres devm_ioremap_* offset parameter kerneldoc
> > > > description
> > > > =A0 lib: implement Devres ioremap_nopost() interface
> > > > =

> > > > =A0Documentation/driver-model/devres.txt |=A0=A03 ++
> > > > =A0arch/alpha/include/asm/io.h=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0|=A0=
=A01 +
> > > > =A0arch/arc/include/asm/io.h=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
|=A0=A01 +
> > > > =A0arch/arm/include/asm/io.h=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
|=A0=A09 ++++
> > > > =A0arch/arm/mm/ioremap.c=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0|=A0=A07 +++
> > > > =A0arch/arm/mm/nommu.c=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0|=A0=A09 ++++
> > > > =A0arch/arm64/include/asm/io.h=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0| 12=
 +++++
> > > > =A0arch/avr32/include/asm/io.h=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0|=A0=
=A01 +
> > > > =A0arch/cris/include/asm/io.h=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0|=
=A0=A01 +
> > > > =A0arch/frv/include/asm/io.h=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
|=A0=A01 +
> > > > =A0arch/hexagon/include/asm/io.h=A0=A0=A0=A0=A0=A0=A0=A0=A0|=A0=A02=
 +
> > > > =A0arch/ia64/include/asm/io.h=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0|=
=A0=A01 +
> > > > =A0arch/m32r/include/asm/io.h=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0|=
=A0=A01 +
> > > > =A0arch/m68k/include/asm/io.h=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0|=
=A0=A01 +
> > > > =A0arch/metag/include/asm/io.h=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0|=A0=
=A02 +
> > > > =A0arch/microblaze/include/asm/io.h=A0=A0=A0=A0=A0=A0|=A0=A01 +
> > > > =A0arch/mips/include/asm/io.h=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0|=
=A0=A01 +
> > > > =A0arch/mn10300/include/asm/io.h=A0=A0=A0=A0=A0=A0=A0=A0=A0|=A0=A01=
 +
> > > > =A0arch/nios2/include/asm/io.h=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0|=A0=
=A01 +
> > > > =A0arch/openrisc/include/asm/io.h=A0=A0=A0=A0=A0=A0=A0=A0|=A0=A02 +
> > > > =A0arch/parisc/include/asm/io.h=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0|=A0=
=A01 +
> > > > =A0arch/powerpc/include/asm/io.h=A0=A0=A0=A0=A0=A0=A0=A0=A0|=A0=A01=
 +
> > > > =A0arch/s390/include/asm/io.h=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0|=
=A0=A01 +
> > > > =A0arch/sh/include/asm/io.h=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0|=A0=A01 +
> > > > =A0arch/sparc/include/asm/io.h=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0|=A0=
=A01 +
> > > > =A0arch/tile/include/asm/io.h=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0|=
=A0=A01 +
> > > > =A0arch/unicore32/include/asm/io.h=A0=A0=A0=A0=A0=A0=A0|=A0=A01 +
> > > > =A0arch/x86/include/asm/io.h=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
|=A0=A01 +
> > > > =A0arch/xtensa/include/asm/io.h=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0|=A0=
=A01 +
> > > > =A0drivers/pci/pci.c=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0|=A0=A04 +-
> > > > =A0include/asm-generic/ioremap-nopost.h=A0=A0|=A0=A09 ++++
> > > > =A0include/asm-generic/pgtable.h=A0=A0=A0=A0=A0=A0=A0=A0=A0|=A0=A04=
 ++
> > > > =A0include/linux/device.h=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0|=A0=A02 +
> > > > =A0include/linux/io.h=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0|=A0=A02 +
> > > > =A0lib/devres.c=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0| 84
> > > > +++++++++++++++++++++++++++++++++--
> > > > =A035 files changed, 167 insertions(+), 5 deletions(-)
> > > > =A0create mode 100644 include/asm-generic/ioremap-nopost.h
> > > > =


_______________________________________________
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: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
To: Benjamin Herrenschmidt <benh@kernel.crashing.org>
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 <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.co>
Subject: Re: [PATCH v3 00/32] PCI: fix config and I/O Address space memory mappings
Date: Wed, 12 Apr 2017 10:44:54 +0100	[thread overview]
Message-ID: <20170412094454.GA31143@red-moon> (raw)
In-Reply-To: <1491952371.7236.22.camel@kernel.crashing.org>

On Wed, Apr 12, 2017 at 09:12:51AM +1000, Benjamin Herrenschmidt wrote:
> On Tue, 2017-04-11 at 15:08 +0100, Lorenzo Pieralisi wrote:
> > On Tue, Apr 11, 2017 at 11:38:26PM +1000, Benjamin Herrenschmidt wrote:
> > > On Tue, 2017-04-11 at 13:28 +0100, Lorenzo Pieralisi wrote:
> > > > This patch series[1] is a v3 of a previous version:
> > > > 
> > > > v2: https://lkml.org/lkml/2017/3/27/220
> > > 
> > > I am not a fan of this at All.
> > > 
> > > That whole concept of "ioremap_nopost" is simply not applicable to the
> > > majority of architectures and certainly not in a way that can apply to
> > > arbitrary mappings.
> > > 
> > > It's also very wrong to provide a "default" operation whose semantics
> > > are weaker than what it's supposed to implement. Very wrong actually.
> > > People will use it assuming the non-posted behaviour and things will
> > > break in subtle way when it cannot be provided.
> > 
> > Well, what's very wrong for you it is not very wrong for others
> > (it is just v3, that's fine, see thread below).
> 
> Maybe, but I don't see in what universe it is ok to have something
> defined for the stronger ordering semantics it provide silently
> fallback to weaker semantics.

I agree :). The drivers I am patching use ioremap() already that's
why falling back to ioremap_nocache() seemed reasonable, but again
I agree with you here.

> > I can easily make ioremap_nopost() mirror ioremap_uc() (ie return
> > NULL unless overriden so that basically you can't use in on an arch
> > that can't provide its semantics) but then that becomes very wrong
> > for other reviewers.
> 
> Those reviewers are WRONG :-)
> 
> > https://lkml.org/lkml/2017/4/6/396
> > 
> > > What exactly are you trying to fix here ?
> > 
> > I wrote in the commit logs and cover letter what I am fixing here.
> 
> Right right, what *actual bug you have observed* are you trying to fix
> ?

I have not observed any bug and I never claimed that. It started here:

http://lists.infradead.org/pipermail/linux-arm-kernel/2017-January/477353.html

If you prefer I am making ARM/ARM64 PCI host bridge drivers
specifications compliant, given that it is architecturally
required.

> I'm pretty such close to all non-x86 archs had that "problem" since the
> dawn of time and it has never hurt anybody.

Good but I still do not see why I would not make this PCI/ARM architecture
compliant.

> That said, I don't think it makes sense to "solve" it by creating a
> "generic" mapping semantic that is basically impossible to implement on
> most architectures out there (and cannot be emulated).
> 
> This is a problem to be solved by the bridge itself. If ARM has a
> mapping attribute to make stores non-posted, keep this an ARM specific
> attribute at this stage I'd say.

I can't. Some PCI host bridge drivers (DT) are shared between ARM/ARM64
and live in drivers (and are also reused on some arches eg microblaze)
and they use ioremap() to map config space.

So the idea behind this series was to add an interface (that is
overriden on ARM/ARM64), it started as a PCI specific interface (v1) and
evolved to ioremap_nopost() (v2).

Thanks,
Lorenzo

> > Anyway:
> > 
> > "The PCI specifications (Rev 3.0, 3.2.5 "Transaction Ordering and
> > Posting") mandate non-posted configuration transactions. As further
> > highlighted in the PCIe specifications (4.0 - Rev0.3, "Ordering
> > Considerations for the Enhanced Configuration Access Mechanism"),
> > through ECAM and ECAM-derivative configuration mechanism, the memory
> > mapped transactions from the host CPU into Configuration Requests on the
> > PCI express fabric may create ordering problems for software because
> > writes to memory address are typically posted transactions (unless the
> > architecture can enforce through virtual address mapping non-posted
> > write transactions behaviour) but writes to Configuration Space are not
> > posted on the PCI express fabric."
> > 
> > On ARM64:
> > 
> > "This rule is reinforced by the ARM v8 architecture reference manual
> > (issue A.k, Early Write Acknowledgment) that explicitly recommends
> > that No Early Write Acknowledgment attribute should be used to map
> > PCI configuration (write) transactions."
> > 
> > > If a given PCIe host bridge (architecture specific) require a special
> > > sauce to provide the illusion of non-posting, then implement this in
> > > the actual root complex code.
> > > 
> > > BTW. I'm pretty sure we "accidentally" made config writes posted at
> > > least to the PHB on a number of powerpc systems forever and we *never*
> > > had a problem because of it ;)
> > 
> > Ok so we should ignore the PCIe specifications and ARM v8 reference
> > manual waiting for a kernel bug to appear ? Is that what you suggest
> > doing ?
> > 
> > Lorenzo
> > 
> > > > v2 -> v3:
> > > > 	- Created a default ioremap_nopost() implementation in a
> > > > separate
> > > > 	  asm-generic header and patched all arches to make use of it
> > > > 	- Removed PCI drivers patches from the series to simplify the
> > > > 	  review, they will be posted separately once the
> > > > ioremap_nopost()
> > > > 	  interface is settled
> > > > 	- Fixed devm_ioremap_* BUS offset comments and implemented
> > > > 	  nopost interface on top of it
> > > > 	- Added collected tags
> > > > 
> > > > v1: https://lkml.org/lkml/2017/2/27/228
> > > > 
> > > > v1 -> v2:
> > > > 	- Changed pci_remap_cfgspace() to more generic ioremap_nopost()
> > > > 	  interface
> > > > 	- Added pgprot_nonposted
> > > > 	- Fixed build errors on arches not relying on asm-generic
> > > > headers
> > > > 	- Added PCI versatile host controller driver patch
> > > > 	- Added missing config space remapping to hisilicon host
> > > > controller
> > > > 
> > > > ---------------------
> > > > Original cover letter
> > > > ---------------------
> > > > 
> > > > PCI local bus specifications (Rev3.0, 3.2.5 "Transaction Ordering
> > > > and Posting") strictly require PCI configuration and I/O Address
> > > > space
> > > > write transactions to be non-posted.
> > > > 
> > > > Current crop of DT/ACPI PCI host controllers drivers relies on
> > > > the ioremap interface to map ECAM and ECAM-derivative PCI config
> > > > regions and pci_remap_iospace() to create a VMA for mapping
> > > > PCI host bridge I/O Address space transactions to CPU virtual address
> > > > space.
> > > > 
> > > > On some platforms (ie ARM/ARM64) ioremap fails to comply with the PCI
> > > > configuration non-posted write transactions requirement, because it
> > > > provides a memory mapping that issues "bufferable" or, in PCI terms
> > > > "posted" write transactions. Likewise, the current
> > > > pci_remap_iospace()
> > > > implementation maps the physical address range that the PCI
> > > > translates
> > > > to I/O space cycles to virtual address space through pgprot_device()
> > > > attributes that on eg ARM64 provides a memory mapping issuing
> > > > posted writes transactions, which is not PCI specifications
> > > > compliant.
> > > > 
> > > > This patch series[1] addresses both issues in one go:
> > > > 
> > > > - It updates the pci_remap_iospace() function to use a page mapping
> > > >   that guarantees non-posted write transactions for I/O space
> > > > addresses
> > > > - It adds a kernel API to remap PCI config space resources, so that
> > > >   architecture can override it with a mapping implementation that
> > > >   guarantees PCI specifications compliancy wrt non-posted write
> > > >   configuration transactions
> > > > - It updates all PCI host controller implementations (and the generic
> > > >   ECAM layer) to use the newly introduced mapping interface
> > > > 
> > > > Tested on Juno ECAM based interface (DT/ACPI).
> > > > 
> > > > Non-ECAM PCI host controller drivers patches need checking to make
> > > > sure that:
> > > > 
> > > > - I patched the correct resource region mapping for config space
> > > > - There are not any other ways to ensure posted-write completion
> > > >   in the respective pci_ops that make the relevant patch unnecessary
> > > > 
> > > > [1]
> > > > git://git.kernel.org/pub/scm/linux/kernel/git/lpieralisi/linux.git
> > > > pci/config-io-mappings-fix-v3
> > > > 
> > > > Lorenzo Pieralisi (32):
> > > >   PCI: remove __weak tag from pci_remap_iospace()
> > > >   asm-generic/pgtable.h: introduce pgprot_nonposted remap attribute
> > > >   PCI: fix pci_remap_iospace() remap attribute
> > > >   asm-generic: add ioremap_nopost() remap interface
> > > >   alpha: include default ioremap_nopost() implementation
> > > >   avr32: include default ioremap_nopost() implementation
> > > >   arc: include default ioremap_nopost() implementation
> > > >   cris: include default ioremap_nopost() implementation
> > > >   frv: include default ioremap_nopost() implementation
> > > >   hexagon: include default ioremap_nopost() implementation
> > > >   ia64: include default ioremap_nopost() implementation
> > > >   m32r: include default ioremap_nopost() implementation
> > > >   m68k: include default ioremap_nopost() implementation
> > > >   metag: include default ioremap_nopost() implementation
> > > >   microblaze: include default ioremap_nopost() implementation
> > > >   mips: include default ioremap_nopost() implementation
> > > >   mn10300: include default ioremap_nopost() implementation
> > > >   nios2: include default ioremap_nopost() implementation
> > > >   openrisc: include default ioremap_nopost() implementation
> > > >   parisc: include default ioremap_nopost() implementation
> > > >   powerpc: include default ioremap_nopost() implementation
> > > >   s390: include default ioremap_nopost() implementation
> > > >   sh: include default ioremap_nopost() implementation
> > > >   sparc: include default ioremap_nopost() implementation
> > > >   tile: include default ioremap_nopost() implementation
> > > >   unicore32: include default ioremap_nopost() implementation
> > > >   x86: include default ioremap_nopost() implementation
> > > >   xtensa: include default ioremap_nopost() implementation
> > > >   arm64: implement ioremap_nopost() interface
> > > >   arm: implement ioremap_nopost() interface
> > > >   lib: fix Devres devm_ioremap_* offset parameter kerneldoc
> > > > description
> > > >   lib: implement Devres ioremap_nopost() interface
> > > > 
> > > >  Documentation/driver-model/devres.txt |  3 ++
> > > >  arch/alpha/include/asm/io.h           |  1 +
> > > >  arch/arc/include/asm/io.h             |  1 +
> > > >  arch/arm/include/asm/io.h             |  9 ++++
> > > >  arch/arm/mm/ioremap.c                 |  7 +++
> > > >  arch/arm/mm/nommu.c                   |  9 ++++
> > > >  arch/arm64/include/asm/io.h           | 12 +++++
> > > >  arch/avr32/include/asm/io.h           |  1 +
> > > >  arch/cris/include/asm/io.h            |  1 +
> > > >  arch/frv/include/asm/io.h             |  1 +
> > > >  arch/hexagon/include/asm/io.h         |  2 +
> > > >  arch/ia64/include/asm/io.h            |  1 +
> > > >  arch/m32r/include/asm/io.h            |  1 +
> > > >  arch/m68k/include/asm/io.h            |  1 +
> > > >  arch/metag/include/asm/io.h           |  2 +
> > > >  arch/microblaze/include/asm/io.h      |  1 +
> > > >  arch/mips/include/asm/io.h            |  1 +
> > > >  arch/mn10300/include/asm/io.h         |  1 +
> > > >  arch/nios2/include/asm/io.h           |  1 +
> > > >  arch/openrisc/include/asm/io.h        |  2 +
> > > >  arch/parisc/include/asm/io.h          |  1 +
> > > >  arch/powerpc/include/asm/io.h         |  1 +
> > > >  arch/s390/include/asm/io.h            |  1 +
> > > >  arch/sh/include/asm/io.h              |  1 +
> > > >  arch/sparc/include/asm/io.h           |  1 +
> > > >  arch/tile/include/asm/io.h            |  1 +
> > > >  arch/unicore32/include/asm/io.h       |  1 +
> > > >  arch/x86/include/asm/io.h             |  1 +
> > > >  arch/xtensa/include/asm/io.h          |  1 +
> > > >  drivers/pci/pci.c                     |  4 +-
> > > >  include/asm-generic/ioremap-nopost.h  |  9 ++++
> > > >  include/asm-generic/pgtable.h         |  4 ++
> > > >  include/linux/device.h                |  2 +
> > > >  include/linux/io.h                    |  2 +
> > > >  lib/devres.c                          | 84
> > > > +++++++++++++++++++++++++++++++++--
> > > >  35 files changed, 167 insertions(+), 5 deletions(-)
> > > >  create mode 100644 include/asm-generic/ioremap-nopost.h
> > > > 

WARNING: multiple messages have this Message-ID (diff)
From: lorenzo.pieralisi@arm.com (Lorenzo Pieralisi)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v3 00/32] PCI: fix config and I/O Address space memory mappings
Date: Wed, 12 Apr 2017 10:44:54 +0100	[thread overview]
Message-ID: <20170412094454.GA31143@red-moon> (raw)
In-Reply-To: <1491952371.7236.22.camel@kernel.crashing.org>

On Wed, Apr 12, 2017 at 09:12:51AM +1000, Benjamin Herrenschmidt wrote:
> On Tue, 2017-04-11 at 15:08 +0100, Lorenzo Pieralisi wrote:
> > On Tue, Apr 11, 2017 at 11:38:26PM +1000, Benjamin Herrenschmidt wrote:
> > > On Tue, 2017-04-11 at 13:28 +0100, Lorenzo Pieralisi wrote:
> > > > This patch series[1] is a v3 of a previous version:
> > > > 
> > > > v2: https://lkml.org/lkml/2017/3/27/220
> > > 
> > > I am not a fan of this at All.
> > > 
> > > That whole concept of "ioremap_nopost" is simply not applicable to the
> > > majority of architectures and certainly not in a way that can apply to
> > > arbitrary mappings.
> > > 
> > > It's also very wrong to provide a "default" operation whose semantics
> > > are weaker than what it's supposed to implement. Very wrong actually.
> > > People will use it assuming the non-posted behaviour and things will
> > > break in subtle way when it cannot be provided.
> > 
> > Well, what's very wrong for you it is not very wrong for others
> > (it is just v3, that's fine, see thread below).
> 
> Maybe, but I don't see in what universe it is ok to have something
> defined for the stronger ordering semantics it provide silently
> fallback to weaker semantics.

I agree :). The drivers I am patching use ioremap() already that's
why falling back to ioremap_nocache() seemed reasonable, but again
I agree with you here.

> > I can easily make ioremap_nopost() mirror ioremap_uc() (ie return
> > NULL unless overriden so that basically you can't use in on an arch
> > that can't provide its semantics) but then that becomes very wrong
> > for other reviewers.
> 
> Those reviewers are WRONG :-)
> 
> > https://lkml.org/lkml/2017/4/6/396
> > 
> > > What exactly are you trying to fix here ?
> > 
> > I wrote in the commit logs and cover letter what I am fixing here.
> 
> Right right, what *actual bug you have observed* are you trying to fix
> ?

I have not observed any bug and I never claimed that. It started here:

http://lists.infradead.org/pipermail/linux-arm-kernel/2017-January/477353.html

If you prefer I am making ARM/ARM64 PCI host bridge drivers
specifications compliant, given that it is architecturally
required.

> I'm pretty such close to all non-x86 archs had that "problem" since the
> dawn of time and it has never hurt anybody.

Good but I still do not see why I would not make this PCI/ARM architecture
compliant.

> That said, I don't think it makes sense to "solve" it by creating a
> "generic" mapping semantic that is basically impossible to implement on
> most architectures out there (and cannot be emulated).
> 
> This is a problem to be solved by the bridge itself. If ARM has a
> mapping attribute to make stores non-posted, keep this an ARM specific
> attribute at this stage I'd say.

I can't. Some PCI host bridge drivers (DT) are shared between ARM/ARM64
and live in drivers (and are also reused on some arches eg microblaze)
and they use ioremap() to map config space.

So the idea behind this series was to add an interface (that is
overriden on ARM/ARM64), it started as a PCI specific interface (v1) and
evolved to ioremap_nopost() (v2).

Thanks,
Lorenzo

> > Anyway:
> > 
> > "The PCI specifications (Rev 3.0, 3.2.5 "Transaction Ordering and
> > Posting") mandate non-posted configuration transactions. As further
> > highlighted in the PCIe specifications (4.0 - Rev0.3, "Ordering
> > Considerations for the Enhanced Configuration Access Mechanism"),
> > through ECAM and ECAM-derivative configuration mechanism, the memory
> > mapped transactions from the host CPU into Configuration Requests on the
> > PCI express fabric may create ordering problems for software because
> > writes to memory address are typically posted transactions (unless the
> > architecture can enforce through virtual address mapping non-posted
> > write transactions behaviour) but writes to Configuration Space are not
> > posted on the PCI express fabric."
> > 
> > On ARM64:
> > 
> > "This rule is reinforced by the ARM v8 architecture reference manual
> > (issue A.k, Early Write Acknowledgment) that explicitly recommends
> > that No Early Write Acknowledgment attribute should be used to map
> > PCI configuration (write) transactions."
> > 
> > > If a given PCIe host bridge (architecture specific) require a special
> > > sauce to provide the illusion of non-posting, then implement this in
> > > the actual root complex code.
> > > 
> > > BTW. I'm pretty sure we "accidentally" made config writes posted at
> > > least to the PHB on a number of powerpc systems forever and we *never*
> > > had a problem because of it ;)
> > 
> > Ok so we should ignore the PCIe specifications and ARM v8 reference
> > manual waiting for a kernel bug to appear ? Is that what you suggest
> > doing ?
> > 
> > Lorenzo
> > 
> > > > v2 -> v3:
> > > > 	- Created a default ioremap_nopost() implementation in a
> > > > separate
> > > > 	??asm-generic header and patched all arches to make use of it
> > > > 	- Removed PCI drivers patches from the series to simplify the
> > > > 	??review, they will be posted separately once the
> > > > ioremap_nopost()
> > > > 	??interface is settled
> > > > 	- Fixed devm_ioremap_* BUS offset comments and implemented
> > > > 	??nopost interface on top of it
> > > > 	- Added collected tags
> > > > 
> > > > v1: https://lkml.org/lkml/2017/2/27/228
> > > > 
> > > > v1 -> v2:
> > > > 	- Changed pci_remap_cfgspace() to more generic ioremap_nopost()
> > > > 	??interface
> > > > 	- Added pgprot_nonposted
> > > > 	- Fixed build errors on arches not relying on asm-generic
> > > > headers
> > > > 	- Added PCI versatile host controller driver patch
> > > > 	- Added missing config space remapping to hisilicon host
> > > > controller
> > > > 
> > > > ---------------------
> > > > Original cover letter
> > > > ---------------------
> > > > 
> > > > PCI local bus specifications (Rev3.0, 3.2.5 "Transaction Ordering
> > > > and Posting") strictly require PCI configuration and I/O Address
> > > > space
> > > > write transactions to be non-posted.
> > > > 
> > > > Current crop of DT/ACPI PCI host controllers drivers relies on
> > > > the ioremap interface to map ECAM and ECAM-derivative PCI config
> > > > regions and pci_remap_iospace() to create a VMA for mapping
> > > > PCI host bridge I/O Address space transactions to CPU virtual address
> > > > space.
> > > > 
> > > > On some platforms (ie ARM/ARM64) ioremap fails to comply with the PCI
> > > > configuration non-posted write transactions requirement, because it
> > > > provides a memory mapping that issues "bufferable" or, in PCI terms
> > > > "posted" write transactions. Likewise, the current
> > > > pci_remap_iospace()
> > > > implementation maps the physical address range that the PCI
> > > > translates
> > > > to I/O space cycles to virtual address space through pgprot_device()
> > > > attributes that on eg ARM64 provides a memory mapping issuing
> > > > posted writes transactions, which is not PCI specifications
> > > > compliant.
> > > > 
> > > > This patch series[1] addresses both issues in one go:
> > > > 
> > > > - It updates the pci_remap_iospace() function to use a page mapping
> > > > ? that guarantees non-posted write transactions for I/O space
> > > > addresses
> > > > - It adds a kernel API to remap PCI config space resources, so that
> > > > ? architecture can override it with a mapping implementation that
> > > > ? guarantees PCI specifications compliancy wrt non-posted write
> > > > ? configuration transactions
> > > > - It updates all PCI host controller implementations (and the generic
> > > > ? ECAM layer) to use the newly introduced mapping interface
> > > > 
> > > > Tested on Juno ECAM based interface (DT/ACPI).
> > > > 
> > > > Non-ECAM PCI host controller drivers patches need checking to make
> > > > sure that:
> > > > 
> > > > - I patched the correct resource region mapping for config space
> > > > - There are not any other ways to ensure posted-write completion
> > > > ? in the respective pci_ops that make the relevant patch unnecessary
> > > > 
> > > > [1]
> > > > git://git.kernel.org/pub/scm/linux/kernel/git/lpieralisi/linux.git
> > > > pci/config-io-mappings-fix-v3
> > > > 
> > > > Lorenzo Pieralisi (32):
> > > > ? PCI: remove __weak tag from pci_remap_iospace()
> > > > ? asm-generic/pgtable.h: introduce pgprot_nonposted remap attribute
> > > > ? PCI: fix pci_remap_iospace() remap attribute
> > > > ? asm-generic: add ioremap_nopost() remap interface
> > > > ? alpha: include default ioremap_nopost() implementation
> > > > ? avr32: include default ioremap_nopost() implementation
> > > > ? arc: include default ioremap_nopost() implementation
> > > > ? cris: include default ioremap_nopost() implementation
> > > > ? frv: include default ioremap_nopost() implementation
> > > > ? hexagon: include default ioremap_nopost() implementation
> > > > ? ia64: include default ioremap_nopost() implementation
> > > > ? m32r: include default ioremap_nopost() implementation
> > > > ? m68k: include default ioremap_nopost() implementation
> > > > ? metag: include default ioremap_nopost() implementation
> > > > ? microblaze: include default ioremap_nopost() implementation
> > > > ? mips: include default ioremap_nopost() implementation
> > > > ? mn10300: include default ioremap_nopost() implementation
> > > > ? nios2: include default ioremap_nopost() implementation
> > > > ? openrisc: include default ioremap_nopost() implementation
> > > > ? parisc: include default ioremap_nopost() implementation
> > > > ? powerpc: include default ioremap_nopost() implementation
> > > > ? s390: include default ioremap_nopost() implementation
> > > > ? sh: include default ioremap_nopost() implementation
> > > > ? sparc: include default ioremap_nopost() implementation
> > > > ? tile: include default ioremap_nopost() implementation
> > > > ? unicore32: include default ioremap_nopost() implementation
> > > > ? x86: include default ioremap_nopost() implementation
> > > > ? xtensa: include default ioremap_nopost() implementation
> > > > ? arm64: implement ioremap_nopost() interface
> > > > ? arm: implement ioremap_nopost() interface
> > > > ? lib: fix Devres devm_ioremap_* offset parameter kerneldoc
> > > > description
> > > > ? lib: implement Devres ioremap_nopost() interface
> > > > 
> > > > ?Documentation/driver-model/devres.txt |??3 ++
> > > > ?arch/alpha/include/asm/io.h???????????|??1 +
> > > > ?arch/arc/include/asm/io.h?????????????|??1 +
> > > > ?arch/arm/include/asm/io.h?????????????|??9 ++++
> > > > ?arch/arm/mm/ioremap.c?????????????????|??7 +++
> > > > ?arch/arm/mm/nommu.c???????????????????|??9 ++++
> > > > ?arch/arm64/include/asm/io.h???????????| 12 +++++
> > > > ?arch/avr32/include/asm/io.h???????????|??1 +
> > > > ?arch/cris/include/asm/io.h????????????|??1 +
> > > > ?arch/frv/include/asm/io.h?????????????|??1 +
> > > > ?arch/hexagon/include/asm/io.h?????????|??2 +
> > > > ?arch/ia64/include/asm/io.h????????????|??1 +
> > > > ?arch/m32r/include/asm/io.h????????????|??1 +
> > > > ?arch/m68k/include/asm/io.h????????????|??1 +
> > > > ?arch/metag/include/asm/io.h???????????|??2 +
> > > > ?arch/microblaze/include/asm/io.h??????|??1 +
> > > > ?arch/mips/include/asm/io.h????????????|??1 +
> > > > ?arch/mn10300/include/asm/io.h?????????|??1 +
> > > > ?arch/nios2/include/asm/io.h???????????|??1 +
> > > > ?arch/openrisc/include/asm/io.h????????|??2 +
> > > > ?arch/parisc/include/asm/io.h??????????|??1 +
> > > > ?arch/powerpc/include/asm/io.h?????????|??1 +
> > > > ?arch/s390/include/asm/io.h????????????|??1 +
> > > > ?arch/sh/include/asm/io.h??????????????|??1 +
> > > > ?arch/sparc/include/asm/io.h???????????|??1 +
> > > > ?arch/tile/include/asm/io.h????????????|??1 +
> > > > ?arch/unicore32/include/asm/io.h???????|??1 +
> > > > ?arch/x86/include/asm/io.h?????????????|??1 +
> > > > ?arch/xtensa/include/asm/io.h??????????|??1 +
> > > > ?drivers/pci/pci.c?????????????????????|??4 +-
> > > > ?include/asm-generic/ioremap-nopost.h??|??9 ++++
> > > > ?include/asm-generic/pgtable.h?????????|??4 ++
> > > > ?include/linux/device.h????????????????|??2 +
> > > > ?include/linux/io.h????????????????????|??2 +
> > > > ?lib/devres.c??????????????????????????| 84
> > > > +++++++++++++++++++++++++++++++++--
> > > > ?35 files changed, 167 insertions(+), 5 deletions(-)
> > > > ?create mode 100644 include/asm-generic/ioremap-nopost.h
> > > > 

  reply	other threads:[~2017-04-12  9:44 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 [this message]
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
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=20170412094454.GA31143@red-moon \
    --to=lorenzo.pieralisi@arm.com \
    --cc=arnd@arndb.de \
    --cc=benh@kernel.crashing.org \
    --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=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.