* [PATCH v3 00/32] PCI: fix config and I/O Address space memory mappings
@ 2017-04-11 12:28 ` Lorenzo Pieralisi
0 siblings, 0 replies; 171+ messages in thread
From: Lorenzo Pieralisi @ 2017-04-11 12:28 UTC (permalink / raw)
To: linux-arm-kernel
This patch series[1] is a v3 of a previous version:
v2: https://lkml.org/lkml/2017/3/27/220
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
--
2.10.0
^ permalink raw reply [flat|nested] 171+ messages in thread
* [PATCH v3 00/32] PCI: fix config and I/O Address space memory mappings
@ 2017-04-11 12:28 ` Lorenzo Pieralisi
0 siblings, 0 replies; 171+ messages in thread
From: Lorenzo Pieralisi @ 2017-04-11 12:28 UTC (permalink / raw)
To: linux-pci
Cc: Jonas Bonn, Rich Felker, Catalin Marinas, Will Deacon,
James E.J. Bottomley, David Howells, Max Filippov,
Paul Mackerras, Huacai Chen, Guan Xuetao, Thomas Gleixner,
Hans-Christian Egtvedt, linux-arch, Jesper Nilsson,
Lorenzo Pieralisi, Yoshinori Sato, Michael Ellerman,
Helge Deller, Russell King, Ingo Molnar, Geert Uytterhoeven,
Benjamin Herrenschmidt, Matt Turner, Haa
This patch series[1] is a v3 of a previous version:
v2: https://lkml.org/lkml/2017/3/27/220
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
--
2.10.0
^ permalink raw reply [flat|nested] 171+ messages in thread
* [PATCH v3 01/32] PCI: remove __weak tag from pci_remap_iospace()
2017-04-11 12:28 ` Lorenzo Pieralisi
(?)
@ 2017-04-11 12:28 ` Lorenzo Pieralisi
-1 siblings, 0 replies; 171+ messages in thread
From: Lorenzo Pieralisi @ 2017-04-11 12:28 UTC (permalink / raw)
To: linux-pci
Cc: Jonas Bonn, Rich Felker, Catalin Marinas, Will Deacon,
James E.J. Bottomley, David Howells, Max Filippov,
Paul Mackerras, Huacai Chen, Guan Xuetao, Thomas Gleixner,
Hans-Christian Egtvedt, linux-arch, Jesper Nilsson,
Lorenzo Pieralisi, Yoshinori Sato, Michael Ellerman,
Helge Deller, Russell King, Ingo Molnar, Geert Uytterhoeven,
Benjamin Herrenschmidt, Matt Turner, Haavard Skinnemoen,
Fenghua Yu, James Hogan, Chris Metcalf, Arnd Bergmann,
Heiko Carstens, Stefan Kristiansson, Mikael Starvik,
Ivan Kokshaysky, Bjorn Helgaas, Stafford Horne, linux-arm-kernel,
Richard Henderson, Chris Zankel, Michal Simek, Tony Luck,
Vineet Gupta, linux-kernel, Ralf Baechle, Richard Kuo,
Niklas Cassel, Luis R. Rodriguez, Martin Schwidefsky,
Ley Foon Tan, David S. Miller
pci_remap_iospace() is marked as a weak symbol even though
no architecture is currently overriding it; given that its
implementation internals have already code paths that are
arch specific (ie PCI_IOBASE and ioremap_page_range() attributes)
there is no need to leave the weak symbol in the kernel since the
same functionality can be achieved by customizing per-arch the
corresponding functionality.
Remove the __weak symbol from pci_remap_iospace().
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Cc: Bjorn Helgaas <bhelgaas@google.com>
---
drivers/pci/pci.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index 7904d02..bd98674 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -3363,7 +3363,7 @@ unsigned long __weak pci_address_to_pio(phys_addr_t address)
* Only architectures that have memory mapped IO functions defined
* (and the PCI_IOBASE value defined) should call this function.
*/
-int __weak pci_remap_iospace(const struct resource *res, phys_addr_t phys_addr)
+int pci_remap_iospace(const struct resource *res, phys_addr_t phys_addr)
{
#if defined(PCI_IOBASE) && defined(CONFIG_MMU)
unsigned long vaddr = (unsigned long)PCI_IOBASE + res->start;
--
2.10.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 171+ messages in thread* [PATCH v3 01/32] PCI: remove __weak tag from pci_remap_iospace()
@ 2017-04-11 12:28 ` Lorenzo Pieralisi
0 siblings, 0 replies; 171+ messages in thread
From: Lorenzo Pieralisi @ 2017-04-11 12:28 UTC (permalink / raw)
To: linux-arm-kernel
pci_remap_iospace() is marked as a weak symbol even though
no architecture is currently overriding it; given that its
implementation internals have already code paths that are
arch specific (ie PCI_IOBASE and ioremap_page_range() attributes)
there is no need to leave the weak symbol in the kernel since the
same functionality can be achieved by customizing per-arch the
corresponding functionality.
Remove the __weak symbol from pci_remap_iospace().
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Cc: Bjorn Helgaas <bhelgaas@google.com>
---
drivers/pci/pci.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index 7904d02..bd98674 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -3363,7 +3363,7 @@ unsigned long __weak pci_address_to_pio(phys_addr_t address)
* Only architectures that have memory mapped IO functions defined
* (and the PCI_IOBASE value defined) should call this function.
*/
-int __weak pci_remap_iospace(const struct resource *res, phys_addr_t phys_addr)
+int pci_remap_iospace(const struct resource *res, phys_addr_t phys_addr)
{
#if defined(PCI_IOBASE) && defined(CONFIG_MMU)
unsigned long vaddr = (unsigned long)PCI_IOBASE + res->start;
--
2.10.0
^ permalink raw reply related [flat|nested] 171+ messages in thread* [PATCH v3 01/32] PCI: remove __weak tag from pci_remap_iospace()
@ 2017-04-11 12:28 ` Lorenzo Pieralisi
0 siblings, 0 replies; 171+ messages in thread
From: Lorenzo Pieralisi @ 2017-04-11 12:28 UTC (permalink / raw)
To: linux-pci
Cc: Jonas Bonn, Rich Felker, Catalin Marinas, Will Deacon,
James E.J. Bottomley, David Howells, Max Filippov,
Paul Mackerras, Huacai Chen, Guan Xuetao, Thomas Gleixner,
Hans-Christian Egtvedt, linux-arch, Jesper Nilsson,
Lorenzo Pieralisi, Yoshinori Sato, Michael Ellerman,
Helge Deller, Russell King, Ingo Molnar, Geert Uytterhoeven,
Benjamin Herrenschmidt, Matt Turner, Haa
pci_remap_iospace() is marked as a weak symbol even though
no architecture is currently overriding it; given that its
implementation internals have already code paths that are
arch specific (ie PCI_IOBASE and ioremap_page_range() attributes)
there is no need to leave the weak symbol in the kernel since the
same functionality can be achieved by customizing per-arch the
corresponding functionality.
Remove the __weak symbol from pci_remap_iospace().
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Cc: Bjorn Helgaas <bhelgaas@google.com>
---
drivers/pci/pci.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index 7904d02..bd98674 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -3363,7 +3363,7 @@ unsigned long __weak pci_address_to_pio(phys_addr_t address)
* Only architectures that have memory mapped IO functions defined
* (and the PCI_IOBASE value defined) should call this function.
*/
-int __weak pci_remap_iospace(const struct resource *res, phys_addr_t phys_addr)
+int pci_remap_iospace(const struct resource *res, phys_addr_t phys_addr)
{
#if defined(PCI_IOBASE) && defined(CONFIG_MMU)
unsigned long vaddr = (unsigned long)PCI_IOBASE + res->start;
--
2.10.0
^ permalink raw reply related [flat|nested] 171+ messages in thread
* [PATCH v3 02/32] asm-generic/pgtable.h: introduce pgprot_nonposted remap attribute
2017-04-11 12:28 ` Lorenzo Pieralisi
(?)
@ 2017-04-11 12:28 ` Lorenzo Pieralisi
-1 siblings, 0 replies; 171+ messages in thread
From: Lorenzo Pieralisi @ 2017-04-11 12:28 UTC (permalink / raw)
To: linux-pci
Cc: Jonas Bonn, Rich Felker, Catalin Marinas, Will Deacon,
James E.J. Bottomley, David Howells, Max Filippov,
Paul Mackerras, Huacai Chen, Guan Xuetao, Thomas Gleixner,
Hans-Christian Egtvedt, linux-arch, Jesper Nilsson,
Lorenzo Pieralisi, Yoshinori Sato, Michael Ellerman,
Helge Deller, Russell King, Ingo Molnar, Geert Uytterhoeven,
Benjamin Herrenschmidt, Matt Turner, Haavard Skinnemoen,
Fenghua Yu, James Hogan, Chris Metcalf, Arnd Bergmann,
Heiko Carstens, Stefan Kristiansson, Mikael Starvik,
Ivan Kokshaysky, Bjorn Helgaas, Stafford Horne, linux-arm-kernel,
Richard Henderson, Chris Zankel, Michal Simek, Tony Luck,
Vineet Gupta, linux-kernel, Ralf Baechle, Richard Kuo,
Niklas Cassel, Luis R. Rodriguez, Martin Schwidefsky,
Ley Foon Tan, David S. Miller
According to the PCI local bus specifications (Revision 3.0, 3.2.5),
I/O Address space transactions are non-posted. On architectures where
I/O space is implemented through a chunk of memory mapped space mapped
to PCI address space (ie IA64/ARM/ARM64) the memory mapping for the
region backing I/O Address Space transactions determines the I/O
transactions attributes (before the transactions actually reaches the
PCI bus where it is handled according to the PCI specifications).
The kernel lacks a pgprot_* attribute to map memory with type
generating non-posted writes transactions, which therefore needs to
be added.
Add a pgprot_nonposted mapping prot to create a memory mapping for
memory areas requiring non-posted write transactions; make it default to
pgprot_noncached (which should provide a sane default behaviour) but
still allowing architectures on which pgprot_noncached results in posted
write transactions to override the prot with an arch specific
implementation that guarantees non-posted writes transactions.
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Will Deacon <will.deacon@arm.com>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Cc: Russell King <linux@armlinux.org.uk>
Cc: Catalin Marinas <catalin.marinas@arm.com>
---
include/asm-generic/pgtable.h | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/include/asm-generic/pgtable.h b/include/asm-generic/pgtable.h
index 1fad160..2070172 100644
--- a/include/asm-generic/pgtable.h
+++ b/include/asm-generic/pgtable.h
@@ -399,6 +399,10 @@ static inline int pud_same(pud_t pud_a, pud_t pud_b)
#define pgprot_device pgprot_noncached
#endif
+#ifndef pgprot_nonposted
+#define pgprot_nonposted pgprot_noncached
+#endif
+
#ifndef pgprot_modify
#define pgprot_modify pgprot_modify
static inline pgprot_t pgprot_modify(pgprot_t oldprot, pgprot_t newprot)
--
2.10.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 171+ messages in thread
* [PATCH v3 02/32] asm-generic/pgtable.h: introduce pgprot_nonposted remap attribute
@ 2017-04-11 12:28 ` Lorenzo Pieralisi
0 siblings, 0 replies; 171+ messages in thread
From: Lorenzo Pieralisi @ 2017-04-11 12:28 UTC (permalink / raw)
To: linux-arm-kernel
According to the PCI local bus specifications (Revision 3.0, 3.2.5),
I/O Address space transactions are non-posted. On architectures where
I/O space is implemented through a chunk of memory mapped space mapped
to PCI address space (ie IA64/ARM/ARM64) the memory mapping for the
region backing I/O Address Space transactions determines the I/O
transactions attributes (before the transactions actually reaches the
PCI bus where it is handled according to the PCI specifications).
The kernel lacks a pgprot_* attribute to map memory with type
generating non-posted writes transactions, which therefore needs to
be added.
Add a pgprot_nonposted mapping prot to create a memory mapping for
memory areas requiring non-posted write transactions; make it default to
pgprot_noncached (which should provide a sane default behaviour) but
still allowing architectures on which pgprot_noncached results in posted
write transactions to override the prot with an arch specific
implementation that guarantees non-posted writes transactions.
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Will Deacon <will.deacon@arm.com>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Cc: Russell King <linux@armlinux.org.uk>
Cc: Catalin Marinas <catalin.marinas@arm.com>
---
include/asm-generic/pgtable.h | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/include/asm-generic/pgtable.h b/include/asm-generic/pgtable.h
index 1fad160..2070172 100644
--- a/include/asm-generic/pgtable.h
+++ b/include/asm-generic/pgtable.h
@@ -399,6 +399,10 @@ static inline int pud_same(pud_t pud_a, pud_t pud_b)
#define pgprot_device pgprot_noncached
#endif
+#ifndef pgprot_nonposted
+#define pgprot_nonposted pgprot_noncached
+#endif
+
#ifndef pgprot_modify
#define pgprot_modify pgprot_modify
static inline pgprot_t pgprot_modify(pgprot_t oldprot, pgprot_t newprot)
--
2.10.0
^ permalink raw reply related [flat|nested] 171+ messages in thread
* [PATCH v3 02/32] asm-generic/pgtable.h: introduce pgprot_nonposted remap attribute
@ 2017-04-11 12:28 ` Lorenzo Pieralisi
0 siblings, 0 replies; 171+ messages in thread
From: Lorenzo Pieralisi @ 2017-04-11 12:28 UTC (permalink / raw)
To: linux-pci
Cc: Jonas Bonn, Rich Felker, Catalin Marinas, Will Deacon,
James E.J. Bottomley, David Howells, Max Filippov,
Paul Mackerras, Huacai Chen, Guan Xuetao, Thomas Gleixner,
Hans-Christian Egtvedt, linux-arch, Jesper Nilsson,
Lorenzo Pieralisi, Yoshinori Sato, Michael Ellerman,
Helge Deller, Russell King, Ingo Molnar, Geert Uytterhoeven,
Benjamin Herrenschmidt, Matt Turner, Haa
According to the PCI local bus specifications (Revision 3.0, 3.2.5),
I/O Address space transactions are non-posted. On architectures where
I/O space is implemented through a chunk of memory mapped space mapped
to PCI address space (ie IA64/ARM/ARM64) the memory mapping for the
region backing I/O Address Space transactions determines the I/O
transactions attributes (before the transactions actually reaches the
PCI bus where it is handled according to the PCI specifications).
The kernel lacks a pgprot_* attribute to map memory with type
generating non-posted writes transactions, which therefore needs to
be added.
Add a pgprot_nonposted mapping prot to create a memory mapping for
memory areas requiring non-posted write transactions; make it default to
pgprot_noncached (which should provide a sane default behaviour) but
still allowing architectures on which pgprot_noncached results in posted
write transactions to override the prot with an arch specific
implementation that guarantees non-posted writes transactions.
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Will Deacon <will.deacon@arm.com>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Cc: Russell King <linux@armlinux.org.uk>
Cc: Catalin Marinas <catalin.marinas@arm.com>
---
include/asm-generic/pgtable.h | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/include/asm-generic/pgtable.h b/include/asm-generic/pgtable.h
index 1fad160..2070172 100644
--- a/include/asm-generic/pgtable.h
+++ b/include/asm-generic/pgtable.h
@@ -399,6 +399,10 @@ static inline int pud_same(pud_t pud_a, pud_t pud_b)
#define pgprot_device pgprot_noncached
#endif
+#ifndef pgprot_nonposted
+#define pgprot_nonposted pgprot_noncached
+#endif
+
#ifndef pgprot_modify
#define pgprot_modify pgprot_modify
static inline pgprot_t pgprot_modify(pgprot_t oldprot, pgprot_t newprot)
--
2.10.0
^ permalink raw reply related [flat|nested] 171+ messages in thread
* [PATCH v3 03/32] PCI: fix pci_remap_iospace() remap attribute
2017-04-11 12:28 ` Lorenzo Pieralisi
(?)
@ 2017-04-11 12:28 ` Lorenzo Pieralisi
-1 siblings, 0 replies; 171+ messages in thread
From: Lorenzo Pieralisi @ 2017-04-11 12:28 UTC (permalink / raw)
To: linux-pci
Cc: Jonas Bonn, Rich Felker, Catalin Marinas, Will Deacon,
James E.J. Bottomley, David Howells, Max Filippov,
Paul Mackerras, Huacai Chen, Guan Xuetao, Thomas Gleixner,
Hans-Christian Egtvedt, linux-arch, Jesper Nilsson,
Lorenzo Pieralisi, Yoshinori Sato, Michael Ellerman,
Helge Deller, Russell King, Ingo Molnar, Geert Uytterhoeven,
Benjamin Herrenschmidt, Matt Turner, Haavard Skinnemoen,
Fenghua Yu, James Hogan, Chris Metcalf, Arnd Bergmann,
Heiko Carstens, Stefan Kristiansson, Mikael Starvik,
Ivan Kokshaysky, Bjorn Helgaas, Stafford Horne, linux-arm-kernel,
Richard Henderson, Chris Zankel, Michal Simek, Tony Luck,
Vineet Gupta, linux-kernel, Ralf Baechle, Richard Kuo,
Niklas Cassel, Luis R. Rodriguez, Martin Schwidefsky,
Ley Foon Tan, David S. Miller
According to the PCI local bus specifications (Revision 3.0, 3.2.5),
I/O Address space transactions are non-posted. On architectures where
I/O space is implemented through a chunk of memory mapped space mapped
to PCI address space (ie IA64/ARM/ARM64) the memory mapping for the
region backing I/O Address Space transactions determines the I/O
transactions attributes (before the transactions actually reaches the
PCI bus where it is handled according to the PCI specifications).
Current pci_remap_iospace() interface, that is used to map the PCI I/O
Address Space into virtual address space, use pgprot_device() as memory
attribute for the virtual address mapping, that in some architectures
(ie ARM64) provides non-cacheable but write bufferable mappings (ie
posted writes), which clash with the non-posted write behaviour for I/O
Address Space mandated by the PCI specifications.
Update the prot ioremap_page_range() parameter in pci_remap_iospace()
to pgprot_nonposted to ensure that the virtual mapping backing
I/O Address Space guarantee non-posted write transactions issued
when addressing I/O Address Space through the MMIO mapping.
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Will Deacon <will.deacon@arm.com>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Cc: Russell King <linux@armlinux.org.uk>
Cc: Catalin Marinas <catalin.marinas@arm.com>
---
drivers/pci/pci.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index bd98674..9e084c0 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -3375,7 +3375,7 @@ int pci_remap_iospace(const struct resource *res, phys_addr_t phys_addr)
return -EINVAL;
return ioremap_page_range(vaddr, vaddr + resource_size(res), phys_addr,
- pgprot_device(PAGE_KERNEL));
+ pgprot_nonposted(PAGE_KERNEL));
#else
/* this architecture does not have memory mapped I/O space,
so this function should never be called */
--
2.10.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 171+ messages in thread
* [PATCH v3 03/32] PCI: fix pci_remap_iospace() remap attribute
@ 2017-04-11 12:28 ` Lorenzo Pieralisi
0 siblings, 0 replies; 171+ messages in thread
From: Lorenzo Pieralisi @ 2017-04-11 12:28 UTC (permalink / raw)
To: linux-arm-kernel
According to the PCI local bus specifications (Revision 3.0, 3.2.5),
I/O Address space transactions are non-posted. On architectures where
I/O space is implemented through a chunk of memory mapped space mapped
to PCI address space (ie IA64/ARM/ARM64) the memory mapping for the
region backing I/O Address Space transactions determines the I/O
transactions attributes (before the transactions actually reaches the
PCI bus where it is handled according to the PCI specifications).
Current pci_remap_iospace() interface, that is used to map the PCI I/O
Address Space into virtual address space, use pgprot_device() as memory
attribute for the virtual address mapping, that in some architectures
(ie ARM64) provides non-cacheable but write bufferable mappings (ie
posted writes), which clash with the non-posted write behaviour for I/O
Address Space mandated by the PCI specifications.
Update the prot ioremap_page_range() parameter in pci_remap_iospace()
to pgprot_nonposted to ensure that the virtual mapping backing
I/O Address Space guarantee non-posted write transactions issued
when addressing I/O Address Space through the MMIO mapping.
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Will Deacon <will.deacon@arm.com>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Cc: Russell King <linux@armlinux.org.uk>
Cc: Catalin Marinas <catalin.marinas@arm.com>
---
drivers/pci/pci.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index bd98674..9e084c0 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -3375,7 +3375,7 @@ int pci_remap_iospace(const struct resource *res, phys_addr_t phys_addr)
return -EINVAL;
return ioremap_page_range(vaddr, vaddr + resource_size(res), phys_addr,
- pgprot_device(PAGE_KERNEL));
+ pgprot_nonposted(PAGE_KERNEL));
#else
/* this architecture does not have memory mapped I/O space,
so this function should never be called */
--
2.10.0
^ permalink raw reply related [flat|nested] 171+ messages in thread
* [PATCH v3 03/32] PCI: fix pci_remap_iospace() remap attribute
@ 2017-04-11 12:28 ` Lorenzo Pieralisi
0 siblings, 0 replies; 171+ messages in thread
From: Lorenzo Pieralisi @ 2017-04-11 12:28 UTC (permalink / raw)
To: linux-pci
Cc: Jonas Bonn, Rich Felker, Catalin Marinas, Will Deacon,
James E.J. Bottomley, David Howells, Max Filippov,
Paul Mackerras, Huacai Chen, Guan Xuetao, Thomas Gleixner,
Hans-Christian Egtvedt, linux-arch, Jesper Nilsson,
Lorenzo Pieralisi, Yoshinori Sato, Michael Ellerman,
Helge Deller, Russell King, Ingo Molnar, Geert Uytterhoeven,
Benjamin Herrenschmidt, Matt Turner, Haa
According to the PCI local bus specifications (Revision 3.0, 3.2.5),
I/O Address space transactions are non-posted. On architectures where
I/O space is implemented through a chunk of memory mapped space mapped
to PCI address space (ie IA64/ARM/ARM64) the memory mapping for the
region backing I/O Address Space transactions determines the I/O
transactions attributes (before the transactions actually reaches the
PCI bus where it is handled according to the PCI specifications).
Current pci_remap_iospace() interface, that is used to map the PCI I/O
Address Space into virtual address space, use pgprot_device() as memory
attribute for the virtual address mapping, that in some architectures
(ie ARM64) provides non-cacheable but write bufferable mappings (ie
posted writes), which clash with the non-posted write behaviour for I/O
Address Space mandated by the PCI specifications.
Update the prot ioremap_page_range() parameter in pci_remap_iospace()
to pgprot_nonposted to ensure that the virtual mapping backing
I/O Address Space guarantee non-posted write transactions issued
when addressing I/O Address Space through the MMIO mapping.
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Will Deacon <will.deacon@arm.com>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Cc: Russell King <linux@armlinux.org.uk>
Cc: Catalin Marinas <catalin.marinas@arm.com>
---
drivers/pci/pci.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index bd98674..9e084c0 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -3375,7 +3375,7 @@ int pci_remap_iospace(const struct resource *res, phys_addr_t phys_addr)
return -EINVAL;
return ioremap_page_range(vaddr, vaddr + resource_size(res), phys_addr,
- pgprot_device(PAGE_KERNEL));
+ pgprot_nonposted(PAGE_KERNEL));
#else
/* this architecture does not have memory mapped I/O space,
so this function should never be called */
--
2.10.0
^ permalink raw reply related [flat|nested] 171+ messages in thread
* [PATCH v3 04/32] asm-generic: add ioremap_nopost() remap interface
2017-04-11 12:28 ` Lorenzo Pieralisi
(?)
@ 2017-04-11 12:28 ` Lorenzo Pieralisi
-1 siblings, 0 replies; 171+ messages in thread
From: Lorenzo Pieralisi @ 2017-04-11 12:28 UTC (permalink / raw)
To: linux-pci
Cc: Jonas Bonn, Rich Felker, Catalin Marinas, Will Deacon,
James E.J. Bottomley, David Howells, Max Filippov,
Paul Mackerras, Huacai Chen, Guan Xuetao, Thomas Gleixner,
Hans-Christian Egtvedt, linux-arch, Jesper Nilsson,
Lorenzo Pieralisi, Yoshinori Sato, Michael Ellerman,
Helge Deller, Russell King, Ingo Molnar, Geert Uytterhoeven,
Benjamin Herrenschmidt, Matt Turner, Haavard Skinnemoen,
Fenghua Yu, James Hogan, Chris Metcalf, Arnd Bergmann,
Heiko Carstens, Stefan Kristiansson, Mikael Starvik,
Ivan Kokshaysky, Bjorn Helgaas, Stafford Horne, linux-arm-kernel,
Richard Henderson, Chris Zankel, Michal Simek, Tony Luck,
Vineet Gupta, linux-kernel, Ralf Baechle, Richard Kuo,
Niklas Cassel, Luis R . Rodriguez, Martin Schwidefsky,
Ley Foon Tan, David S. Miller
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.
Current DT and ACPI host bridge controllers map PCI configuration space
(ECAM and ECAM-derivative) into the virtual address space through
ioremap() calls, that are non-cacheable device accesses on most
architectures, but may provide "bufferable" or "posted" write semantics
in architecture like eg ARM/ARM64 that allow ioremap'ed regions writes
to be buffered in the bus connecting the host CPU to the PCI fabric;
this behaviour, as underlined in the PCIe specifications, may trigger
transactions ordering rules and must be prevented.
Introduce a new generic and explicit API to create a memory mapping for
ECAM and ECAM-derivative config space area (and a corresponding generic
asm-generic header file) that defaults to ioremap_nocache() (which
should provide a sane default behaviour) and can be included by
all architectures that do not require an arch specific memory mapping
for ioremap_nopost() to guarantee non-posted writes behaviour.
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Cc: Russell King <linux@armlinux.org.uk>
Cc: Luis R. Rodriguez <mcgrof@kernel.org>
---
include/asm-generic/ioremap-nopost.h | 9 +++++++++
1 file changed, 9 insertions(+)
create mode 100644 include/asm-generic/ioremap-nopost.h
diff --git a/include/asm-generic/ioremap-nopost.h b/include/asm-generic/ioremap-nopost.h
new file mode 100644
index 0000000..015911f
--- /dev/null
+++ b/include/asm-generic/ioremap-nopost.h
@@ -0,0 +1,9 @@
+#ifndef __ASM_GENERIC_IOREMAP_NOPOST_H
+#define __ASM_GENERIC_IOREMAP_NOPOST_H
+
+static inline void __iomem *ioremap_nopost(phys_addr_t offset, size_t size)
+{
+ return ioremap_nocache(offset, size);
+}
+
+#endif /* __ASM_GENERIC_IOREMAP_NOPOST_H */
--
2.10.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 171+ messages in thread* [PATCH v3 04/32] asm-generic: add ioremap_nopost() remap interface
@ 2017-04-11 12:28 ` Lorenzo Pieralisi
0 siblings, 0 replies; 171+ messages in thread
From: Lorenzo Pieralisi @ 2017-04-11 12:28 UTC (permalink / raw)
To: linux-arm-kernel
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.
Current DT and ACPI host bridge controllers map PCI configuration space
(ECAM and ECAM-derivative) into the virtual address space through
ioremap() calls, that are non-cacheable device accesses on most
architectures, but may provide "bufferable" or "posted" write semantics
in architecture like eg ARM/ARM64 that allow ioremap'ed regions writes
to be buffered in the bus connecting the host CPU to the PCI fabric;
this behaviour, as underlined in the PCIe specifications, may trigger
transactions ordering rules and must be prevented.
Introduce a new generic and explicit API to create a memory mapping for
ECAM and ECAM-derivative config space area (and a corresponding generic
asm-generic header file) that defaults to ioremap_nocache() (which
should provide a sane default behaviour) and can be included by
all architectures that do not require an arch specific memory mapping
for ioremap_nopost() to guarantee non-posted writes behaviour.
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Cc: Russell King <linux@armlinux.org.uk>
Cc: Luis R. Rodriguez <mcgrof@kernel.org>
---
include/asm-generic/ioremap-nopost.h | 9 +++++++++
1 file changed, 9 insertions(+)
create mode 100644 include/asm-generic/ioremap-nopost.h
diff --git a/include/asm-generic/ioremap-nopost.h b/include/asm-generic/ioremap-nopost.h
new file mode 100644
index 0000000..015911f
--- /dev/null
+++ b/include/asm-generic/ioremap-nopost.h
@@ -0,0 +1,9 @@
+#ifndef __ASM_GENERIC_IOREMAP_NOPOST_H
+#define __ASM_GENERIC_IOREMAP_NOPOST_H
+
+static inline void __iomem *ioremap_nopost(phys_addr_t offset, size_t size)
+{
+ return ioremap_nocache(offset, size);
+}
+
+#endif /* __ASM_GENERIC_IOREMAP_NOPOST_H */
--
2.10.0
^ permalink raw reply related [flat|nested] 171+ messages in thread* [PATCH v3 04/32] asm-generic: add ioremap_nopost() remap interface
@ 2017-04-11 12:28 ` Lorenzo Pieralisi
0 siblings, 0 replies; 171+ messages in thread
From: Lorenzo Pieralisi @ 2017-04-11 12:28 UTC (permalink / raw)
To: linux-pci
Cc: Jonas Bonn, Rich Felker, Catalin Marinas, Will Deacon,
James E.J. Bottomley, David Howells, Max Filippov,
Paul Mackerras, Huacai Chen, Guan Xuetao, Thomas Gleixner,
Hans-Christian Egtvedt, linux-arch, Jesper Nilsson,
Lorenzo Pieralisi, Yoshinori Sato, Michael Ellerman,
Helge Deller, Russell King, Ingo Molnar, Geert Uytterhoeven,
Benjamin Herrenschmidt, Matt Turner, Haa
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.
Current DT and ACPI host bridge controllers map PCI configuration space
(ECAM and ECAM-derivative) into the virtual address space through
ioremap() calls, that are non-cacheable device accesses on most
architectures, but may provide "bufferable" or "posted" write semantics
in architecture like eg ARM/ARM64 that allow ioremap'ed regions writes
to be buffered in the bus connecting the host CPU to the PCI fabric;
this behaviour, as underlined in the PCIe specifications, may trigger
transactions ordering rules and must be prevented.
Introduce a new generic and explicit API to create a memory mapping for
ECAM and ECAM-derivative config space area (and a corresponding generic
asm-generic header file) that defaults to ioremap_nocache() (which
should provide a sane default behaviour) and can be included by
all architectures that do not require an arch specific memory mapping
for ioremap_nopost() to guarantee non-posted writes behaviour.
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Cc: Russell King <linux@armlinux.org.uk>
Cc: Luis R. Rodriguez <mcgrof@kernel.org>
---
include/asm-generic/ioremap-nopost.h | 9 +++++++++
1 file changed, 9 insertions(+)
create mode 100644 include/asm-generic/ioremap-nopost.h
diff --git a/include/asm-generic/ioremap-nopost.h b/include/asm-generic/ioremap-nopost.h
new file mode 100644
index 0000000..015911f
--- /dev/null
+++ b/include/asm-generic/ioremap-nopost.h
@@ -0,0 +1,9 @@
+#ifndef __ASM_GENERIC_IOREMAP_NOPOST_H
+#define __ASM_GENERIC_IOREMAP_NOPOST_H
+
+static inline void __iomem *ioremap_nopost(phys_addr_t offset, size_t size)
+{
+ return ioremap_nocache(offset, size);
+}
+
+#endif /* __ASM_GENERIC_IOREMAP_NOPOST_H */
--
2.10.0
^ permalink raw reply related [flat|nested] 171+ messages in thread* Re: [PATCH v3 04/32] asm-generic: add ioremap_nopost() remap interface
2017-04-11 12:28 ` Lorenzo Pieralisi
(?)
@ 2017-04-11 13:39 ` Benjamin Herrenschmidt
-1 siblings, 0 replies; 171+ messages in thread
From: Benjamin Herrenschmidt @ 2017-04-11 13:39 UTC (permalink / raw)
To: Lorenzo Pieralisi, linux-pci
Cc: Jonas Bonn, Rich Felker, Catalin Marinas, Will Deacon,
James E.J. Bottomley, David Howells, Max Filippov,
Paul Mackerras, Huacai Chen, Guan Xuetao, Thomas Gleixner,
Hans-Christian Egtvedt, linux-arch, Jesper Nilsson,
Yoshinori Sato, Michael Ellerman, Helge Deller, Russell King,
Ingo Molnar, Geert Uytterhoeven, Matt Turner, Haavard Skinnemoen,
Fenghua Yu, James Hogan, Chris Metcalf, Arnd Bergmann,
Heiko Carstens, Stefan Kristiansson, Mikael Starvik,
Ivan Kokshaysky, Bjorn Helgaas, Stafford Horne, linux-arm-kernel,
Richard Henderson, Chris Zankel, Michal Simek, Tony Luck,
Vineet Gupta, linux-kernel, Ralf Baechle, Richard Kuo,
Niklas Cassel, Luis R . Rodriguez, Martin Schwidefsky,
Ley Foon Tan, David S. Miller
T24gVHVlLCAyMDE3LTA0LTExIGF0IDEzOjI4ICswMTAwLCBMb3JlbnpvIFBpZXJhbGlzaSB3cm90
ZToKPiArc3RhdGljIGlubGluZSB2b2lkIF9faW9tZW0gKmlvcmVtYXBfbm9wb3N0KHBoeXNfYWRk
cl90IG9mZnNldCwKPiBzaXplX3Qgc2l6ZSkKPiArewo+ICvCoMKgwqDCoMKgwqDCoHJldHVybiBp
b3JlbWFwX25vY2FjaGUob2Zmc2V0LCBzaXplKTsKPiArfQo+ICsKCk5vIHRoaXMgaXMgd3Jvbmcg
YXMgSSBleHBsYWluZWQuCgpUaGlzIGlzIGEgc2VtYW50aWMgdGhhdCBzaW1wbHkgKmNhbm5vdCog
YmUgZ2VuZXJpY2FsbHkgcHJvdmlkZWQgYWNjcm9zcwphcmNoaXRlY3R1cmVzIGFzIGEgbWFwcGlu
ZyBhdHRyaWJ1dGUuCgpUaGUgc29sdXRpb24gdG8geW91ciBwcm9ibGVtIGxpZXMgZWxzZXdoZXJl
LgoKQ2hlZXJzLApCZW4uCgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX18KbGludXgtYXJtLWtlcm5lbCBtYWlsaW5nIGxpc3QKbGludXgtYXJtLWtlcm5lbEBs
aXN0cy5pbmZyYWRlYWQub3JnCmh0dHA6Ly9saXN0cy5pbmZyYWRlYWQub3JnL21haWxtYW4vbGlz
dGluZm8vbGludXgtYXJtLWtlcm5lbAo=
^ permalink raw reply [flat|nested] 171+ messages in thread
* [PATCH v3 04/32] asm-generic: add ioremap_nopost() remap interface
@ 2017-04-11 13:39 ` Benjamin Herrenschmidt
0 siblings, 0 replies; 171+ messages in thread
From: Benjamin Herrenschmidt @ 2017-04-11 13:39 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, 2017-04-11 at 13:28 +0100, Lorenzo Pieralisi wrote:
> +static inline void __iomem *ioremap_nopost(phys_addr_t offset,
> size_t size)
> +{
> +???????return ioremap_nocache(offset, size);
> +}
> +
No this is wrong as I explained.
This is a semantic that simply *cannot* be generically provided accross
architectures as a mapping attribute.
The solution to your problem lies elsewhere.
Cheers,
Ben.
^ permalink raw reply [flat|nested] 171+ messages in thread* Re: [PATCH v3 04/32] asm-generic: add ioremap_nopost() remap interface
@ 2017-04-11 13:39 ` Benjamin Herrenschmidt
0 siblings, 0 replies; 171+ messages in thread
From: Benjamin Herrenschmidt @ 2017-04-11 13:39 UTC (permalink / raw)
To: Lorenzo Pieralisi, linux-pci
Cc: Jonas Bonn, Rich Felker, Catalin Marinas, Will Deacon,
James E.J. Bottomley, David Howells, Max Filippov,
Paul Mackerras, Huacai Chen, Guan Xuetao, Thomas Gleixner,
Hans-Christian Egtvedt, linux-arch, Jesper Nilsson,
Yoshinori Sato, Michael Ellerman, Helge Deller, Russell King,
Ingo Molnar, Geert Uytterhoeven, Matt Turner, Haavard Skinnemoen,
Fenghua Yu, James Hogan
On Tue, 2017-04-11 at 13:28 +0100, Lorenzo Pieralisi wrote:
> +static inline void __iomem *ioremap_nopost(phys_addr_t offset,
> size_t size)
> +{
> + return ioremap_nocache(offset, size);
> +}
> +
No this is wrong as I explained.
This is a semantic that simply *cannot* be generically provided accross
architectures as a mapping attribute.
The solution to your problem lies elsewhere.
Cheers,
Ben.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 171+ messages in thread* Re: [PATCH v3 04/32] asm-generic: add ioremap_nopost() remap interface
2017-04-11 13:39 ` Benjamin Herrenschmidt
(?)
@ 2017-04-11 14:31 ` Lorenzo Pieralisi
-1 siblings, 0 replies; 171+ messages in thread
From: Lorenzo Pieralisi @ 2017-04-11 14:31 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Jonas Bonn, Rich Felker, linux-pci, Will Deacon,
James E.J. Bottomley, David Howells, Max Filippov,
Paul Mackerras, Huacai Chen, Guan Xuetao, Thomas Gleixner,
Hans-Christian Egtvedt, linux-arch, Jesper Nilsson,
Yoshinori Sato, Michael Ellerman, Helge Deller, Russell King,
Ingo Molnar, Geert Uytterhoeven, Catalin Marinas, Matt Turner,
Haavard Skinnemoen, Fenghua Yu, James Hogan, Chris Metcalf,
Arnd Bergmann, Heiko Carstens, Stefan Kristiansson,
Mikael Starvik, Ivan Kokshaysky, Bjorn Helgaas, Stafford Horne,
linux-arm-kernel, Richard Henderson, Chris Zankel, Michal Simek,
Tony Luck, Vineet Gupta, linux-kernel, Ralf Baechle, Richard Kuo,
Niklas Cassel, Luis R . Rodriguez, Martin Schwidefsky,
Ley Foon Tan, David S. Miller
On Tue, Apr 11, 2017 at 11:39:43PM +1000, Benjamin Herrenschmidt wrote:
> On Tue, 2017-04-11 at 13:28 +0100, Lorenzo Pieralisi wrote:
> > +static inline void __iomem *ioremap_nopost(phys_addr_t offset,
> > size_t size)
> > +{
> > +=A0=A0=A0=A0=A0=A0=A0return ioremap_nocache(offset, size);
> > +}
> > +
> =
> No this is wrong as I explained.
> =
> This is a semantic that simply *cannot* be generically provided accross
> architectures as a mapping attribute.
I agree that a default implementation does not make much sense. The
only solution to this, if we want the ioremap_nopost to be made available
to generic code (and drivers - ie DT PCI host bridge drivers on ARM/ARM64
are not arch code), is to make the ioremap_nopost() call return NULL
unless overriden by arch code that can provide its semantics.
Thanks,
Lorenzo
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 171+ messages in thread* [PATCH v3 04/32] asm-generic: add ioremap_nopost() remap interface
@ 2017-04-11 14:31 ` Lorenzo Pieralisi
0 siblings, 0 replies; 171+ messages in thread
From: Lorenzo Pieralisi @ 2017-04-11 14:31 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, Apr 11, 2017 at 11:39:43PM +1000, Benjamin Herrenschmidt wrote:
> On Tue, 2017-04-11 at 13:28 +0100, Lorenzo Pieralisi wrote:
> > +static inline void __iomem *ioremap_nopost(phys_addr_t offset,
> > size_t size)
> > +{
> > +???????return ioremap_nocache(offset, size);
> > +}
> > +
>
> No this is wrong as I explained.
>
> This is a semantic that simply *cannot* be generically provided accross
> architectures as a mapping attribute.
I agree that a default implementation does not make much sense. The
only solution to this, if we want the ioremap_nopost to be made available
to generic code (and drivers - ie DT PCI host bridge drivers on ARM/ARM64
are not arch code), is to make the ioremap_nopost() call return NULL
unless overriden by arch code that can provide its semantics.
Thanks,
Lorenzo
^ permalink raw reply [flat|nested] 171+ messages in thread* Re: [PATCH v3 04/32] asm-generic: add ioremap_nopost() remap interface
@ 2017-04-11 14:31 ` Lorenzo Pieralisi
0 siblings, 0 replies; 171+ messages in thread
From: Lorenzo Pieralisi @ 2017-04-11 14:31 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Jonas Bonn, Rich Felker, linux-pci, Will Deacon,
James E.J. Bottomley, David Howells, Max Filippov,
Paul Mackerras, Huacai Chen, Guan Xuetao, Thomas Gleixner,
Hans-Christian Egtvedt, linux-arch, Jesper Nilsson,
Yoshinori Sato, Michael Ellerman, Helge Deller, Russell King,
Ingo Molnar, Geert Uytterhoeven, Catalin Marinas, Matt Turner,
Haavard Skinnemoen, Fenghua Yu
On Tue, Apr 11, 2017 at 11:39:43PM +1000, Benjamin Herrenschmidt wrote:
> On Tue, 2017-04-11 at 13:28 +0100, Lorenzo Pieralisi wrote:
> > +static inline void __iomem *ioremap_nopost(phys_addr_t offset,
> > size_t size)
> > +{
> > + return ioremap_nocache(offset, size);
> > +}
> > +
>
> No this is wrong as I explained.
>
> This is a semantic that simply *cannot* be generically provided accross
> architectures as a mapping attribute.
I agree that a default implementation does not make much sense. The
only solution to this, if we want the ioremap_nopost to be made available
to generic code (and drivers - ie DT PCI host bridge drivers on ARM/ARM64
are not arch code), is to make the ioremap_nopost() call return NULL
unless overriden by arch code that can provide its semantics.
Thanks,
Lorenzo
^ permalink raw reply [flat|nested] 171+ messages in thread* Re: [PATCH v3 04/32] asm-generic: add ioremap_nopost() remap interface
2017-04-11 14:31 ` Lorenzo Pieralisi
(?)
@ 2017-04-11 23:14 ` Benjamin Herrenschmidt
-1 siblings, 0 replies; 171+ messages in thread
From: Benjamin Herrenschmidt @ 2017-04-11 23:14 UTC (permalink / raw)
To: Lorenzo Pieralisi
Cc: Jonas Bonn, Rich Felker, linux-pci, Will Deacon,
James E.J. Bottomley, David Howells, Max Filippov,
Paul Mackerras, Huacai Chen, Guan Xuetao, Thomas Gleixner,
Hans-Christian Egtvedt, linux-arch, Jesper Nilsson,
Yoshinori Sato, Michael Ellerman, Helge Deller, Russell King,
Ingo Molnar, Geert Uytterhoeven, Catalin Marinas, Matt Turner,
Haavard Skinnemoen, Fenghua Yu, James Hogan, Chris Metcalf,
Arnd Bergmann, Heiko Carstens, Stefan Kristiansson,
Mikael Starvik, Ivan Kokshaysky, Bjorn Helgaas, Stafford Horne,
linux-arm-kernel, Richard Henderson, Chris Zankel, Michal Simek,
Tony Luck, Vineet Gupta, linux-kernel, Ralf Baechle, Richard Kuo,
Niklas Cassel, Luis R . Rodriguez, Martin Schwidefsky,
Ley Foon Tan, David S. Miller
On Tue, 2017-04-11 at 15:31 +0100, Lorenzo Pieralisi wrote:
> > This is a semantic that simply *cannot* be generically provided accross
> > architectures as a mapping attribute.
>
> I agree that a default implementation does not make much sense. The
> only solution to this, if we want the ioremap_nopost to be made available
> to generic code (and drivers - ie DT PCI host bridge drivers on ARM/ARM64
> are not arch code), is to make the ioremap_nopost() call return NULL
> unless overriden by arch code that can provide its semantics.
That would be a better option.
You might be able to implement a fallback, for example by having the
config ops do a read back from the bridge.
Ben.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 171+ messages in thread
* [PATCH v3 04/32] asm-generic: add ioremap_nopost() remap interface
@ 2017-04-11 23:14 ` Benjamin Herrenschmidt
0 siblings, 0 replies; 171+ messages in thread
From: Benjamin Herrenschmidt @ 2017-04-11 23:14 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, 2017-04-11 at 15:31 +0100, Lorenzo Pieralisi wrote:
> > This is a semantic that simply *cannot* be generically provided accross
> > architectures as a mapping attribute.
>
> I agree that a default implementation does not make much sense. The
> only solution to this, if we want the ioremap_nopost to be made available
> to generic code (and drivers - ie DT PCI host bridge drivers on ARM/ARM64
> are not arch code), is to make the ioremap_nopost() call return NULL
> unless overriden by arch code that can provide its semantics.
That would be a better option.
You might be able to implement a fallback, for example by having the
config ops do a read back from the bridge.
Ben.
^ permalink raw reply [flat|nested] 171+ messages in thread
* Re: [PATCH v3 04/32] asm-generic: add ioremap_nopost() remap interface
@ 2017-04-11 23:14 ` Benjamin Herrenschmidt
0 siblings, 0 replies; 171+ messages in thread
From: Benjamin Herrenschmidt @ 2017-04-11 23:14 UTC (permalink / raw)
To: Lorenzo Pieralisi
Cc: Jonas Bonn, Rich Felker, linux-pci, Will Deacon,
James E.J. Bottomley, David Howells, Max Filippov,
Paul Mackerras, Huacai Chen, Guan Xuetao, Thomas Gleixner,
Hans-Christian Egtvedt, linux-arch, Jesper Nilsson,
Yoshinori Sato, Michael Ellerman, Helge Deller, Russell King,
Ingo Molnar, Geert Uytterhoeven, Catalin Marinas, Matt Turner,
Haavard Skinnemoen, Fenghua Yu
On Tue, 2017-04-11 at 15:31 +0100, Lorenzo Pieralisi wrote:
> > This is a semantic that simply *cannot* be generically provided accross
> > architectures as a mapping attribute.
>
> I agree that a default implementation does not make much sense. The
> only solution to this, if we want the ioremap_nopost to be made available
> to generic code (and drivers - ie DT PCI host bridge drivers on ARM/ARM64
> are not arch code), is to make the ioremap_nopost() call return NULL
> unless overriden by arch code that can provide its semantics.
That would be a better option.
You might be able to implement a fallback, for example by having the
config ops do a read back from the bridge.
Ben.
^ permalink raw reply [flat|nested] 171+ messages in thread
* Re: [PATCH v3 04/32] asm-generic: add ioremap_nopost() remap interface
2017-04-11 23:14 ` Benjamin Herrenschmidt
(?)
@ 2017-04-12 10:00 ` Lorenzo Pieralisi
-1 siblings, 0 replies; 171+ messages in thread
From: Lorenzo Pieralisi @ 2017-04-12 10:00 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Jonas Bonn, Rich Felker, linux-pci, Will Deacon,
James E.J. Bottomley, David Howells, Max Filippov,
Paul Mackerras, Huacai Chen, Guan Xuetao, Thomas Gleixner,
Hans-Christian Egtvedt, linux-arch, Jesper Nilsson,
Yoshinori Sato, Michael Ellerman, Helge Deller, Russell King,
Ingo Molnar, Geert Uytterhoeven, Catalin Marinas, Matt Turner,
Haavard Skinnemoen, Fenghua Yu, James Hogan, Chris Metcalf,
Arnd Bergmann, Heiko Carstens, Stefan Kristiansson,
Mikael Starvik, Ivan Kokshaysky, Bjorn Helgaas, Stafford Horne,
linux-arm-kernel, Richard Henderson, Chris Zankel, Michal Simek,
Tony Luck, Vineet Gupta, linux-kernel, Ralf Baechle, Richard Kuo,
Niklas Cassel, Luis R . Rodriguez, Martin Schwidefsky,
Ley Foon Tan, David S. Miller
On Wed, Apr 12, 2017 at 09:14:07AM +1000, Benjamin Herrenschmidt wrote:
> On Tue, 2017-04-11 at 15:31 +0100, Lorenzo Pieralisi wrote:
> > > This is a semantic that simply *cannot* be generically provided accross
> > > architectures as a mapping attribute.
> >
> > I agree that a default implementation does not make much sense. The
> > only solution to this, if we want the ioremap_nopost to be made available
> > to generic code (and drivers - ie DT PCI host bridge drivers on ARM/ARM64
> > are not arch code), is to make the ioremap_nopost() call return NULL
> > unless overriden by arch code that can provide its semantics.
>
> That would be a better option.
I think that's what I will implement which basically means I will
replace the default:
static inline void __iomem *ioremap_nopost(phys_addr_t offset, size_t size)
{
return ioremap_nocache(offset, size);
}
with
static inline void __iomem *ioremap_nopost(phys_addr_t offset, size_t size)
{
return NULL;
}
If an arch can override ioremap_nopost() with sensible mapping
attributes (or whatever make it enforceable) it does, if it can't
any ioremap_nopost() usage will result in a mapping failure, if you
see any other viable solution please shout.
Thanks,
Lorenzo
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 171+ messages in thread* [PATCH v3 04/32] asm-generic: add ioremap_nopost() remap interface
@ 2017-04-12 10:00 ` Lorenzo Pieralisi
0 siblings, 0 replies; 171+ messages in thread
From: Lorenzo Pieralisi @ 2017-04-12 10:00 UTC (permalink / raw)
To: linux-arm-kernel
On Wed, Apr 12, 2017 at 09:14:07AM +1000, Benjamin Herrenschmidt wrote:
> On Tue, 2017-04-11 at 15:31 +0100, Lorenzo Pieralisi wrote:
> > > This is a semantic that simply *cannot* be generically provided accross
> > > architectures as a mapping attribute.
> >
> > I agree that a default implementation does not make much sense. The
> > only solution to this, if we want the ioremap_nopost to be made available
> > to generic code (and drivers - ie DT PCI host bridge drivers on ARM/ARM64
> > are not arch code), is to make the ioremap_nopost() call return NULL
> > unless overriden by arch code that can provide its semantics.
>
> That would be a better option.
I think that's what I will implement which basically means I will
replace the default:
static inline void __iomem *ioremap_nopost(phys_addr_t offset, size_t size)
{
return ioremap_nocache(offset, size);
}
with
static inline void __iomem *ioremap_nopost(phys_addr_t offset, size_t size)
{
return NULL;
}
If an arch can override ioremap_nopost() with sensible mapping
attributes (or whatever make it enforceable) it does, if it can't
any ioremap_nopost() usage will result in a mapping failure, if you
see any other viable solution please shout.
Thanks,
Lorenzo
^ permalink raw reply [flat|nested] 171+ messages in thread* Re: [PATCH v3 04/32] asm-generic: add ioremap_nopost() remap interface
@ 2017-04-12 10:00 ` Lorenzo Pieralisi
0 siblings, 0 replies; 171+ messages in thread
From: Lorenzo Pieralisi @ 2017-04-12 10:00 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Jonas Bonn, Rich Felker, linux-pci, Will Deacon,
James E.J. Bottomley, David Howells, Max Filippov,
Paul Mackerras, Huacai Chen, Guan Xuetao, Thomas Gleixner,
Hans-Christian Egtvedt, linux-arch, Jesper Nilsson,
Yoshinori Sato, Michael Ellerman, Helge Deller, Russell King,
Ingo Molnar, Geert Uytterhoeven, Catalin Marinas, Matt Turner,
Haavard Skinnemoen, Fenghua Yu
On Wed, Apr 12, 2017 at 09:14:07AM +1000, Benjamin Herrenschmidt wrote:
> On Tue, 2017-04-11 at 15:31 +0100, Lorenzo Pieralisi wrote:
> > > This is a semantic that simply *cannot* be generically provided accross
> > > architectures as a mapping attribute.
> >
> > I agree that a default implementation does not make much sense. The
> > only solution to this, if we want the ioremap_nopost to be made available
> > to generic code (and drivers - ie DT PCI host bridge drivers on ARM/ARM64
> > are not arch code), is to make the ioremap_nopost() call return NULL
> > unless overriden by arch code that can provide its semantics.
>
> That would be a better option.
I think that's what I will implement which basically means I will
replace the default:
static inline void __iomem *ioremap_nopost(phys_addr_t offset, size_t size)
{
return ioremap_nocache(offset, size);
}
with
static inline void __iomem *ioremap_nopost(phys_addr_t offset, size_t size)
{
return NULL;
}
If an arch can override ioremap_nopost() with sensible mapping
attributes (or whatever make it enforceable) it does, if it can't
any ioremap_nopost() usage will result in a mapping failure, if you
see any other viable solution please shout.
Thanks,
Lorenzo
^ permalink raw reply [flat|nested] 171+ messages in thread
* Re: [PATCH v3 04/32] asm-generic: add ioremap_nopost() remap interface
2017-04-11 13:39 ` Benjamin Herrenschmidt
(?)
@ 2017-04-12 11:20 ` Russell King - ARM Linux
-1 siblings, 0 replies; 171+ messages in thread
From: Russell King - ARM Linux @ 2017-04-12 11:20 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Jonas Bonn, Rich Felker, linux-pci, Will Deacon, David Howells,
Max Filippov, Paul Mackerras, Huacai Chen, Guan Xuetao,
Thomas Gleixner, Hans-Christian Egtvedt, linux-arch,
Jesper Nilsson, Lorenzo Pieralisi, Yoshinori Sato,
Michael Ellerman, Helge Deller, James E.J. Bottomley,
Ingo Molnar, Geert Uytterhoeven, Catalin Marinas, Matt Turner,
Haavard Skinnemoen, Fenghua Yu, James Hogan, Chris Metcalf,
Arnd Bergmann, Heiko Carstens, Stefan Kristiansson,
Mikael Starvik, Ivan Kokshaysky, Bjorn Helgaas, Stafford Horne,
linux-arm-kernel, Richard Henderson, Chris Zankel, Michal Simek,
Tony Luck, Vineet Gupta, linux-kernel, Ralf Baechle, Richard Kuo,
Niklas Cassel, Luis R . Rodriguez, Martin Schwidefsky,
Ley Foon Tan, David S. Miller
On Tue, Apr 11, 2017 at 11:39:43PM +1000, Benjamin Herrenschmidt wrote:
> On Tue, 2017-04-11 at 13:28 +0100, Lorenzo Pieralisi wrote:
> > +static inline void __iomem *ioremap_nopost(phys_addr_t offset,
> > size_t size)
> > +{
> > +=A0=A0=A0=A0=A0=A0=A0return ioremap_nocache(offset, size);
> > +}
> > +
> =
> No this is wrong as I explained.
> =
> This is a semantic that simply *cannot* be generically provided accross
> architectures as a mapping attribute.
> =
> The solution to your problem lies elsewhere.
I disagree. Sure, it may not be supportable across all architectures,
but we're not introducing something brand new here.
What we're trying to do is to fix some _existing_ drivers that are
already using ioremap() to map the PCI IO and configuration spaces.
Maybe it would help if those drivers were part of this patch set,
rather than the patch set just introducing a whole new architecture
interface without really showing where the problem drivers are.
The issue here is that if we make this new ioremap_nopost() fail by
returning NULL if an architecture does not provide an implementation,
then these drivers are going to start failing on such architectures.
It is only safe to do that where we know for certain that the drivers
are not used - but I don't think that's the case here (it's difficult
to tell, because no drivers are updated in this series, so we don't
know which are going to be affected.)
So, the question is:
- is it better to provide a default implementation which provides the
functionality that existing drivers are _already_ using, albiet not
entirely correctly.
or:
- is it better to break drivers on architectures when they're converted
to fix up this issue.
What, I suppose, we could do is not bother with a default implementation,
but instead litter drivers with:
+#ifdef ioremap_post
+ base =3D ioremap_post(...);
+#else
base =3D ioremap(...);
+#endif
which gets around your objection - not providing a default that's weaker
than required, but also not breaking the drivers. The problem is that
we end up littering drivers with ifdefs.
However, I'm willing to bet that the architectures that you're saying
will not be able to support the weaker semantic won't have any need to
use these drivers, or if they do, the drivers will need the method of
accessing stuff like PCI IO and configuration spaces radically altered.
So, maybe the best solution is to not provide any kind of default
implementation, add a HAVE_IOREMAP_POST Kconfig symbol, have architectures
select that when they do provide ioremap_post(), and make the drivers
depend on that (so we don't end up trying to build these drivers on
architectures where they can never work.) Down side to that is reduced
build coverage.
-- =
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 171+ messages in thread* [PATCH v3 04/32] asm-generic: add ioremap_nopost() remap interface
@ 2017-04-12 11:20 ` Russell King - ARM Linux
0 siblings, 0 replies; 171+ messages in thread
From: Russell King - ARM Linux @ 2017-04-12 11:20 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, Apr 11, 2017 at 11:39:43PM +1000, Benjamin Herrenschmidt wrote:
> On Tue, 2017-04-11 at 13:28 +0100, Lorenzo Pieralisi wrote:
> > +static inline void __iomem *ioremap_nopost(phys_addr_t offset,
> > size_t size)
> > +{
> > +???????return ioremap_nocache(offset, size);
> > +}
> > +
>
> No this is wrong as I explained.
>
> This is a semantic that simply *cannot* be generically provided accross
> architectures as a mapping attribute.
>
> The solution to your problem lies elsewhere.
I disagree. Sure, it may not be supportable across all architectures,
but we're not introducing something brand new here.
What we're trying to do is to fix some _existing_ drivers that are
already using ioremap() to map the PCI IO and configuration spaces.
Maybe it would help if those drivers were part of this patch set,
rather than the patch set just introducing a whole new architecture
interface without really showing where the problem drivers are.
The issue here is that if we make this new ioremap_nopost() fail by
returning NULL if an architecture does not provide an implementation,
then these drivers are going to start failing on such architectures.
It is only safe to do that where we know for certain that the drivers
are not used - but I don't think that's the case here (it's difficult
to tell, because no drivers are updated in this series, so we don't
know which are going to be affected.)
So, the question is:
- is it better to provide a default implementation which provides the
functionality that existing drivers are _already_ using, albiet not
entirely correctly.
or:
- is it better to break drivers on architectures when they're converted
to fix up this issue.
What, I suppose, we could do is not bother with a default implementation,
but instead litter drivers with:
+#ifdef ioremap_post
+ base = ioremap_post(...);
+#else
base = ioremap(...);
+#endif
which gets around your objection - not providing a default that's weaker
than required, but also not breaking the drivers. The problem is that
we end up littering drivers with ifdefs.
However, I'm willing to bet that the architectures that you're saying
will not be able to support the weaker semantic won't have any need to
use these drivers, or if they do, the drivers will need the method of
accessing stuff like PCI IO and configuration spaces radically altered.
So, maybe the best solution is to not provide any kind of default
implementation, add a HAVE_IOREMAP_POST Kconfig symbol, have architectures
select that when they do provide ioremap_post(), and make the drivers
depend on that (so we don't end up trying to build these drivers on
architectures where they can never work.) Down side to that is reduced
build coverage.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply [flat|nested] 171+ messages in thread* Re: [PATCH v3 04/32] asm-generic: add ioremap_nopost() remap interface
@ 2017-04-12 11:20 ` Russell King - ARM Linux
0 siblings, 0 replies; 171+ messages in thread
From: Russell King - ARM Linux @ 2017-04-12 11:20 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Jonas Bonn, Rich Felker, linux-pci, Will Deacon, David Howells,
Max Filippov, Paul Mackerras, Huacai Chen, Guan Xuetao,
Thomas Gleixner, Hans-Christian Egtvedt, linux-arch,
Jesper Nilsson, Lorenzo Pieralisi, Yoshinori Sato,
Michael Ellerman, Helge Deller, James E.J. Bottomley,
Ingo Molnar, Geert Uytterhoeven, Catalin Marinas, Matt Turner,
Haavard Skinnemoen, Fenghua Yu
On Tue, Apr 11, 2017 at 11:39:43PM +1000, Benjamin Herrenschmidt wrote:
> On Tue, 2017-04-11 at 13:28 +0100, Lorenzo Pieralisi wrote:
> > +static inline void __iomem *ioremap_nopost(phys_addr_t offset,
> > size_t size)
> > +{
> > + return ioremap_nocache(offset, size);
> > +}
> > +
>
> No this is wrong as I explained.
>
> This is a semantic that simply *cannot* be generically provided accross
> architectures as a mapping attribute.
>
> The solution to your problem lies elsewhere.
I disagree. Sure, it may not be supportable across all architectures,
but we're not introducing something brand new here.
What we're trying to do is to fix some _existing_ drivers that are
already using ioremap() to map the PCI IO and configuration spaces.
Maybe it would help if those drivers were part of this patch set,
rather than the patch set just introducing a whole new architecture
interface without really showing where the problem drivers are.
The issue here is that if we make this new ioremap_nopost() fail by
returning NULL if an architecture does not provide an implementation,
then these drivers are going to start failing on such architectures.
It is only safe to do that where we know for certain that the drivers
are not used - but I don't think that's the case here (it's difficult
to tell, because no drivers are updated in this series, so we don't
know which are going to be affected.)
So, the question is:
- is it better to provide a default implementation which provides the
functionality that existing drivers are _already_ using, albiet not
entirely correctly.
or:
- is it better to break drivers on architectures when they're converted
to fix up this issue.
What, I suppose, we could do is not bother with a default implementation,
but instead litter drivers with:
+#ifdef ioremap_post
+ base = ioremap_post(...);
+#else
base = ioremap(...);
+#endif
which gets around your objection - not providing a default that's weaker
than required, but also not breaking the drivers. The problem is that
we end up littering drivers with ifdefs.
However, I'm willing to bet that the architectures that you're saying
will not be able to support the weaker semantic won't have any need to
use these drivers, or if they do, the drivers will need the method of
accessing stuff like PCI IO and configuration spaces radically altered.
So, maybe the best solution is to not provide any kind of default
implementation, add a HAVE_IOREMAP_POST Kconfig symbol, have architectures
select that when they do provide ioremap_post(), and make the drivers
depend on that (so we don't end up trying to build these drivers on
architectures where they can never work.) Down side to that is reduced
build coverage.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply [flat|nested] 171+ messages in thread* Re: [PATCH v3 04/32] asm-generic: add ioremap_nopost() remap interface
2017-04-12 11:20 ` Russell King - ARM Linux
(?)
@ 2017-04-18 15:49 ` Lorenzo Pieralisi
-1 siblings, 0 replies; 171+ messages in thread
From: Lorenzo Pieralisi @ 2017-04-18 15:49 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: Jonas Bonn, Rich Felker, Catalin Marinas, Will Deacon,
David Howells, Max Filippov, Paul Mackerras, Huacai Chen,
Guan Xuetao, Thomas Gleixner, Hans-Christian Egtvedt, linux-arch,
Jesper Nilsson, Yoshinori Sato, Michael Ellerman, Helge Deller,
James E.J. Bottomley, Ingo Molnar, Geert Uytterhoeven,
Benjamin Herrenschmidt, Matt Turner, Haavard Skinnemoen,
Fenghua Yu, James Hogan, Chris Metcalf, Arnd Bergmann,
Heiko Carstens, Stefan Kristiansson, Mikael Starvik,
Ivan Kokshaysky, Bjorn Helgaas, Stafford Horne, linux-arm-kernel,
Richard Henderson, Chris Zankel, Michal Simek, Tony Luck,
linux-pci, Vineet Gupta, linux-kernel, Ralf Baechle, Richard Kuo,
Niklas Cassel, Luis R . Rodriguez, Martin Schwidefsky,
Ley Foon Tan, David S. Miller
On Wed, Apr 12, 2017 at 12:20:22PM +0100, Russell King - ARM Linux wrote:
> On Tue, Apr 11, 2017 at 11:39:43PM +1000, Benjamin Herrenschmidt wrote:
> > On Tue, 2017-04-11 at 13:28 +0100, Lorenzo Pieralisi wrote:
> > > +static inline void __iomem *ioremap_nopost(phys_addr_t offset,
> > > size_t size)
> > > +{
> > > +=A0=A0=A0=A0=A0=A0=A0return ioremap_nocache(offset, size);
> > > +}
> > > +
> > =
> > No this is wrong as I explained.
> > =
> > This is a semantic that simply *cannot* be generically provided accross
> > architectures as a mapping attribute.
> > =
> > The solution to your problem lies elsewhere.
> =
> I disagree. Sure, it may not be supportable across all architectures,
> but we're not introducing something brand new here.
> =
> What we're trying to do is to fix some _existing_ drivers that are
> already using ioremap() to map the PCI IO and configuration spaces.
> Maybe it would help if those drivers were part of this patch set,
> rather than the patch set just introducing a whole new architecture
> interface without really showing where the problem drivers are.
> =
> The issue here is that if we make this new ioremap_nopost() fail by
> returning NULL if an architecture does not provide an implementation,
> then these drivers are going to start failing on such architectures.
> =
> It is only safe to do that where we know for certain that the drivers
> are not used - but I don't think that's the case here (it's difficult
> to tell, because no drivers are updated in this series, so we don't
> know which are going to be affected.)
> =
> So, the question is:
> =
> - is it better to provide a default implementation which provides the
> functionality that existing drivers are _already_ using, albiet not
> entirely correctly.
> =
> or:
> =
> - is it better to break drivers on architectures when they're converted
> to fix up this issue.
> =
> What, I suppose, we could do is not bother with a default implementation,
> but instead litter drivers with:
> =
> +#ifdef ioremap_post
> + base =3D ioremap_post(...);
> +#else
> base =3D ioremap(...);
> +#endif
> =
> which gets around your objection - not providing a default that's weaker
> than required, but also not breaking the drivers. The problem is that
> we end up littering drivers with ifdefs.
> =
> However, I'm willing to bet that the architectures that you're saying
> will not be able to support the weaker semantic won't have any need to
> use these drivers, or if they do, the drivers will need the method of
> accessing stuff like PCI IO and configuration spaces radically altered.
> =
> So, maybe the best solution is to not provide any kind of default
> implementation, add a HAVE_IOREMAP_POST Kconfig symbol, have architectures
> select that when they do provide ioremap_post(), and make the drivers
> depend on that (so we don't end up trying to build these drivers on
> architectures where they can never work.) Down side to that is reduced
> build coverage.
I can do that yes, which already means I have to know if eg microblaze
(drivers/pci/host/pcie-xilinx.c) can provide a mapping with nonposted
writes semantics, otherwise it is a dead-end.
Another option would be going back to what v1 did, namely, to implement
a pci_remap_cfgspace() interface (it is the _nopost() suffix that stirred
debate - nobody would object to having a default pci_remap_cfgspace()
implementation that defaults to ioremap_nocache(), I know Bjorn does not
like it to be PCI specific, just adding an option on the table to make
progress).
Thanks,
Lorenzo
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 171+ messages in thread* [PATCH v3 04/32] asm-generic: add ioremap_nopost() remap interface
@ 2017-04-18 15:49 ` Lorenzo Pieralisi
0 siblings, 0 replies; 171+ messages in thread
From: Lorenzo Pieralisi @ 2017-04-18 15:49 UTC (permalink / raw)
To: linux-arm-kernel
On Wed, Apr 12, 2017 at 12:20:22PM +0100, Russell King - ARM Linux wrote:
> On Tue, Apr 11, 2017 at 11:39:43PM +1000, Benjamin Herrenschmidt wrote:
> > On Tue, 2017-04-11 at 13:28 +0100, Lorenzo Pieralisi wrote:
> > > +static inline void __iomem *ioremap_nopost(phys_addr_t offset,
> > > size_t size)
> > > +{
> > > +???????return ioremap_nocache(offset, size);
> > > +}
> > > +
> >
> > No this is wrong as I explained.
> >
> > This is a semantic that simply *cannot* be generically provided accross
> > architectures as a mapping attribute.
> >
> > The solution to your problem lies elsewhere.
>
> I disagree. Sure, it may not be supportable across all architectures,
> but we're not introducing something brand new here.
>
> What we're trying to do is to fix some _existing_ drivers that are
> already using ioremap() to map the PCI IO and configuration spaces.
> Maybe it would help if those drivers were part of this patch set,
> rather than the patch set just introducing a whole new architecture
> interface without really showing where the problem drivers are.
>
> The issue here is that if we make this new ioremap_nopost() fail by
> returning NULL if an architecture does not provide an implementation,
> then these drivers are going to start failing on such architectures.
>
> It is only safe to do that where we know for certain that the drivers
> are not used - but I don't think that's the case here (it's difficult
> to tell, because no drivers are updated in this series, so we don't
> know which are going to be affected.)
>
> So, the question is:
>
> - is it better to provide a default implementation which provides the
> functionality that existing drivers are _already_ using, albiet not
> entirely correctly.
>
> or:
>
> - is it better to break drivers on architectures when they're converted
> to fix up this issue.
>
> What, I suppose, we could do is not bother with a default implementation,
> but instead litter drivers with:
>
> +#ifdef ioremap_post
> + base = ioremap_post(...);
> +#else
> base = ioremap(...);
> +#endif
>
> which gets around your objection - not providing a default that's weaker
> than required, but also not breaking the drivers. The problem is that
> we end up littering drivers with ifdefs.
>
> However, I'm willing to bet that the architectures that you're saying
> will not be able to support the weaker semantic won't have any need to
> use these drivers, or if they do, the drivers will need the method of
> accessing stuff like PCI IO and configuration spaces radically altered.
>
> So, maybe the best solution is to not provide any kind of default
> implementation, add a HAVE_IOREMAP_POST Kconfig symbol, have architectures
> select that when they do provide ioremap_post(), and make the drivers
> depend on that (so we don't end up trying to build these drivers on
> architectures where they can never work.) Down side to that is reduced
> build coverage.
I can do that yes, which already means I have to know if eg microblaze
(drivers/pci/host/pcie-xilinx.c) can provide a mapping with nonposted
writes semantics, otherwise it is a dead-end.
Another option would be going back to what v1 did, namely, to implement
a pci_remap_cfgspace() interface (it is the _nopost() suffix that stirred
debate - nobody would object to having a default pci_remap_cfgspace()
implementation that defaults to ioremap_nocache(), I know Bjorn does not
like it to be PCI specific, just adding an option on the table to make
progress).
Thanks,
Lorenzo
^ permalink raw reply [flat|nested] 171+ messages in thread* Re: [PATCH v3 04/32] asm-generic: add ioremap_nopost() remap interface
@ 2017-04-18 15:49 ` Lorenzo Pieralisi
0 siblings, 0 replies; 171+ messages in thread
From: Lorenzo Pieralisi @ 2017-04-18 15:49 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: Jonas Bonn, Rich Felker, Catalin Marinas, Will Deacon,
David Howells, Max Filippov, Paul Mackerras, Huacai Chen,
Guan Xuetao, Thomas Gleixner, Hans-Christian Egtvedt, linux-arch,
Jesper Nilsson, Yoshinori Sato, Michael Ellerman, Helge Deller,
James E.J. Bottomley, Ingo Molnar, Geert Uytterhoeven,
Benjamin Herrenschmidt, Matt Turner, Haavard Skinnemoen,
Fenghua Yu
On Wed, Apr 12, 2017 at 12:20:22PM +0100, Russell King - ARM Linux wrote:
> On Tue, Apr 11, 2017 at 11:39:43PM +1000, Benjamin Herrenschmidt wrote:
> > On Tue, 2017-04-11 at 13:28 +0100, Lorenzo Pieralisi wrote:
> > > +static inline void __iomem *ioremap_nopost(phys_addr_t offset,
> > > size_t size)
> > > +{
> > > + return ioremap_nocache(offset, size);
> > > +}
> > > +
> >
> > No this is wrong as I explained.
> >
> > This is a semantic that simply *cannot* be generically provided accross
> > architectures as a mapping attribute.
> >
> > The solution to your problem lies elsewhere.
>
> I disagree. Sure, it may not be supportable across all architectures,
> but we're not introducing something brand new here.
>
> What we're trying to do is to fix some _existing_ drivers that are
> already using ioremap() to map the PCI IO and configuration spaces.
> Maybe it would help if those drivers were part of this patch set,
> rather than the patch set just introducing a whole new architecture
> interface without really showing where the problem drivers are.
>
> The issue here is that if we make this new ioremap_nopost() fail by
> returning NULL if an architecture does not provide an implementation,
> then these drivers are going to start failing on such architectures.
>
> It is only safe to do that where we know for certain that the drivers
> are not used - but I don't think that's the case here (it's difficult
> to tell, because no drivers are updated in this series, so we don't
> know which are going to be affected.)
>
> So, the question is:
>
> - is it better to provide a default implementation which provides the
> functionality that existing drivers are _already_ using, albiet not
> entirely correctly.
>
> or:
>
> - is it better to break drivers on architectures when they're converted
> to fix up this issue.
>
> What, I suppose, we could do is not bother with a default implementation,
> but instead litter drivers with:
>
> +#ifdef ioremap_post
> + base = ioremap_post(...);
> +#else
> base = ioremap(...);
> +#endif
>
> which gets around your objection - not providing a default that's weaker
> than required, but also not breaking the drivers. The problem is that
> we end up littering drivers with ifdefs.
>
> However, I'm willing to bet that the architectures that you're saying
> will not be able to support the weaker semantic won't have any need to
> use these drivers, or if they do, the drivers will need the method of
> accessing stuff like PCI IO and configuration spaces radically altered.
>
> So, maybe the best solution is to not provide any kind of default
> implementation, add a HAVE_IOREMAP_POST Kconfig symbol, have architectures
> select that when they do provide ioremap_post(), and make the drivers
> depend on that (so we don't end up trying to build these drivers on
> architectures where they can never work.) Down side to that is reduced
> build coverage.
I can do that yes, which already means I have to know if eg microblaze
(drivers/pci/host/pcie-xilinx.c) can provide a mapping with nonposted
writes semantics, otherwise it is a dead-end.
Another option would be going back to what v1 did, namely, to implement
a pci_remap_cfgspace() interface (it is the _nopost() suffix that stirred
debate - nobody would object to having a default pci_remap_cfgspace()
implementation that defaults to ioremap_nocache(), I know Bjorn does not
like it to be PCI specific, just adding an option on the table to make
progress).
Thanks,
Lorenzo
^ permalink raw reply [flat|nested] 171+ messages in thread* Re: [PATCH v3 04/32] asm-generic: add ioremap_nopost() remap interface
2017-04-18 15:49 ` Lorenzo Pieralisi
(?)
@ 2017-04-18 16:31 ` Bjorn Helgaas
-1 siblings, 0 replies; 171+ messages in thread
From: Bjorn Helgaas @ 2017-04-18 16:31 UTC (permalink / raw)
To: Lorenzo Pieralisi
Cc: Jonas Bonn, Rich Felker, Catalin Marinas, Will Deacon,
James E.J. Bottomley, David Howells, Max Filippov,
Paul Mackerras, Huacai Chen, Guan Xuetao, Thomas Gleixner,
Hans-Christian Egtvedt, Linux-Arch, Jesper Nilsson,
Yoshinori Sato, Michael Ellerman, Helge Deller,
Russell King - ARM Linux, Ingo Molnar, Geert Uytterhoeven,
Benjamin Herrenschmidt, Matt Turner, Haavard Skinnemoen,
Fenghua Yu, James Hogan, Chris Metcalf, Arnd Bergmann,
Heiko Carstens, Stefan Kristiansson, Mikael Starvik,
Ivan Kokshaysky, Stafford Horne, linux-arm, Richard Henderson,
Chris Zankel, Michal Simek, Tony Luck, linux-pci, Vineet Gupta,
linux-kernel, Ralf Baechle, Richard Kuo, Niklas Cassel,
Luis R . Rodriguez, Martin Schwidefsky, Ley Foon Tan,
David S. Miller
On Tue, Apr 18, 2017 at 10:49 AM, Lorenzo Pieralisi
<lorenzo.pieralisi@arm.com> wrote:
> On Wed, Apr 12, 2017 at 12:20:22PM +0100, Russell King - ARM Linux wrote:
>> On Tue, Apr 11, 2017 at 11:39:43PM +1000, Benjamin Herrenschmidt wrote:
>> > On Tue, 2017-04-11 at 13:28 +0100, Lorenzo Pieralisi wrote:
>> > > +static inline void __iomem *ioremap_nopost(phys_addr_t offset,
>> > > size_t size)
>> > > +{
>> > > + return ioremap_nocache(offset, size);
>> > > +}
>> > > +
>> >
>> > No this is wrong as I explained.
>> >
>> > This is a semantic that simply *cannot* be generically provided accross
>> > architectures as a mapping attribute.
>> >
>> > The solution to your problem lies elsewhere.
>>
>> I disagree. Sure, it may not be supportable across all architectures,
>> but we're not introducing something brand new here.
>>
>> What we're trying to do is to fix some _existing_ drivers that are
>> already using ioremap() to map the PCI IO and configuration spaces.
>> Maybe it would help if those drivers were part of this patch set,
>> rather than the patch set just introducing a whole new architecture
>> interface without really showing where the problem drivers are.
>>
>> The issue here is that if we make this new ioremap_nopost() fail by
>> returning NULL if an architecture does not provide an implementation,
>> then these drivers are going to start failing on such architectures.
>>
>> It is only safe to do that where we know for certain that the drivers
>> are not used - but I don't think that's the case here (it's difficult
>> to tell, because no drivers are updated in this series, so we don't
>> know which are going to be affected.)
>>
>> So, the question is:
>>
>> - is it better to provide a default implementation which provides the
>> functionality that existing drivers are _already_ using, albiet not
>> entirely correctly.
>>
>> or:
>>
>> - is it better to break drivers on architectures when they're converted
>> to fix up this issue.
>>
>> What, I suppose, we could do is not bother with a default implementation,
>> but instead litter drivers with:
>>
>> +#ifdef ioremap_post
>> + base = ioremap_post(...);
>> +#else
>> base = ioremap(...);
>> +#endif
>>
>> which gets around your objection - not providing a default that's weaker
>> than required, but also not breaking the drivers. The problem is that
>> we end up littering drivers with ifdefs.
>>
>> However, I'm willing to bet that the architectures that you're saying
>> will not be able to support the weaker semantic won't have any need to
>> use these drivers, or if they do, the drivers will need the method of
>> accessing stuff like PCI IO and configuration spaces radically altered.
>>
>> So, maybe the best solution is to not provide any kind of default
>> implementation, add a HAVE_IOREMAP_POST Kconfig symbol, have architectures
>> select that when they do provide ioremap_post(), and make the drivers
>> depend on that (so we don't end up trying to build these drivers on
>> architectures where they can never work.) Down side to that is reduced
>> build coverage.
>
> I can do that yes, which already means I have to know if eg microblaze
> (drivers/pci/host/pcie-xilinx.c) can provide a mapping with nonposted
> writes semantics, otherwise it is a dead-end.
>
> Another option would be going back to what v1 did, namely, to implement
> a pci_remap_cfgspace() interface (it is the _nopost() suffix that stirred
> debate - nobody would object to having a default pci_remap_cfgspace()
> implementation that defaults to ioremap_nocache(), I know Bjorn does not
> like it to be PCI specific, just adding an option on the table to make
> progress).
The reason I objected to pci_remap_cfgspace() was that I thought
ioremap_nopost() was implementable across arches. That turned out not
to be true, so I'm fine with calling it pci_remap_cfgspace(). Maybe
it's worth a note in the default implementation that arches should
override it with a non-postable version if they can.
Bjorn
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 171+ messages in thread* [PATCH v3 04/32] asm-generic: add ioremap_nopost() remap interface
@ 2017-04-18 16:31 ` Bjorn Helgaas
0 siblings, 0 replies; 171+ messages in thread
From: Bjorn Helgaas @ 2017-04-18 16:31 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, Apr 18, 2017 at 10:49 AM, Lorenzo Pieralisi
<lorenzo.pieralisi@arm.com> wrote:
> On Wed, Apr 12, 2017 at 12:20:22PM +0100, Russell King - ARM Linux wrote:
>> On Tue, Apr 11, 2017 at 11:39:43PM +1000, Benjamin Herrenschmidt wrote:
>> > On Tue, 2017-04-11 at 13:28 +0100, Lorenzo Pieralisi wrote:
>> > > +static inline void __iomem *ioremap_nopost(phys_addr_t offset,
>> > > size_t size)
>> > > +{
>> > > + return ioremap_nocache(offset, size);
>> > > +}
>> > > +
>> >
>> > No this is wrong as I explained.
>> >
>> > This is a semantic that simply *cannot* be generically provided accross
>> > architectures as a mapping attribute.
>> >
>> > The solution to your problem lies elsewhere.
>>
>> I disagree. Sure, it may not be supportable across all architectures,
>> but we're not introducing something brand new here.
>>
>> What we're trying to do is to fix some _existing_ drivers that are
>> already using ioremap() to map the PCI IO and configuration spaces.
>> Maybe it would help if those drivers were part of this patch set,
>> rather than the patch set just introducing a whole new architecture
>> interface without really showing where the problem drivers are.
>>
>> The issue here is that if we make this new ioremap_nopost() fail by
>> returning NULL if an architecture does not provide an implementation,
>> then these drivers are going to start failing on such architectures.
>>
>> It is only safe to do that where we know for certain that the drivers
>> are not used - but I don't think that's the case here (it's difficult
>> to tell, because no drivers are updated in this series, so we don't
>> know which are going to be affected.)
>>
>> So, the question is:
>>
>> - is it better to provide a default implementation which provides the
>> functionality that existing drivers are _already_ using, albiet not
>> entirely correctly.
>>
>> or:
>>
>> - is it better to break drivers on architectures when they're converted
>> to fix up this issue.
>>
>> What, I suppose, we could do is not bother with a default implementation,
>> but instead litter drivers with:
>>
>> +#ifdef ioremap_post
>> + base = ioremap_post(...);
>> +#else
>> base = ioremap(...);
>> +#endif
>>
>> which gets around your objection - not providing a default that's weaker
>> than required, but also not breaking the drivers. The problem is that
>> we end up littering drivers with ifdefs.
>>
>> However, I'm willing to bet that the architectures that you're saying
>> will not be able to support the weaker semantic won't have any need to
>> use these drivers, or if they do, the drivers will need the method of
>> accessing stuff like PCI IO and configuration spaces radically altered.
>>
>> So, maybe the best solution is to not provide any kind of default
>> implementation, add a HAVE_IOREMAP_POST Kconfig symbol, have architectures
>> select that when they do provide ioremap_post(), and make the drivers
>> depend on that (so we don't end up trying to build these drivers on
>> architectures where they can never work.) Down side to that is reduced
>> build coverage.
>
> I can do that yes, which already means I have to know if eg microblaze
> (drivers/pci/host/pcie-xilinx.c) can provide a mapping with nonposted
> writes semantics, otherwise it is a dead-end.
>
> Another option would be going back to what v1 did, namely, to implement
> a pci_remap_cfgspace() interface (it is the _nopost() suffix that stirred
> debate - nobody would object to having a default pci_remap_cfgspace()
> implementation that defaults to ioremap_nocache(), I know Bjorn does not
> like it to be PCI specific, just adding an option on the table to make
> progress).
The reason I objected to pci_remap_cfgspace() was that I thought
ioremap_nopost() was implementable across arches. That turned out not
to be true, so I'm fine with calling it pci_remap_cfgspace(). Maybe
it's worth a note in the default implementation that arches should
override it with a non-postable version if they can.
Bjorn
^ permalink raw reply [flat|nested] 171+ messages in thread* Re: [PATCH v3 04/32] asm-generic: add ioremap_nopost() remap interface
@ 2017-04-18 16:31 ` Bjorn Helgaas
0 siblings, 0 replies; 171+ messages in thread
From: Bjorn Helgaas @ 2017-04-18 16:31 UTC (permalink / raw)
To: Lorenzo Pieralisi
Cc: Jonas Bonn, Rich Felker, Catalin Marinas, Will Deacon,
James E.J. Bottomley, David Howells, Max Filippov,
Paul Mackerras, Huacai Chen, Guan Xuetao, Thomas Gleixner,
Hans-Christian Egtvedt, Linux-Arch, Jesper Nilsson,
Yoshinori Sato, Michael Ellerman, Helge Deller,
Russell King - ARM Linux, Ingo Molnar, Geert Uytterhoeven,
Benjamin Herrenschmidt, Matt Turner, Haavard Skinnemoen
On Tue, Apr 18, 2017 at 10:49 AM, Lorenzo Pieralisi
<lorenzo.pieralisi@arm.com> wrote:
> On Wed, Apr 12, 2017 at 12:20:22PM +0100, Russell King - ARM Linux wrote:
>> On Tue, Apr 11, 2017 at 11:39:43PM +1000, Benjamin Herrenschmidt wrote:
>> > On Tue, 2017-04-11 at 13:28 +0100, Lorenzo Pieralisi wrote:
>> > > +static inline void __iomem *ioremap_nopost(phys_addr_t offset,
>> > > size_t size)
>> > > +{
>> > > + return ioremap_nocache(offset, size);
>> > > +}
>> > > +
>> >
>> > No this is wrong as I explained.
>> >
>> > This is a semantic that simply *cannot* be generically provided accross
>> > architectures as a mapping attribute.
>> >
>> > The solution to your problem lies elsewhere.
>>
>> I disagree. Sure, it may not be supportable across all architectures,
>> but we're not introducing something brand new here.
>>
>> What we're trying to do is to fix some _existing_ drivers that are
>> already using ioremap() to map the PCI IO and configuration spaces.
>> Maybe it would help if those drivers were part of this patch set,
>> rather than the patch set just introducing a whole new architecture
>> interface without really showing where the problem drivers are.
>>
>> The issue here is that if we make this new ioremap_nopost() fail by
>> returning NULL if an architecture does not provide an implementation,
>> then these drivers are going to start failing on such architectures.
>>
>> It is only safe to do that where we know for certain that the drivers
>> are not used - but I don't think that's the case here (it's difficult
>> to tell, because no drivers are updated in this series, so we don't
>> know which are going to be affected.)
>>
>> So, the question is:
>>
>> - is it better to provide a default implementation which provides the
>> functionality that existing drivers are _already_ using, albiet not
>> entirely correctly.
>>
>> or:
>>
>> - is it better to break drivers on architectures when they're converted
>> to fix up this issue.
>>
>> What, I suppose, we could do is not bother with a default implementation,
>> but instead litter drivers with:
>>
>> +#ifdef ioremap_post
>> + base = ioremap_post(...);
>> +#else
>> base = ioremap(...);
>> +#endif
>>
>> which gets around your objection - not providing a default that's weaker
>> than required, but also not breaking the drivers. The problem is that
>> we end up littering drivers with ifdefs.
>>
>> However, I'm willing to bet that the architectures that you're saying
>> will not be able to support the weaker semantic won't have any need to
>> use these drivers, or if they do, the drivers will need the method of
>> accessing stuff like PCI IO and configuration spaces radically altered.
>>
>> So, maybe the best solution is to not provide any kind of default
>> implementation, add a HAVE_IOREMAP_POST Kconfig symbol, have architectures
>> select that when they do provide ioremap_post(), and make the drivers
>> depend on that (so we don't end up trying to build these drivers on
>> architectures where they can never work.) Down side to that is reduced
>> build coverage.
>
> I can do that yes, which already means I have to know if eg microblaze
> (drivers/pci/host/pcie-xilinx.c) can provide a mapping with nonposted
> writes semantics, otherwise it is a dead-end.
>
> Another option would be going back to what v1 did, namely, to implement
> a pci_remap_cfgspace() interface (it is the _nopost() suffix that stirred
> debate - nobody would object to having a default pci_remap_cfgspace()
> implementation that defaults to ioremap_nocache(), I know Bjorn does not
> like it to be PCI specific, just adding an option on the table to make
> progress).
The reason I objected to pci_remap_cfgspace() was that I thought
ioremap_nopost() was implementable across arches. That turned out not
to be true, so I'm fine with calling it pci_remap_cfgspace(). Maybe
it's worth a note in the default implementation that arches should
override it with a non-postable version if they can.
Bjorn
^ permalink raw reply [flat|nested] 171+ messages in thread
* Re: [PATCH v3 04/32] asm-generic: add ioremap_nopost() remap interface
2017-04-18 15:49 ` Lorenzo Pieralisi
(?)
@ 2017-04-18 22:43 ` Benjamin Herrenschmidt
-1 siblings, 0 replies; 171+ messages in thread
From: Benjamin Herrenschmidt @ 2017-04-18 22:43 UTC (permalink / raw)
To: Lorenzo Pieralisi, Russell King - ARM Linux
Cc: Jonas Bonn, Rich Felker, linux-pci, Will Deacon, David Howells,
Max Filippov, Paul Mackerras, Huacai Chen, Guan Xuetao,
Thomas Gleixner, Hans-Christian Egtvedt, linux-arch,
Jesper Nilsson, Yoshinori Sato, Michael Ellerman, Helge Deller,
James E.J. Bottomley, Ingo Molnar, Geert Uytterhoeven,
Catalin Marinas, Matt Turner, Haavard Skinnemoen, Fenghua Yu,
James Hogan, Chris Metcalf, Arnd Bergmann, Heiko Carstens,
Stefan Kristiansson, Mikael Starvik, Ivan Kokshaysky,
Bjorn Helgaas, Stafford Horne, linux-arm-kernel,
Richard Henderson, Chris Zankel, Michal Simek, Tony Luck,
Vineet Gupta, linux-kernel, Ralf Baechle, Richard Kuo,
Niklas Cassel, Luis R . Rodriguez, Martin Schwidefsky,
Ley Foon Tan, David S. Miller
On Tue, 2017-04-18 at 16:49 +0100, Lorenzo Pieralisi wrote:
> I can do that yes, which already means I have to know if eg microblaze
> (drivers/pci/host/pcie-xilinx.c) can provide a mapping with nonposted
> writes semantics, otherwise it is a dead-end.
>
> Another option would be going back to what v1 did, namely, to implement
> a pci_remap_cfgspace() interface (it is the _nopost() suffix that stirred
> debate - nobody would object to having a default pci_remap_cfgspace()
> implementation that defaults to ioremap_nocache(), I know Bjorn does not
> like it to be PCI specific, just adding an option on the table to make
> progress).
Well, it boils down again to the fact that a mapping attribute isn't
sufficient.
Let's say I'm microblaze and I can't do non-posted mapping. Then the
Host Bridge driver needs to *know* that so it can implement a different
workaround, such as reading back from some bridge register after every
config write which ensures the previous write reached its destination
for example, or whatever other IP specific mechanism.
Cheers,
Ben.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 171+ messages in thread
* [PATCH v3 04/32] asm-generic: add ioremap_nopost() remap interface
@ 2017-04-18 22:43 ` Benjamin Herrenschmidt
0 siblings, 0 replies; 171+ messages in thread
From: Benjamin Herrenschmidt @ 2017-04-18 22:43 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, 2017-04-18 at 16:49 +0100, Lorenzo Pieralisi wrote:
> I can do that yes, which already means I have to know if eg microblaze
> (drivers/pci/host/pcie-xilinx.c) can provide a mapping with nonposted
> writes semantics, otherwise it is a dead-end.
>
> Another option would be going back to what v1 did, namely, to implement
> a pci_remap_cfgspace() interface (it is the _nopost() suffix that stirred
> debate - nobody would object to having a default pci_remap_cfgspace()
> implementation that defaults to ioremap_nocache(), I know Bjorn does not
> like it to be PCI specific, just adding an option on the table to make
> progress).
Well, it boils down again to the fact that a mapping attribute isn't
sufficient.
Let's say I'm microblaze and I can't do non-posted mapping. Then the
Host Bridge driver needs to *know* that so it can implement a different
workaround, such as reading back from some bridge register after every
config write which ensures the previous write reached its destination
for example, or whatever other IP specific mechanism.
Cheers,
Ben.
^ permalink raw reply [flat|nested] 171+ messages in thread
* Re: [PATCH v3 04/32] asm-generic: add ioremap_nopost() remap interface
@ 2017-04-18 22:43 ` Benjamin Herrenschmidt
0 siblings, 0 replies; 171+ messages in thread
From: Benjamin Herrenschmidt @ 2017-04-18 22:43 UTC (permalink / raw)
To: Lorenzo Pieralisi, Russell King - ARM Linux
Cc: Jonas Bonn, Rich Felker, linux-pci, Will Deacon, David Howells,
Max Filippov, Paul Mackerras, Huacai Chen, Guan Xuetao,
Thomas Gleixner, Hans-Christian Egtvedt, linux-arch,
Jesper Nilsson, Yoshinori Sato, Michael Ellerman, Helge Deller,
James E.J. Bottomley, Ingo Molnar, Geert Uytterhoeven,
Catalin Marinas, Matt Turner, Haavard Skinnemoen, Fenghua Yu,
James Hogan
On Tue, 2017-04-18 at 16:49 +0100, Lorenzo Pieralisi wrote:
> I can do that yes, which already means I have to know if eg microblaze
> (drivers/pci/host/pcie-xilinx.c) can provide a mapping with nonposted
> writes semantics, otherwise it is a dead-end.
>
> Another option would be going back to what v1 did, namely, to implement
> a pci_remap_cfgspace() interface (it is the _nopost() suffix that stirred
> debate - nobody would object to having a default pci_remap_cfgspace()
> implementation that defaults to ioremap_nocache(), I know Bjorn does not
> like it to be PCI specific, just adding an option on the table to make
> progress).
Well, it boils down again to the fact that a mapping attribute isn't
sufficient.
Let's say I'm microblaze and I can't do non-posted mapping. Then the
Host Bridge driver needs to *know* that so it can implement a different
workaround, such as reading back from some bridge register after every
config write which ensures the previous write reached its destination
for example, or whatever other IP specific mechanism.
Cheers,
Ben.
^ permalink raw reply [flat|nested] 171+ messages in thread
* [PATCH v3 05/32] alpha: include default ioremap_nopost() implementation
2017-04-11 12:28 ` Lorenzo Pieralisi
@ 2017-04-11 12:28 ` Lorenzo Pieralisi
-1 siblings, 0 replies; 171+ messages in thread
From: Lorenzo Pieralisi @ 2017-04-11 12:28 UTC (permalink / raw)
To: linux-pci
Cc: linux-arch, linux-kernel, linux-arm-kernel, Lorenzo Pieralisi,
Bjorn Helgaas, Richard Henderson, Ivan Kokshaysky, Matt Turner
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.
Include the asm-generic ioremap_nopost() implementation (currently
falling back to ioremap_nocache()) to provide a non-posted writes
ioremap interface to kernel subsystems.
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Cc: Richard Henderson <rth@twiddle.net>
Cc: Ivan Kokshaysky <ink@jurassic.park.msu.ru>
Cc: Matt Turner <mattst88@gmail.com>
---
arch/alpha/include/asm/io.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/alpha/include/asm/io.h b/arch/alpha/include/asm/io.h
index ff40491..5d7cc11 100644
--- a/arch/alpha/include/asm/io.h
+++ b/arch/alpha/include/asm/io.h
@@ -300,6 +300,7 @@ static inline void __iomem * ioremap_nocache(unsigned long offset,
}
#define ioremap_uc ioremap_nocache
+#include <asm-generic/ioremap-nopost.h>
static inline void iounmap(volatile void __iomem *addr)
{
--
2.10.0
^ permalink raw reply related [flat|nested] 171+ messages in thread* [PATCH v3 05/32] alpha: include default ioremap_nopost() implementation
@ 2017-04-11 12:28 ` Lorenzo Pieralisi
0 siblings, 0 replies; 171+ messages in thread
From: Lorenzo Pieralisi @ 2017-04-11 12:28 UTC (permalink / raw)
To: linux-arm-kernel
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.
Include the asm-generic ioremap_nopost() implementation (currently
falling back to ioremap_nocache()) to provide a non-posted writes
ioremap interface to kernel subsystems.
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Cc: Richard Henderson <rth@twiddle.net>
Cc: Ivan Kokshaysky <ink@jurassic.park.msu.ru>
Cc: Matt Turner <mattst88@gmail.com>
---
arch/alpha/include/asm/io.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/alpha/include/asm/io.h b/arch/alpha/include/asm/io.h
index ff40491..5d7cc11 100644
--- a/arch/alpha/include/asm/io.h
+++ b/arch/alpha/include/asm/io.h
@@ -300,6 +300,7 @@ static inline void __iomem * ioremap_nocache(unsigned long offset,
}
#define ioremap_uc ioremap_nocache
+#include <asm-generic/ioremap-nopost.h>
static inline void iounmap(volatile void __iomem *addr)
{
--
2.10.0
^ permalink raw reply related [flat|nested] 171+ messages in thread
* [PATCH v3 06/32] avr32: include default ioremap_nopost() implementation
2017-04-11 12:28 ` Lorenzo Pieralisi
@ 2017-04-11 12:28 ` Lorenzo Pieralisi
-1 siblings, 0 replies; 171+ messages in thread
From: Lorenzo Pieralisi @ 2017-04-11 12:28 UTC (permalink / raw)
To: linux-pci
Cc: linux-arch, linux-kernel, linux-arm-kernel, Lorenzo Pieralisi,
Bjorn Helgaas, Hans-Christian Egtvedt, Haavard Skinnemoen
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.
Include the asm-generic ioremap_nopost() implementation (currently
falling back to ioremap_nocache()) to provide a non-posted writes
ioremap interface to kernel subsystems.
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Cc: Hans-Christian Egtvedt <egtvedt@samfundet.no>
Cc: Haavard Skinnemoen <hskinnemoen@gmail.com>
---
arch/avr32/include/asm/io.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/avr32/include/asm/io.h b/arch/avr32/include/asm/io.h
index f855646..b2ff522 100644
--- a/arch/avr32/include/asm/io.h
+++ b/arch/avr32/include/asm/io.h
@@ -298,6 +298,7 @@ extern void __iounmap(void __iomem *addr);
#define ioremap_wc ioremap_nocache
#define ioremap_wt ioremap_nocache
#define ioremap_uc ioremap_nocache
+#include <asm-generic/ioremap-nopost.h>
#define cached(addr) P1SEGADDR(addr)
#define uncached(addr) P2SEGADDR(addr)
--
2.10.0
^ permalink raw reply related [flat|nested] 171+ messages in thread
* [PATCH v3 06/32] avr32: include default ioremap_nopost() implementation
@ 2017-04-11 12:28 ` Lorenzo Pieralisi
0 siblings, 0 replies; 171+ messages in thread
From: Lorenzo Pieralisi @ 2017-04-11 12:28 UTC (permalink / raw)
To: linux-arm-kernel
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.
Include the asm-generic ioremap_nopost() implementation (currently
falling back to ioremap_nocache()) to provide a non-posted writes
ioremap interface to kernel subsystems.
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Cc: Hans-Christian Egtvedt <egtvedt@samfundet.no>
Cc: Haavard Skinnemoen <hskinnemoen@gmail.com>
---
arch/avr32/include/asm/io.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/avr32/include/asm/io.h b/arch/avr32/include/asm/io.h
index f855646..b2ff522 100644
--- a/arch/avr32/include/asm/io.h
+++ b/arch/avr32/include/asm/io.h
@@ -298,6 +298,7 @@ extern void __iounmap(void __iomem *addr);
#define ioremap_wc ioremap_nocache
#define ioremap_wt ioremap_nocache
#define ioremap_uc ioremap_nocache
+#include <asm-generic/ioremap-nopost.h>
#define cached(addr) P1SEGADDR(addr)
#define uncached(addr) P2SEGADDR(addr)
--
2.10.0
^ permalink raw reply related [flat|nested] 171+ messages in thread
* Re: [PATCH v3 06/32] avr32: include default ioremap_nopost() implementation
2017-04-11 12:28 ` Lorenzo Pieralisi
(?)
(?)
@ 2017-04-11 13:55 ` Nicolas Ferre
-1 siblings, 0 replies; 171+ messages in thread
From: Nicolas Ferre @ 2017-04-11 13:55 UTC (permalink / raw)
To: Lorenzo Pieralisi, linux-pci
Cc: linux-arch, linux-kernel, Bjorn Helgaas, Haavard Skinnemoen,
linux-arm-kernel, Hans-Christian Egtvedt
Le 11/04/2017 à 14:28, Lorenzo Pieralisi a écrit :
> 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.
>
> Include the asm-generic ioremap_nopost() implementation (currently
> falling back to ioremap_nocache()) to provide a non-posted writes
> ioremap interface to kernel subsystems.
>
> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> Cc: Bjorn Helgaas <bhelgaas@google.com>
> Cc: Hans-Christian Egtvedt <egtvedt@samfundet.no>
> Cc: Haavard Skinnemoen <hskinnemoen@gmail.com>
> ---
> arch/avr32/include/asm/io.h | 1 +
> 1 file changed, 1 insertion(+)
You probably need to remove this one as the avr32 architecture will be
removed in kernel 4.12:
https://lkml.org/lkml/2017/3/27/422
Best regards,
> diff --git a/arch/avr32/include/asm/io.h b/arch/avr32/include/asm/io.h
> index f855646..b2ff522 100644
> --- a/arch/avr32/include/asm/io.h
> +++ b/arch/avr32/include/asm/io.h
> @@ -298,6 +298,7 @@ extern void __iounmap(void __iomem *addr);
> #define ioremap_wc ioremap_nocache
> #define ioremap_wt ioremap_nocache
> #define ioremap_uc ioremap_nocache
> +#include <asm-generic/ioremap-nopost.h>
>
> #define cached(addr) P1SEGADDR(addr)
> #define uncached(addr) P2SEGADDR(addr)
>
--
Nicolas Ferre
^ permalink raw reply [flat|nested] 171+ messages in thread
* [PATCH v3 06/32] avr32: include default ioremap_nopost() implementation
@ 2017-04-11 13:55 ` Nicolas Ferre
0 siblings, 0 replies; 171+ messages in thread
From: Nicolas Ferre @ 2017-04-11 13:55 UTC (permalink / raw)
To: linux-arm-kernel
Le 11/04/2017 ? 14:28, Lorenzo Pieralisi a ?crit :
> 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.
>
> Include the asm-generic ioremap_nopost() implementation (currently
> falling back to ioremap_nocache()) to provide a non-posted writes
> ioremap interface to kernel subsystems.
>
> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> Cc: Bjorn Helgaas <bhelgaas@google.com>
> Cc: Hans-Christian Egtvedt <egtvedt@samfundet.no>
> Cc: Haavard Skinnemoen <hskinnemoen@gmail.com>
> ---
> arch/avr32/include/asm/io.h | 1 +
> 1 file changed, 1 insertion(+)
You probably need to remove this one as the avr32 architecture will be
removed in kernel 4.12:
https://lkml.org/lkml/2017/3/27/422
Best regards,
> diff --git a/arch/avr32/include/asm/io.h b/arch/avr32/include/asm/io.h
> index f855646..b2ff522 100644
> --- a/arch/avr32/include/asm/io.h
> +++ b/arch/avr32/include/asm/io.h
> @@ -298,6 +298,7 @@ extern void __iounmap(void __iomem *addr);
> #define ioremap_wc ioremap_nocache
> #define ioremap_wt ioremap_nocache
> #define ioremap_uc ioremap_nocache
> +#include <asm-generic/ioremap-nopost.h>
>
> #define cached(addr) P1SEGADDR(addr)
> #define uncached(addr) P2SEGADDR(addr)
>
--
Nicolas Ferre
^ permalink raw reply [flat|nested] 171+ messages in thread
* Re: [PATCH v3 06/32] avr32: include default ioremap_nopost() implementation
@ 2017-04-11 13:55 ` Nicolas Ferre
0 siblings, 0 replies; 171+ messages in thread
From: Nicolas Ferre @ 2017-04-11 13:55 UTC (permalink / raw)
To: Lorenzo Pieralisi, linux-pci
Cc: linux-arch, linux-kernel, Bjorn Helgaas, Haavard Skinnemoen,
linux-arm-kernel, Hans-Christian Egtvedt
Le 11/04/2017 à 14:28, Lorenzo Pieralisi a écrit :
> 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.
>
> Include the asm-generic ioremap_nopost() implementation (currently
> falling back to ioremap_nocache()) to provide a non-posted writes
> ioremap interface to kernel subsystems.
>
> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> Cc: Bjorn Helgaas <bhelgaas@google.com>
> Cc: Hans-Christian Egtvedt <egtvedt@samfundet.no>
> Cc: Haavard Skinnemoen <hskinnemoen@gmail.com>
> ---
> arch/avr32/include/asm/io.h | 1 +
> 1 file changed, 1 insertion(+)
You probably need to remove this one as the avr32 architecture will be
removed in kernel 4.12:
https://lkml.org/lkml/2017/3/27/422
Best regards,
> diff --git a/arch/avr32/include/asm/io.h b/arch/avr32/include/asm/io.h
> index f855646..b2ff522 100644
> --- a/arch/avr32/include/asm/io.h
> +++ b/arch/avr32/include/asm/io.h
> @@ -298,6 +298,7 @@ extern void __iounmap(void __iomem *addr);
> #define ioremap_wc ioremap_nocache
> #define ioremap_wt ioremap_nocache
> #define ioremap_uc ioremap_nocache
> +#include <asm-generic/ioremap-nopost.h>
>
> #define cached(addr) P1SEGADDR(addr)
> #define uncached(addr) P2SEGADDR(addr)
>
--
Nicolas Ferre
^ permalink raw reply [flat|nested] 171+ messages in thread
* Re: [PATCH v3 06/32] avr32: include default ioremap_nopost() implementation
@ 2017-04-11 13:55 ` Nicolas Ferre
0 siblings, 0 replies; 171+ messages in thread
From: Nicolas Ferre @ 2017-04-11 13:55 UTC (permalink / raw)
To: Lorenzo Pieralisi, linux-pci
Cc: linux-arch, linux-kernel, Bjorn Helgaas, Haavard Skinnemoen,
linux-arm-kernel, Hans-Christian Egtvedt
Le 11/04/2017 =E0 14:28, Lorenzo Pieralisi a =E9crit :
> 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.
> =
> Include the asm-generic ioremap_nopost() implementation (currently
> falling back to ioremap_nocache()) to provide a non-posted writes
> ioremap interface to kernel subsystems.
> =
> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> Cc: Bjorn Helgaas <bhelgaas@google.com>
> Cc: Hans-Christian Egtvedt <egtvedt@samfundet.no>
> Cc: Haavard Skinnemoen <hskinnemoen@gmail.com>
> ---
> arch/avr32/include/asm/io.h | 1 +
> 1 file changed, 1 insertion(+)
You probably need to remove this one as the avr32 architecture will be
removed in kernel 4.12:
https://lkml.org/lkml/2017/3/27/422
Best regards,
> diff --git a/arch/avr32/include/asm/io.h b/arch/avr32/include/asm/io.h
> index f855646..b2ff522 100644
> --- a/arch/avr32/include/asm/io.h
> +++ b/arch/avr32/include/asm/io.h
> @@ -298,6 +298,7 @@ extern void __iounmap(void __iomem *addr);
> #define ioremap_wc ioremap_nocache
> #define ioremap_wt ioremap_nocache
> #define ioremap_uc ioremap_nocache
> +#include <asm-generic/ioremap-nopost.h>
> =
> #define cached(addr) P1SEGADDR(addr)
> #define uncached(addr) P2SEGADDR(addr)
> =
-- =
Nicolas Ferre
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 171+ messages in thread
* [PATCH v3 07/32] arc: include default ioremap_nopost() implementation
2017-04-11 12:28 ` Lorenzo Pieralisi
@ 2017-04-11 12:28 ` Lorenzo Pieralisi
-1 siblings, 0 replies; 171+ messages in thread
From: Lorenzo Pieralisi @ 2017-04-11 12:28 UTC (permalink / raw)
To: linux-pci
Cc: linux-arch, linux-kernel, linux-arm-kernel, Lorenzo Pieralisi,
Bjorn Helgaas, Vineet Gupta
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.
Include the asm-generic ioremap_nopost() implementation (currently
falling back to ioremap_nocache()) to provide a non-posted writes
ioremap interface to kernel subsystems.
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Cc: Vineet Gupta <vgupta@synopsys.com>
---
arch/arc/include/asm/io.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arc/include/asm/io.h b/arch/arc/include/asm/io.h
index c22b181..58686c8 100644
--- a/arch/arc/include/asm/io.h
+++ b/arch/arc/include/asm/io.h
@@ -39,6 +39,7 @@ extern void iounmap(const void __iomem *addr);
#define ioremap_nocache(phy, sz) ioremap(phy, sz)
#define ioremap_wc(phy, sz) ioremap(phy, sz)
#define ioremap_wt(phy, sz) ioremap(phy, sz)
+#include <asm-generic/ioremap-nopost.h>
/*
* io{read,write}{16,32}be() macros
--
2.10.0
^ permalink raw reply related [flat|nested] 171+ messages in thread* [PATCH v3 07/32] arc: include default ioremap_nopost() implementation
@ 2017-04-11 12:28 ` Lorenzo Pieralisi
0 siblings, 0 replies; 171+ messages in thread
From: Lorenzo Pieralisi @ 2017-04-11 12:28 UTC (permalink / raw)
To: linux-arm-kernel
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.
Include the asm-generic ioremap_nopost() implementation (currently
falling back to ioremap_nocache()) to provide a non-posted writes
ioremap interface to kernel subsystems.
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Cc: Vineet Gupta <vgupta@synopsys.com>
---
arch/arc/include/asm/io.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arc/include/asm/io.h b/arch/arc/include/asm/io.h
index c22b181..58686c8 100644
--- a/arch/arc/include/asm/io.h
+++ b/arch/arc/include/asm/io.h
@@ -39,6 +39,7 @@ extern void iounmap(const void __iomem *addr);
#define ioremap_nocache(phy, sz) ioremap(phy, sz)
#define ioremap_wc(phy, sz) ioremap(phy, sz)
#define ioremap_wt(phy, sz) ioremap(phy, sz)
+#include <asm-generic/ioremap-nopost.h>
/*
* io{read,write}{16,32}be() macros
--
2.10.0
^ permalink raw reply related [flat|nested] 171+ messages in thread
* [PATCH v3 08/32] cris: include default ioremap_nopost() implementation
2017-04-11 12:28 ` Lorenzo Pieralisi
@ 2017-04-11 12:28 ` Lorenzo Pieralisi
-1 siblings, 0 replies; 171+ messages in thread
From: Lorenzo Pieralisi @ 2017-04-11 12:28 UTC (permalink / raw)
To: linux-pci
Cc: linux-arch, linux-kernel, linux-arm-kernel, Lorenzo Pieralisi,
Niklas Cassel, Bjorn Helgaas, Jesper Nilsson, Mikael Starvik
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.
Include the asm-generic ioremap_nopost() implementation (currently
falling back to ioremap_nocache()) to provide a non-posted writes
ioremap interface to kernel subsystems.
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Cc: Niklas Cassel <nks@flawful.org>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Cc: Jesper Nilsson <jesper.nilsson@axis.com>
Cc: Mikael Starvik <starvik@axis.com>
---
arch/cris/include/asm/io.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/cris/include/asm/io.h b/arch/cris/include/asm/io.h
index fe0b2a0..b9c9397 100644
--- a/arch/cris/include/asm/io.h
+++ b/arch/cris/include/asm/io.h
@@ -21,5 +21,6 @@ extern void iounmap(volatile void * __iomem addr);
extern void __iomem * ioremap_nocache(unsigned long offset, unsigned long size);
#include <asm-generic/io.h>
+#include <asm-generic/ioremap-nopost.h>
#endif
--
2.10.0
^ permalink raw reply related [flat|nested] 171+ messages in thread
* [PATCH v3 08/32] cris: include default ioremap_nopost() implementation
@ 2017-04-11 12:28 ` Lorenzo Pieralisi
0 siblings, 0 replies; 171+ messages in thread
From: Lorenzo Pieralisi @ 2017-04-11 12:28 UTC (permalink / raw)
To: linux-arm-kernel
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.
Include the asm-generic ioremap_nopost() implementation (currently
falling back to ioremap_nocache()) to provide a non-posted writes
ioremap interface to kernel subsystems.
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Cc: Niklas Cassel <nks@flawful.org>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Cc: Jesper Nilsson <jesper.nilsson@axis.com>
Cc: Mikael Starvik <starvik@axis.com>
---
arch/cris/include/asm/io.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/cris/include/asm/io.h b/arch/cris/include/asm/io.h
index fe0b2a0..b9c9397 100644
--- a/arch/cris/include/asm/io.h
+++ b/arch/cris/include/asm/io.h
@@ -21,5 +21,6 @@ extern void iounmap(volatile void * __iomem addr);
extern void __iomem * ioremap_nocache(unsigned long offset, unsigned long size);
#include <asm-generic/io.h>
+#include <asm-generic/ioremap-nopost.h>
#endif
--
2.10.0
^ permalink raw reply related [flat|nested] 171+ messages in thread
* Re: [PATCH v3 08/32] cris: include default ioremap_nopost() implementation
2017-04-11 12:28 ` Lorenzo Pieralisi
(?)
@ 2017-04-11 13:15 ` Jesper Nilsson
-1 siblings, 0 replies; 171+ messages in thread
From: Jesper Nilsson @ 2017-04-11 13:15 UTC (permalink / raw)
To: Lorenzo Pieralisi
Cc: linux-pci, linux-arch, linux-kernel, linux-arm-kernel,
Niklas Cassel, Bjorn Helgaas, Jesper Nilsson, Mikael Starvik
On Tue, Apr 11, 2017 at 01:28:48PM +0100, Lorenzo Pieralisi wrote:
> 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.
>
> Include the asm-generic ioremap_nopost() implementation (currently
> falling back to ioremap_nocache()) to provide a non-posted writes
> ioremap interface to kernel subsystems.
>
> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> Cc: Niklas Cassel <nks@flawful.org>
> Cc: Bjorn Helgaas <bhelgaas@google.com>
For the CRIS-part:
Acked-by: Jesper Nilsson <jesper.nilsson@axis.com>
/^JN - Jesper Nilsson
--
Jesper Nilsson -- jesper.nilsson@axis.com
^ permalink raw reply [flat|nested] 171+ messages in thread* [PATCH v3 08/32] cris: include default ioremap_nopost() implementation
@ 2017-04-11 13:15 ` Jesper Nilsson
0 siblings, 0 replies; 171+ messages in thread
From: Jesper Nilsson @ 2017-04-11 13:15 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, Apr 11, 2017 at 01:28:48PM +0100, Lorenzo Pieralisi wrote:
> 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.
>
> Include the asm-generic ioremap_nopost() implementation (currently
> falling back to ioremap_nocache()) to provide a non-posted writes
> ioremap interface to kernel subsystems.
>
> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> Cc: Niklas Cassel <nks@flawful.org>
> Cc: Bjorn Helgaas <bhelgaas@google.com>
For the CRIS-part:
Acked-by: Jesper Nilsson <jesper.nilsson@axis.com>
/^JN - Jesper Nilsson
--
Jesper Nilsson -- jesper.nilsson at axis.com
^ permalink raw reply [flat|nested] 171+ messages in thread* Re: [PATCH v3 08/32] cris: include default ioremap_nopost() implementation
@ 2017-04-11 13:15 ` Jesper Nilsson
0 siblings, 0 replies; 171+ messages in thread
From: Jesper Nilsson @ 2017-04-11 13:15 UTC (permalink / raw)
To: Lorenzo Pieralisi
Cc: linux-arch, Mikael Starvik, linux-pci, linux-kernel,
Jesper Nilsson, Niklas Cassel, Bjorn Helgaas, linux-arm-kernel
On Tue, Apr 11, 2017 at 01:28:48PM +0100, Lorenzo Pieralisi wrote:
> 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.
>
> Include the asm-generic ioremap_nopost() implementation (currently
> falling back to ioremap_nocache()) to provide a non-posted writes
> ioremap interface to kernel subsystems.
>
> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> Cc: Niklas Cassel <nks@flawful.org>
> Cc: Bjorn Helgaas <bhelgaas@google.com>
For the CRIS-part:
Acked-by: Jesper Nilsson <jesper.nilsson@axis.com>
/^JN - Jesper Nilsson
--
Jesper Nilsson -- jesper.nilsson@axis.com
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 171+ messages in thread
* [PATCH v3 09/32] frv: include default ioremap_nopost() implementation
2017-04-11 12:28 ` Lorenzo Pieralisi
@ 2017-04-11 12:28 ` Lorenzo Pieralisi
-1 siblings, 0 replies; 171+ messages in thread
From: Lorenzo Pieralisi @ 2017-04-11 12:28 UTC (permalink / raw)
To: linux-pci
Cc: linux-arch, linux-kernel, linux-arm-kernel, Lorenzo Pieralisi,
Bjorn Helgaas
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.
Include the asm-generic ioremap_nopost() implementation (currently
falling back to ioremap_nocache()) to provide a non-posted writes
ioremap interface to kernel subsystems.
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Cc: Bjorn Helgaas <bhelgaas@google.com>
---
arch/frv/include/asm/io.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/frv/include/asm/io.h b/arch/frv/include/asm/io.h
index 8062fc7..8808502 100644
--- a/arch/frv/include/asm/io.h
+++ b/arch/frv/include/asm/io.h
@@ -290,6 +290,7 @@ static inline void __iomem *ioremap_fullcache(unsigned long physaddr, unsigned l
#define ioremap_wc ioremap_nocache
#define ioremap_uc ioremap_nocache
+#include <asm-generic/ioremap-nopost.h>
extern void iounmap(void volatile __iomem *addr);
--
2.10.0
^ permalink raw reply related [flat|nested] 171+ messages in thread
* [PATCH v3 09/32] frv: include default ioremap_nopost() implementation
@ 2017-04-11 12:28 ` Lorenzo Pieralisi
0 siblings, 0 replies; 171+ messages in thread
From: Lorenzo Pieralisi @ 2017-04-11 12:28 UTC (permalink / raw)
To: linux-arm-kernel
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.
Include the asm-generic ioremap_nopost() implementation (currently
falling back to ioremap_nocache()) to provide a non-posted writes
ioremap interface to kernel subsystems.
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Cc: Bjorn Helgaas <bhelgaas@google.com>
---
arch/frv/include/asm/io.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/frv/include/asm/io.h b/arch/frv/include/asm/io.h
index 8062fc7..8808502 100644
--- a/arch/frv/include/asm/io.h
+++ b/arch/frv/include/asm/io.h
@@ -290,6 +290,7 @@ static inline void __iomem *ioremap_fullcache(unsigned long physaddr, unsigned l
#define ioremap_wc ioremap_nocache
#define ioremap_uc ioremap_nocache
+#include <asm-generic/ioremap-nopost.h>
extern void iounmap(void volatile __iomem *addr);
--
2.10.0
^ permalink raw reply related [flat|nested] 171+ messages in thread
* [PATCH v3 10/32] hexagon: include default ioremap_nopost() implementation
2017-04-11 12:28 ` Lorenzo Pieralisi
(?)
(?)
@ 2017-04-11 12:28 ` Lorenzo Pieralisi
-1 siblings, 0 replies; 171+ messages in thread
From: Lorenzo Pieralisi @ 2017-04-11 12:28 UTC (permalink / raw)
To: linux-pci
Cc: linux-arch, linux-kernel, linux-arm-kernel, Lorenzo Pieralisi,
Bjorn Helgaas, Richard Kuo
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.
Include the asm-generic ioremap_nopost() implementation (currently
falling back to ioremap_nocache()) to provide a non-posted writes
ioremap interface to kernel subsystems.
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Cc: Richard Kuo <rkuo@codeaurora.org>
---
arch/hexagon/include/asm/io.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/hexagon/include/asm/io.h b/arch/hexagon/include/asm/io.h
index 66f5e9a..be630bf 100644
--- a/arch/hexagon/include/asm/io.h
+++ b/arch/hexagon/include/asm/io.h
@@ -197,6 +197,8 @@ static inline void __iomem *ioremap(unsigned long phys_addr, unsigned long size)
return ioremap_nocache(phys_addr, size);
}
+#include <asm-generic/ioremap-nopost.h>
+
static inline void iounmap(volatile void __iomem *addr)
{
__iounmap(addr);
--
2.10.0
^ permalink raw reply related [flat|nested] 171+ messages in thread* [PATCH v3 10/32] hexagon: include default ioremap_nopost() implementation
@ 2017-04-11 12:28 ` Lorenzo Pieralisi
0 siblings, 0 replies; 171+ messages in thread
From: Lorenzo Pieralisi @ 2017-04-11 12:28 UTC (permalink / raw)
To: linux-arm-kernel
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.
Include the asm-generic ioremap_nopost() implementation (currently
falling back to ioremap_nocache()) to provide a non-posted writes
ioremap interface to kernel subsystems.
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Cc: Richard Kuo <rkuo@codeaurora.org>
---
arch/hexagon/include/asm/io.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/hexagon/include/asm/io.h b/arch/hexagon/include/asm/io.h
index 66f5e9a..be630bf 100644
--- a/arch/hexagon/include/asm/io.h
+++ b/arch/hexagon/include/asm/io.h
@@ -197,6 +197,8 @@ static inline void __iomem *ioremap(unsigned long phys_addr, unsigned long size)
return ioremap_nocache(phys_addr, size);
}
+#include <asm-generic/ioremap-nopost.h>
+
static inline void iounmap(volatile void __iomem *addr)
{
__iounmap(addr);
--
2.10.0
^ permalink raw reply related [flat|nested] 171+ messages in thread* [PATCH v3 10/32] hexagon: include default ioremap_nopost() implementation
@ 2017-04-11 12:28 ` Lorenzo Pieralisi
0 siblings, 0 replies; 171+ messages in thread
From: Lorenzo Pieralisi @ 2017-04-11 12:28 UTC (permalink / raw)
To: linux-pci
Cc: linux-arch, Lorenzo Pieralisi, linux-kernel, Richard Kuo,
Bjorn Helgaas, linux-arm-kernel
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.
Include the asm-generic ioremap_nopost() implementation (currently
falling back to ioremap_nocache()) to provide a non-posted writes
ioremap interface to kernel subsystems.
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Cc: Richard Kuo <rkuo@codeaurora.org>
---
arch/hexagon/include/asm/io.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/hexagon/include/asm/io.h b/arch/hexagon/include/asm/io.h
index 66f5e9a..be630bf 100644
--- a/arch/hexagon/include/asm/io.h
+++ b/arch/hexagon/include/asm/io.h
@@ -197,6 +197,8 @@ static inline void __iomem *ioremap(unsigned long phys_addr, unsigned long size)
return ioremap_nocache(phys_addr, size);
}
+#include <asm-generic/ioremap-nopost.h>
+
static inline void iounmap(volatile void __iomem *addr)
{
__iounmap(addr);
--
2.10.0
^ permalink raw reply related [flat|nested] 171+ messages in thread* [PATCH v3 10/32] hexagon: include default ioremap_nopost() implementation
@ 2017-04-11 12:28 ` Lorenzo Pieralisi
0 siblings, 0 replies; 171+ messages in thread
From: Lorenzo Pieralisi @ 2017-04-11 12:28 UTC (permalink / raw)
To: linux-pci
Cc: linux-arch, Lorenzo Pieralisi, linux-kernel, Richard Kuo,
Bjorn Helgaas, linux-arm-kernel
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.
Include the asm-generic ioremap_nopost() implementation (currently
falling back to ioremap_nocache()) to provide a non-posted writes
ioremap interface to kernel subsystems.
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Cc: Richard Kuo <rkuo@codeaurora.org>
---
arch/hexagon/include/asm/io.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/hexagon/include/asm/io.h b/arch/hexagon/include/asm/io.h
index 66f5e9a..be630bf 100644
--- a/arch/hexagon/include/asm/io.h
+++ b/arch/hexagon/include/asm/io.h
@@ -197,6 +197,8 @@ static inline void __iomem *ioremap(unsigned long phys_addr, unsigned long size)
return ioremap_nocache(phys_addr, size);
}
+#include <asm-generic/ioremap-nopost.h>
+
static inline void iounmap(volatile void __iomem *addr)
{
__iounmap(addr);
--
2.10.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 171+ messages in thread
* [PATCH v3 11/32] ia64: include default ioremap_nopost() implementation
2017-04-11 12:28 ` Lorenzo Pieralisi
@ 2017-04-11 12:28 ` Lorenzo Pieralisi
-1 siblings, 0 replies; 171+ messages in thread
From: Lorenzo Pieralisi @ 2017-04-11 12:28 UTC (permalink / raw)
To: linux-pci
Cc: linux-arch, linux-kernel, linux-arm-kernel, Lorenzo Pieralisi,
Bjorn Helgaas, Tony Luck, Fenghua Yu
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.
Include the asm-generic ioremap_nopost() implementation (currently
falling back to ioremap_nocache()) to provide a non-posted writes
ioremap interface to kernel subsystems.
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Cc: Tony Luck <tony.luck@intel.com>
Cc: Fenghua Yu <fenghua.yu@intel.com>
---
arch/ia64/include/asm/io.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/ia64/include/asm/io.h b/arch/ia64/include/asm/io.h
index 5de673a..130956b 100644
--- a/arch/ia64/include/asm/io.h
+++ b/arch/ia64/include/asm/io.h
@@ -434,6 +434,7 @@ static inline void __iomem * ioremap_cache (unsigned long phys_addr, unsigned lo
}
#define ioremap_cache ioremap_cache
#define ioremap_uc ioremap_nocache
+#include <asm-generic/ioremap-nopost.h>
/*
--
2.10.0
^ permalink raw reply related [flat|nested] 171+ messages in thread
* [PATCH v3 11/32] ia64: include default ioremap_nopost() implementation
@ 2017-04-11 12:28 ` Lorenzo Pieralisi
0 siblings, 0 replies; 171+ messages in thread
From: Lorenzo Pieralisi @ 2017-04-11 12:28 UTC (permalink / raw)
To: linux-arm-kernel
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.
Include the asm-generic ioremap_nopost() implementation (currently
falling back to ioremap_nocache()) to provide a non-posted writes
ioremap interface to kernel subsystems.
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Cc: Tony Luck <tony.luck@intel.com>
Cc: Fenghua Yu <fenghua.yu@intel.com>
---
arch/ia64/include/asm/io.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/ia64/include/asm/io.h b/arch/ia64/include/asm/io.h
index 5de673a..130956b 100644
--- a/arch/ia64/include/asm/io.h
+++ b/arch/ia64/include/asm/io.h
@@ -434,6 +434,7 @@ static inline void __iomem * ioremap_cache (unsigned long phys_addr, unsigned lo
}
#define ioremap_cache ioremap_cache
#define ioremap_uc ioremap_nocache
+#include <asm-generic/ioremap-nopost.h>
/*
--
2.10.0
^ permalink raw reply related [flat|nested] 171+ messages in thread
* [PATCH v3 12/32] m32r: include default ioremap_nopost() implementation
2017-04-11 12:28 ` Lorenzo Pieralisi
@ 2017-04-11 12:28 ` Lorenzo Pieralisi
-1 siblings, 0 replies; 171+ messages in thread
From: Lorenzo Pieralisi @ 2017-04-11 12:28 UTC (permalink / raw)
To: linux-pci
Cc: linux-arch, linux-kernel, linux-arm-kernel, Lorenzo Pieralisi,
Bjorn Helgaas
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.
Include the asm-generic ioremap_nopost() implementation (currently
falling back to ioremap_nocache()) to provide a non-posted writes
ioremap interface to kernel subsystems.
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Cc: Bjorn Helgaas <bhelgaas@google.com>
---
arch/m32r/include/asm/io.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/m32r/include/asm/io.h b/arch/m32r/include/asm/io.h
index 4b0f5e0..1577102 100644
--- a/arch/m32r/include/asm/io.h
+++ b/arch/m32r/include/asm/io.h
@@ -70,6 +70,7 @@ extern void iounmap(volatile void __iomem *addr);
#define ioremap_wc ioremap_nocache
#define ioremap_wt ioremap_nocache
#define ioremap_uc ioremap_nocache
+#include <asm-generic/ioremap-nopost.h>
/*
* IO bus memory addresses are also 1:1 with the physical address
--
2.10.0
^ permalink raw reply related [flat|nested] 171+ messages in thread
* [PATCH v3 12/32] m32r: include default ioremap_nopost() implementation
@ 2017-04-11 12:28 ` Lorenzo Pieralisi
0 siblings, 0 replies; 171+ messages in thread
From: Lorenzo Pieralisi @ 2017-04-11 12:28 UTC (permalink / raw)
To: linux-arm-kernel
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.
Include the asm-generic ioremap_nopost() implementation (currently
falling back to ioremap_nocache()) to provide a non-posted writes
ioremap interface to kernel subsystems.
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Cc: Bjorn Helgaas <bhelgaas@google.com>
---
arch/m32r/include/asm/io.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/m32r/include/asm/io.h b/arch/m32r/include/asm/io.h
index 4b0f5e0..1577102 100644
--- a/arch/m32r/include/asm/io.h
+++ b/arch/m32r/include/asm/io.h
@@ -70,6 +70,7 @@ extern void iounmap(volatile void __iomem *addr);
#define ioremap_wc ioremap_nocache
#define ioremap_wt ioremap_nocache
#define ioremap_uc ioremap_nocache
+#include <asm-generic/ioremap-nopost.h>
/*
* IO bus memory addresses are also 1:1 with the physical address
--
2.10.0
^ permalink raw reply related [flat|nested] 171+ messages in thread
* [PATCH v3 13/32] m68k: include default ioremap_nopost() implementation
2017-04-11 12:28 ` Lorenzo Pieralisi
(?)
(?)
@ 2017-04-11 12:28 ` Lorenzo Pieralisi
-1 siblings, 0 replies; 171+ messages in thread
From: Lorenzo Pieralisi @ 2017-04-11 12:28 UTC (permalink / raw)
To: linux-pci
Cc: linux-arch, linux-kernel, linux-arm-kernel, Lorenzo Pieralisi,
Bjorn Helgaas, Geert Uytterhoeven
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.
Include the asm-generic ioremap_nopost() implementation (currently
falling back to ioremap_nocache()) to provide a non-posted writes
ioremap interface to kernel subsystems.
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>
---
arch/m68k/include/asm/io.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/m68k/include/asm/io.h b/arch/m68k/include/asm/io.h
index bccd5a9..ce39ee5 100644
--- a/arch/m68k/include/asm/io.h
+++ b/arch/m68k/include/asm/io.h
@@ -3,6 +3,7 @@
#else
#include <asm/io_mm.h>
#endif
+#include <asm-generic/ioremap-nopost.h>
#define readb_relaxed(addr) readb(addr)
#define readw_relaxed(addr) readw(addr)
--
2.10.0
^ permalink raw reply related [flat|nested] 171+ messages in thread
* [PATCH v3 13/32] m68k: include default ioremap_nopost() implementation
@ 2017-04-11 12:28 ` Lorenzo Pieralisi
0 siblings, 0 replies; 171+ messages in thread
From: Lorenzo Pieralisi @ 2017-04-11 12:28 UTC (permalink / raw)
To: linux-arm-kernel
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.
Include the asm-generic ioremap_nopost() implementation (currently
falling back to ioremap_nocache()) to provide a non-posted writes
ioremap interface to kernel subsystems.
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>
---
arch/m68k/include/asm/io.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/m68k/include/asm/io.h b/arch/m68k/include/asm/io.h
index bccd5a9..ce39ee5 100644
--- a/arch/m68k/include/asm/io.h
+++ b/arch/m68k/include/asm/io.h
@@ -3,6 +3,7 @@
#else
#include <asm/io_mm.h>
#endif
+#include <asm-generic/ioremap-nopost.h>
#define readb_relaxed(addr) readb(addr)
#define readw_relaxed(addr) readw(addr)
--
2.10.0
^ permalink raw reply related [flat|nested] 171+ messages in thread
* [PATCH v3 13/32] m68k: include default ioremap_nopost() implementation
@ 2017-04-11 12:28 ` Lorenzo Pieralisi
0 siblings, 0 replies; 171+ messages in thread
From: Lorenzo Pieralisi @ 2017-04-11 12:28 UTC (permalink / raw)
To: linux-pci
Cc: linux-arch, Lorenzo Pieralisi, linux-kernel, Geert Uytterhoeven,
Bjorn Helgaas, linux-arm-kernel
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.
Include the asm-generic ioremap_nopost() implementation (currently
falling back to ioremap_nocache()) to provide a non-posted writes
ioremap interface to kernel subsystems.
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>
---
arch/m68k/include/asm/io.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/m68k/include/asm/io.h b/arch/m68k/include/asm/io.h
index bccd5a9..ce39ee5 100644
--- a/arch/m68k/include/asm/io.h
+++ b/arch/m68k/include/asm/io.h
@@ -3,6 +3,7 @@
#else
#include <asm/io_mm.h>
#endif
+#include <asm-generic/ioremap-nopost.h>
#define readb_relaxed(addr) readb(addr)
#define readw_relaxed(addr) readw(addr)
--
2.10.0
^ permalink raw reply related [flat|nested] 171+ messages in thread
* [PATCH v3 13/32] m68k: include default ioremap_nopost() implementation
@ 2017-04-11 12:28 ` Lorenzo Pieralisi
0 siblings, 0 replies; 171+ messages in thread
From: Lorenzo Pieralisi @ 2017-04-11 12:28 UTC (permalink / raw)
To: linux-pci
Cc: linux-arch, Lorenzo Pieralisi, linux-kernel, Geert Uytterhoeven,
Bjorn Helgaas, linux-arm-kernel
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.
Include the asm-generic ioremap_nopost() implementation (currently
falling back to ioremap_nocache()) to provide a non-posted writes
ioremap interface to kernel subsystems.
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>
---
arch/m68k/include/asm/io.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/m68k/include/asm/io.h b/arch/m68k/include/asm/io.h
index bccd5a9..ce39ee5 100644
--- a/arch/m68k/include/asm/io.h
+++ b/arch/m68k/include/asm/io.h
@@ -3,6 +3,7 @@
#else
#include <asm/io_mm.h>
#endif
+#include <asm-generic/ioremap-nopost.h>
#define readb_relaxed(addr) readb(addr)
#define readw_relaxed(addr) readw(addr)
--
2.10.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 171+ messages in thread
* [PATCH v3 14/32] metag: include default ioremap_nopost() implementation
2017-04-11 12:28 ` Lorenzo Pieralisi
@ 2017-04-11 12:28 ` Lorenzo Pieralisi
-1 siblings, 0 replies; 171+ messages in thread
From: Lorenzo Pieralisi @ 2017-04-11 12:28 UTC (permalink / raw)
To: linux-pci
Cc: linux-arch, linux-kernel, linux-arm-kernel, Lorenzo Pieralisi,
Bjorn Helgaas, James Hogan
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.
Include the asm-generic ioremap_nopost() implementation (currently
falling back to ioremap_nocache()) to provide a non-posted writes
ioremap interface to kernel subsystems.
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Cc: James Hogan <james.hogan@imgtec.com>
---
arch/metag/include/asm/io.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/metag/include/asm/io.h b/arch/metag/include/asm/io.h
index 9890f21..c805e0d 100644
--- a/arch/metag/include/asm/io.h
+++ b/arch/metag/include/asm/io.h
@@ -166,4 +166,6 @@ extern void __iounmap(void __iomem *addr);
#define iounmap(addr) \
__iounmap(addr)
+#include <asm-generic/ioremap-nopost.h>
+
#endif /* _ASM_METAG_IO_H */
--
2.10.0
^ permalink raw reply related [flat|nested] 171+ messages in thread
* [PATCH v3 14/32] metag: include default ioremap_nopost() implementation
@ 2017-04-11 12:28 ` Lorenzo Pieralisi
0 siblings, 0 replies; 171+ messages in thread
From: Lorenzo Pieralisi @ 2017-04-11 12:28 UTC (permalink / raw)
To: linux-arm-kernel
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.
Include the asm-generic ioremap_nopost() implementation (currently
falling back to ioremap_nocache()) to provide a non-posted writes
ioremap interface to kernel subsystems.
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Cc: James Hogan <james.hogan@imgtec.com>
---
arch/metag/include/asm/io.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/metag/include/asm/io.h b/arch/metag/include/asm/io.h
index 9890f21..c805e0d 100644
--- a/arch/metag/include/asm/io.h
+++ b/arch/metag/include/asm/io.h
@@ -166,4 +166,6 @@ extern void __iounmap(void __iomem *addr);
#define iounmap(addr) \
__iounmap(addr)
+#include <asm-generic/ioremap-nopost.h>
+
#endif /* _ASM_METAG_IO_H */
--
2.10.0
^ permalink raw reply related [flat|nested] 171+ messages in thread
* [PATCH v3 15/32] microblaze: include default ioremap_nopost() implementation
2017-04-11 12:28 ` Lorenzo Pieralisi
@ 2017-04-11 12:28 ` Lorenzo Pieralisi
-1 siblings, 0 replies; 171+ messages in thread
From: Lorenzo Pieralisi @ 2017-04-11 12:28 UTC (permalink / raw)
To: linux-pci
Cc: linux-arch, linux-kernel, linux-arm-kernel, Lorenzo Pieralisi,
Bjorn Helgaas, Michal Simek
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.
Include the asm-generic ioremap_nopost() implementation (currently
falling back to ioremap_nocache()) to provide a non-posted writes
ioremap interface to kernel subsystems.
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Cc: Michal Simek <monstr@monstr.eu>
---
arch/microblaze/include/asm/io.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/microblaze/include/asm/io.h b/arch/microblaze/include/asm/io.h
index 39b6315..4714a6d 100644
--- a/arch/microblaze/include/asm/io.h
+++ b/arch/microblaze/include/asm/io.h
@@ -43,6 +43,7 @@ extern void __iomem *ioremap(phys_addr_t address, unsigned long size);
#define ioremap_fullcache(addr, size) ioremap((addr), (size))
#define ioremap_wc(addr, size) ioremap((addr), (size))
#define ioremap_wt(addr, size) ioremap((addr), (size))
+#include <asm-generic/ioremap-nopost.h>
#endif /* CONFIG_MMU */
--
2.10.0
^ permalink raw reply related [flat|nested] 171+ messages in thread
* [PATCH v3 15/32] microblaze: include default ioremap_nopost() implementation
@ 2017-04-11 12:28 ` Lorenzo Pieralisi
0 siblings, 0 replies; 171+ messages in thread
From: Lorenzo Pieralisi @ 2017-04-11 12:28 UTC (permalink / raw)
To: linux-arm-kernel
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.
Include the asm-generic ioremap_nopost() implementation (currently
falling back to ioremap_nocache()) to provide a non-posted writes
ioremap interface to kernel subsystems.
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Cc: Michal Simek <monstr@monstr.eu>
---
arch/microblaze/include/asm/io.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/microblaze/include/asm/io.h b/arch/microblaze/include/asm/io.h
index 39b6315..4714a6d 100644
--- a/arch/microblaze/include/asm/io.h
+++ b/arch/microblaze/include/asm/io.h
@@ -43,6 +43,7 @@ extern void __iomem *ioremap(phys_addr_t address, unsigned long size);
#define ioremap_fullcache(addr, size) ioremap((addr), (size))
#define ioremap_wc(addr, size) ioremap((addr), (size))
#define ioremap_wt(addr, size) ioremap((addr), (size))
+#include <asm-generic/ioremap-nopost.h>
#endif /* CONFIG_MMU */
--
2.10.0
^ permalink raw reply related [flat|nested] 171+ messages in thread
* [PATCH v3 16/32] mips: include default ioremap_nopost() implementation
2017-04-11 12:28 ` Lorenzo Pieralisi
@ 2017-04-11 12:28 ` Lorenzo Pieralisi
-1 siblings, 0 replies; 171+ messages in thread
From: Lorenzo Pieralisi @ 2017-04-11 12:28 UTC (permalink / raw)
To: linux-pci
Cc: linux-arch, linux-kernel, linux-arm-kernel, Lorenzo Pieralisi,
Ralf Baechle, Huacai Chen, Bjorn Helgaas
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.
Include the asm-generic ioremap_nopost() implementation (currently
falling back to ioremap_nocache()) to provide a non-posted writes
ioremap interface to kernel subsystems.
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: Huacai Chen <chenhc@lemote.com>
Cc: Bjorn Helgaas <bhelgaas@google.com>
---
arch/mips/include/asm/io.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/mips/include/asm/io.h b/arch/mips/include/asm/io.h
index ecabc00..d8d1bae 100644
--- a/arch/mips/include/asm/io.h
+++ b/arch/mips/include/asm/io.h
@@ -257,6 +257,7 @@ static inline void __iomem * __ioremap_mode(phys_addr_t offset, unsigned long si
#define ioremap_nocache(offset, size) \
__ioremap_mode((offset), (size), _CACHE_UNCACHED)
#define ioremap_uc ioremap_nocache
+#include <asm-generic/ioremap-nopost.h>
/*
* ioremap_cachable - map bus memory into CPU space
--
2.10.0
^ permalink raw reply related [flat|nested] 171+ messages in thread
* [PATCH v3 16/32] mips: include default ioremap_nopost() implementation
@ 2017-04-11 12:28 ` Lorenzo Pieralisi
0 siblings, 0 replies; 171+ messages in thread
From: Lorenzo Pieralisi @ 2017-04-11 12:28 UTC (permalink / raw)
To: linux-arm-kernel
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.
Include the asm-generic ioremap_nopost() implementation (currently
falling back to ioremap_nocache()) to provide a non-posted writes
ioremap interface to kernel subsystems.
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: Huacai Chen <chenhc@lemote.com>
Cc: Bjorn Helgaas <bhelgaas@google.com>
---
arch/mips/include/asm/io.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/mips/include/asm/io.h b/arch/mips/include/asm/io.h
index ecabc00..d8d1bae 100644
--- a/arch/mips/include/asm/io.h
+++ b/arch/mips/include/asm/io.h
@@ -257,6 +257,7 @@ static inline void __iomem * __ioremap_mode(phys_addr_t offset, unsigned long si
#define ioremap_nocache(offset, size) \
__ioremap_mode((offset), (size), _CACHE_UNCACHED)
#define ioremap_uc ioremap_nocache
+#include <asm-generic/ioremap-nopost.h>
/*
* ioremap_cachable - map bus memory into CPU space
--
2.10.0
^ permalink raw reply related [flat|nested] 171+ messages in thread
* [PATCH v3 17/32] mn10300: include default ioremap_nopost() implementation
2017-04-11 12:28 ` Lorenzo Pieralisi
@ 2017-04-11 12:28 ` Lorenzo Pieralisi
-1 siblings, 0 replies; 171+ messages in thread
From: Lorenzo Pieralisi @ 2017-04-11 12:28 UTC (permalink / raw)
To: linux-pci
Cc: linux-arch, linux-kernel, linux-arm-kernel, Lorenzo Pieralisi,
Bjorn Helgaas, David Howells
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.
Include the asm-generic ioremap_nopost() implementation (currently
falling back to ioremap_nocache()) to provide a non-posted writes
ioremap interface to kernel subsystems.
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Cc: David Howells <dhowells@redhat.com>
---
arch/mn10300/include/asm/io.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/mn10300/include/asm/io.h b/arch/mn10300/include/asm/io.h
index 6218935..95a3c20 100644
--- a/arch/mn10300/include/asm/io.h
+++ b/arch/mn10300/include/asm/io.h
@@ -284,6 +284,7 @@ static inline void __iomem *ioremap_nocache(unsigned long offset, unsigned long
#define ioremap_wc ioremap_nocache
#define ioremap_wt ioremap_nocache
#define ioremap_uc ioremap_nocache
+#include <asm-generic/ioremap-nopost.h>
static inline void iounmap(void __iomem *addr)
{
--
2.10.0
^ permalink raw reply related [flat|nested] 171+ messages in thread* [PATCH v3 17/32] mn10300: include default ioremap_nopost() implementation
@ 2017-04-11 12:28 ` Lorenzo Pieralisi
0 siblings, 0 replies; 171+ messages in thread
From: Lorenzo Pieralisi @ 2017-04-11 12:28 UTC (permalink / raw)
To: linux-arm-kernel
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.
Include the asm-generic ioremap_nopost() implementation (currently
falling back to ioremap_nocache()) to provide a non-posted writes
ioremap interface to kernel subsystems.
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Cc: David Howells <dhowells@redhat.com>
---
arch/mn10300/include/asm/io.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/mn10300/include/asm/io.h b/arch/mn10300/include/asm/io.h
index 6218935..95a3c20 100644
--- a/arch/mn10300/include/asm/io.h
+++ b/arch/mn10300/include/asm/io.h
@@ -284,6 +284,7 @@ static inline void __iomem *ioremap_nocache(unsigned long offset, unsigned long
#define ioremap_wc ioremap_nocache
#define ioremap_wt ioremap_nocache
#define ioremap_uc ioremap_nocache
+#include <asm-generic/ioremap-nopost.h>
static inline void iounmap(void __iomem *addr)
{
--
2.10.0
^ permalink raw reply related [flat|nested] 171+ messages in thread
* [PATCH v3 18/32] nios2: include default ioremap_nopost() implementation
2017-04-11 12:28 ` Lorenzo Pieralisi
@ 2017-04-11 12:28 ` Lorenzo Pieralisi
-1 siblings, 0 replies; 171+ messages in thread
From: Lorenzo Pieralisi @ 2017-04-11 12:28 UTC (permalink / raw)
To: linux-pci
Cc: linux-arch, linux-kernel, linux-arm-kernel, Lorenzo Pieralisi,
Bjorn Helgaas, Ley Foon Tan
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.
Include the asm-generic ioremap_nopost() implementation (currently
falling back to ioremap_nocache()) to provide a non-posted writes
ioremap interface to kernel subsystems.
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Cc: Ley Foon Tan <lftan@altera.com>
---
arch/nios2/include/asm/io.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/nios2/include/asm/io.h b/arch/nios2/include/asm/io.h
index ce072ba..ff8ac76 100644
--- a/arch/nios2/include/asm/io.h
+++ b/arch/nios2/include/asm/io.h
@@ -47,6 +47,7 @@ static inline void iounmap(void __iomem *addr)
#define ioremap_wc ioremap_nocache
#define ioremap_wt ioremap_nocache
+#include <asm-generic/ioremap-nopost.h>
/* Pages to physical address... */
#define page_to_phys(page) virt_to_phys(page_to_virt(page))
--
2.10.0
^ permalink raw reply related [flat|nested] 171+ messages in thread
* [PATCH v3 18/32] nios2: include default ioremap_nopost() implementation
@ 2017-04-11 12:28 ` Lorenzo Pieralisi
0 siblings, 0 replies; 171+ messages in thread
From: Lorenzo Pieralisi @ 2017-04-11 12:28 UTC (permalink / raw)
To: linux-arm-kernel
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.
Include the asm-generic ioremap_nopost() implementation (currently
falling back to ioremap_nocache()) to provide a non-posted writes
ioremap interface to kernel subsystems.
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Cc: Ley Foon Tan <lftan@altera.com>
---
arch/nios2/include/asm/io.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/nios2/include/asm/io.h b/arch/nios2/include/asm/io.h
index ce072ba..ff8ac76 100644
--- a/arch/nios2/include/asm/io.h
+++ b/arch/nios2/include/asm/io.h
@@ -47,6 +47,7 @@ static inline void iounmap(void __iomem *addr)
#define ioremap_wc ioremap_nocache
#define ioremap_wt ioremap_nocache
+#include <asm-generic/ioremap-nopost.h>
/* Pages to physical address... */
#define page_to_phys(page) virt_to_phys(page_to_virt(page))
--
2.10.0
^ permalink raw reply related [flat|nested] 171+ messages in thread
* [PATCH v3 19/32] openrisc: include default ioremap_nopost() implementation
2017-04-11 12:28 ` Lorenzo Pieralisi
@ 2017-04-11 12:28 ` Lorenzo Pieralisi
-1 siblings, 0 replies; 171+ messages in thread
From: Lorenzo Pieralisi @ 2017-04-11 12:28 UTC (permalink / raw)
To: linux-pci
Cc: linux-arch, linux-kernel, linux-arm-kernel, Lorenzo Pieralisi,
Jonas Bonn, Bjorn Helgaas, Stafford Horne, Stefan Kristiansson
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.
Include the asm-generic ioremap_nopost() implementation (currently
falling back to ioremap_nocache()) to provide a non-posted writes
ioremap interface to kernel subsystems.
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Cc: Jonas Bonn <jonas@southpole.se>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Cc: Stafford Horne <shorne@gmail.com>
Cc: Stefan Kristiansson <stefan.kristiansson@saunalahti.fi>
---
arch/openrisc/include/asm/io.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/openrisc/include/asm/io.h b/arch/openrisc/include/asm/io.h
index 7c69139..1cea257 100644
--- a/arch/openrisc/include/asm/io.h
+++ b/arch/openrisc/include/asm/io.h
@@ -48,5 +48,7 @@ static inline void __iomem *ioremap_nocache(phys_addr_t offset,
__pgprot(pgprot_val(PAGE_KERNEL) | _PAGE_CI));
}
+#include <asm-generic/ioremap-nopost.h>
+
extern void iounmap(void *addr);
#endif
--
2.10.0
^ permalink raw reply related [flat|nested] 171+ messages in thread
* [PATCH v3 19/32] openrisc: include default ioremap_nopost() implementation
@ 2017-04-11 12:28 ` Lorenzo Pieralisi
0 siblings, 0 replies; 171+ messages in thread
From: Lorenzo Pieralisi @ 2017-04-11 12:28 UTC (permalink / raw)
To: linux-arm-kernel
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.
Include the asm-generic ioremap_nopost() implementation (currently
falling back to ioremap_nocache()) to provide a non-posted writes
ioremap interface to kernel subsystems.
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Cc: Jonas Bonn <jonas@southpole.se>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Cc: Stafford Horne <shorne@gmail.com>
Cc: Stefan Kristiansson <stefan.kristiansson@saunalahti.fi>
---
arch/openrisc/include/asm/io.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/openrisc/include/asm/io.h b/arch/openrisc/include/asm/io.h
index 7c69139..1cea257 100644
--- a/arch/openrisc/include/asm/io.h
+++ b/arch/openrisc/include/asm/io.h
@@ -48,5 +48,7 @@ static inline void __iomem *ioremap_nocache(phys_addr_t offset,
__pgprot(pgprot_val(PAGE_KERNEL) | _PAGE_CI));
}
+#include <asm-generic/ioremap-nopost.h>
+
extern void iounmap(void *addr);
#endif
--
2.10.0
^ permalink raw reply related [flat|nested] 171+ messages in thread
* [PATCH v3 20/32] parisc: include default ioremap_nopost() implementation
2017-04-11 12:28 ` Lorenzo Pieralisi
@ 2017-04-11 12:29 ` Lorenzo Pieralisi
-1 siblings, 0 replies; 171+ messages in thread
From: Lorenzo Pieralisi @ 2017-04-11 12:29 UTC (permalink / raw)
To: linux-pci
Cc: linux-arch, linux-kernel, linux-arm-kernel, Lorenzo Pieralisi,
Bjorn Helgaas, James E.J. Bottomley, Helge Deller
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.
Include the asm-generic ioremap_nopost() implementation (currently
falling back to ioremap_nocache()) to provide a non-posted writes
ioremap interface to kernel subsystems.
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Cc: "James E.J. Bottomley" <jejb@parisc-linux.org>
Cc: Helge Deller <deller@gmx.de>
---
arch/parisc/include/asm/io.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/parisc/include/asm/io.h b/arch/parisc/include/asm/io.h
index 1a16f1d..373ba75 100644
--- a/arch/parisc/include/asm/io.h
+++ b/arch/parisc/include/asm/io.h
@@ -139,6 +139,7 @@ static inline void __iomem * ioremap(unsigned long offset, unsigned long size)
#define ioremap_nocache(off, sz) ioremap((off), (sz))
#define ioremap_wc ioremap_nocache
#define ioremap_uc ioremap_nocache
+#include <asm-generic/ioremap-nopost.h>
extern void iounmap(const volatile void __iomem *addr);
--
2.10.0
^ permalink raw reply related [flat|nested] 171+ messages in thread
* [PATCH v3 20/32] parisc: include default ioremap_nopost() implementation
@ 2017-04-11 12:29 ` Lorenzo Pieralisi
0 siblings, 0 replies; 171+ messages in thread
From: Lorenzo Pieralisi @ 2017-04-11 12:29 UTC (permalink / raw)
To: linux-arm-kernel
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.
Include the asm-generic ioremap_nopost() implementation (currently
falling back to ioremap_nocache()) to provide a non-posted writes
ioremap interface to kernel subsystems.
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Cc: "James E.J. Bottomley" <jejb@parisc-linux.org>
Cc: Helge Deller <deller@gmx.de>
---
arch/parisc/include/asm/io.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/parisc/include/asm/io.h b/arch/parisc/include/asm/io.h
index 1a16f1d..373ba75 100644
--- a/arch/parisc/include/asm/io.h
+++ b/arch/parisc/include/asm/io.h
@@ -139,6 +139,7 @@ static inline void __iomem * ioremap(unsigned long offset, unsigned long size)
#define ioremap_nocache(off, sz) ioremap((off), (sz))
#define ioremap_wc ioremap_nocache
#define ioremap_uc ioremap_nocache
+#include <asm-generic/ioremap-nopost.h>
extern void iounmap(const volatile void __iomem *addr);
--
2.10.0
^ permalink raw reply related [flat|nested] 171+ messages in thread
* [PATCH v3 21/32] powerpc: include default ioremap_nopost() implementation
2017-04-11 12:28 ` Lorenzo Pieralisi
@ 2017-04-11 12:29 ` Lorenzo Pieralisi
-1 siblings, 0 replies; 171+ messages in thread
From: Lorenzo Pieralisi @ 2017-04-11 12:29 UTC (permalink / raw)
To: linux-pci
Cc: linux-arch, linux-kernel, linux-arm-kernel, Lorenzo Pieralisi,
Michael Ellerman, Bjorn Helgaas, Benjamin Herrenschmidt,
Paul Mackerras
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.
Include the asm-generic ioremap_nopost() implementation (currently
falling back to ioremap_nocache()) to provide a non-posted writes
ioremap interface to kernel subsystems.
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Paul Mackerras <paulus@samba.org>
---
arch/powerpc/include/asm/io.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/powerpc/include/asm/io.h b/arch/powerpc/include/asm/io.h
index 5ed2924..6dcd0e2 100644
--- a/arch/powerpc/include/asm/io.h
+++ b/arch/powerpc/include/asm/io.h
@@ -757,6 +757,7 @@ extern void __iomem *ioremap_prot(phys_addr_t address, unsigned long size,
extern void __iomem *ioremap_wc(phys_addr_t address, unsigned long size);
#define ioremap_nocache(addr, size) ioremap((addr), (size))
#define ioremap_uc(addr, size) ioremap((addr), (size))
+#include <asm-generic/ioremap-nopost.h>
extern void iounmap(volatile void __iomem *addr);
--
2.10.0
^ permalink raw reply related [flat|nested] 171+ messages in thread
* [PATCH v3 21/32] powerpc: include default ioremap_nopost() implementation
@ 2017-04-11 12:29 ` Lorenzo Pieralisi
0 siblings, 0 replies; 171+ messages in thread
From: Lorenzo Pieralisi @ 2017-04-11 12:29 UTC (permalink / raw)
To: linux-arm-kernel
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.
Include the asm-generic ioremap_nopost() implementation (currently
falling back to ioremap_nocache()) to provide a non-posted writes
ioremap interface to kernel subsystems.
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Paul Mackerras <paulus@samba.org>
---
arch/powerpc/include/asm/io.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/powerpc/include/asm/io.h b/arch/powerpc/include/asm/io.h
index 5ed2924..6dcd0e2 100644
--- a/arch/powerpc/include/asm/io.h
+++ b/arch/powerpc/include/asm/io.h
@@ -757,6 +757,7 @@ extern void __iomem *ioremap_prot(phys_addr_t address, unsigned long size,
extern void __iomem *ioremap_wc(phys_addr_t address, unsigned long size);
#define ioremap_nocache(addr, size) ioremap((addr), (size))
#define ioremap_uc(addr, size) ioremap((addr), (size))
+#include <asm-generic/ioremap-nopost.h>
extern void iounmap(volatile void __iomem *addr);
--
2.10.0
^ permalink raw reply related [flat|nested] 171+ messages in thread
* Re: [PATCH v3 21/32] powerpc: include default ioremap_nopost() implementation
2017-04-11 12:29 ` Lorenzo Pieralisi
(?)
(?)
@ 2017-04-11 13:38 ` Benjamin Herrenschmidt
-1 siblings, 0 replies; 171+ messages in thread
From: Benjamin Herrenschmidt @ 2017-04-11 13:38 UTC (permalink / raw)
To: Lorenzo Pieralisi, linux-pci
Cc: linux-arch, linux-kernel, linux-arm-kernel, Michael Ellerman,
Bjorn Helgaas, Paul Mackerras
On Tue, 2017-04-11 at 13:29 +0100, Lorenzo Pieralisi wrote:
> 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.
>
> Include the asm-generic ioremap_nopost() implementation (currently
> falling back to ioremap_nocache()) to provide a non-posted writes
> ioremap interface to kernel subsystems.
NAK. As explained in my reply to patch 0.
> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> > Cc: Michael Ellerman <mpe@ellerman.id.au>
> > Cc: Bjorn Helgaas <bhelgaas@google.com>
> > Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> > Cc: Paul Mackerras <paulus@samba.org>
> ---
> arch/powerpc/include/asm/io.h | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/powerpc/include/asm/io.h b/arch/powerpc/include/asm/io.h
> index 5ed2924..6dcd0e2 100644
> --- a/arch/powerpc/include/asm/io.h
> +++ b/arch/powerpc/include/asm/io.h
> @@ -757,6 +757,7 @@ extern void __iomem *ioremap_prot(phys_addr_t address, unsigned long size,
> extern void __iomem *ioremap_wc(phys_addr_t address, unsigned long size);
> > #define ioremap_nocache(addr, size) ioremap((addr), (size))
> > #define ioremap_uc(addr, size) ioremap((addr), (size))
> +#include <asm-generic/ioremap-nopost.h>
>
> extern void iounmap(volatile void __iomem *addr);
>
^ permalink raw reply [flat|nested] 171+ messages in thread
* [PATCH v3 21/32] powerpc: include default ioremap_nopost() implementation
@ 2017-04-11 13:38 ` Benjamin Herrenschmidt
0 siblings, 0 replies; 171+ messages in thread
From: Benjamin Herrenschmidt @ 2017-04-11 13:38 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, 2017-04-11 at 13:29 +0100, Lorenzo Pieralisi wrote:
> 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.
>
> Include the asm-generic ioremap_nopost() implementation (currently
> falling back to ioremap_nocache()) to provide a non-posted writes
> ioremap interface to kernel subsystems.
NAK. As explained in my reply to patch 0.
> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> > Cc: Michael Ellerman <mpe@ellerman.id.au>
> > Cc: Bjorn Helgaas <bhelgaas@google.com>
> > Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> > Cc: Paul Mackerras <paulus@samba.org>
> ---
> ?arch/powerpc/include/asm/io.h | 1 +
> ?1 file changed, 1 insertion(+)
>
> diff --git a/arch/powerpc/include/asm/io.h b/arch/powerpc/include/asm/io.h
> index 5ed2924..6dcd0e2 100644
> --- a/arch/powerpc/include/asm/io.h
> +++ b/arch/powerpc/include/asm/io.h
> @@ -757,6 +757,7 @@ extern void __iomem *ioremap_prot(phys_addr_t address, unsigned long size,
> ?extern void __iomem *ioremap_wc(phys_addr_t address, unsigned long size);
> > ?#define ioremap_nocache(addr, size) ioremap((addr), (size))
> > ?#define ioremap_uc(addr, size) ioremap((addr), (size))
> +#include <asm-generic/ioremap-nopost.h>
> ?
> ?extern void iounmap(volatile void __iomem *addr);
> ?
^ permalink raw reply [flat|nested] 171+ messages in thread
* Re: [PATCH v3 21/32] powerpc: include default ioremap_nopost() implementation
@ 2017-04-11 13:38 ` Benjamin Herrenschmidt
0 siblings, 0 replies; 171+ messages in thread
From: Benjamin Herrenschmidt @ 2017-04-11 13:38 UTC (permalink / raw)
To: Lorenzo Pieralisi, linux-pci
Cc: linux-arch, Michael Ellerman, linux-kernel, Paul Mackerras,
Bjorn Helgaas, linux-arm-kernel
On Tue, 2017-04-11 at 13:29 +0100, Lorenzo Pieralisi wrote:
> 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.
>
> Include the asm-generic ioremap_nopost() implementation (currently
> falling back to ioremap_nocache()) to provide a non-posted writes
> ioremap interface to kernel subsystems.
NAK. As explained in my reply to patch 0.
> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> > Cc: Michael Ellerman <mpe@ellerman.id.au>
> > Cc: Bjorn Helgaas <bhelgaas@google.com>
> > Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> > Cc: Paul Mackerras <paulus@samba.org>
> ---
> arch/powerpc/include/asm/io.h | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/powerpc/include/asm/io.h b/arch/powerpc/include/asm/io.h
> index 5ed2924..6dcd0e2 100644
> --- a/arch/powerpc/include/asm/io.h
> +++ b/arch/powerpc/include/asm/io.h
> @@ -757,6 +757,7 @@ extern void __iomem *ioremap_prot(phys_addr_t address, unsigned long size,
> extern void __iomem *ioremap_wc(phys_addr_t address, unsigned long size);
> > #define ioremap_nocache(addr, size) ioremap((addr), (size))
> > #define ioremap_uc(addr, size) ioremap((addr), (size))
> +#include <asm-generic/ioremap-nopost.h>
>
> extern void iounmap(volatile void __iomem *addr);
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 171+ messages in thread
* Re: [PATCH v3 21/32] powerpc: include default ioremap_nopost() implementation
@ 2017-04-11 13:38 ` Benjamin Herrenschmidt
0 siblings, 0 replies; 171+ messages in thread
From: Benjamin Herrenschmidt @ 2017-04-11 13:38 UTC (permalink / raw)
To: Lorenzo Pieralisi, linux-pci
Cc: linux-arch, Michael Ellerman, linux-kernel, Paul Mackerras,
Bjorn Helgaas, linux-arm-kernel
T24gVHVlLCAyMDE3LTA0LTExIGF0IDEzOjI5ICswMTAwLCBMb3JlbnpvIFBpZXJhbGlzaSB3cm90
ZToKPiBUaGUgUENJIHNwZWNpZmljYXRpb25zIChSZXYgMy4wLCAzLjIuNSAiVHJhbnNhY3Rpb24g
T3JkZXJpbmcgYW5kIFBvc3RpbmciKQo+IG1hbmRhdGUgbm9uLXBvc3RlZCBjb25maWd1cmF0aW9u
IHRyYW5zYWN0aW9ucy4gQXMgZnVydGhlciBoaWdobGlnaHRlZCBpbgo+IHRoZSBQQ0llIHNwZWNp
ZmljYXRpb25zICg0LjAgLSBSZXYwLjMsICJPcmRlcmluZyBDb25zaWRlcmF0aW9ucyBmb3IgdGhl
Cj4gRW5oYW5jZWQgQ29uZmlndXJhdGlvbiBBY2Nlc3MgTWVjaGFuaXNtIiksIHRocm91Z2ggRUNB
TSBhbmQKPiBFQ0FNLWRlcml2YXRpdmUgY29uZmlndXJhdGlvbiBtZWNoYW5pc20sIHRoZSBtZW1v
cnkgbWFwcGVkIHRyYW5zYWN0aW9ucwo+IGZyb20gdGhlIGhvc3QgQ1BVIGludG8gQ29uZmlndXJh
dGlvbiBSZXF1ZXN0cyBvbiB0aGUgUENJIGV4cHJlc3MgZmFicmljCj4gbWF5IGNyZWF0ZSBvcmRl
cmluZyBwcm9ibGVtcyBmb3Igc29mdHdhcmUgYmVjYXVzZSB3cml0ZXMgdG8gbWVtb3J5Cj4gYWRk
cmVzcyBhcmUgdHlwaWNhbGx5IHBvc3RlZCB0cmFuc2FjdGlvbnMgKHVubGVzcyB0aGUgYXJjaGl0
ZWN0dXJlIGNhbgo+IGVuZm9yY2UgdGhyb3VnaCB2aXJ0dWFsIGFkZHJlc3MgbWFwcGluZyBub24t
cG9zdGVkIHdyaXRlIHRyYW5zYWN0aW9ucwo+IGJlaGF2aW91cikgYnV0IHdyaXRlcyB0byBDb25m
aWd1cmF0aW9uIFNwYWNlIGFyZSBub3QgcG9zdGVkIG9uIHRoZSBQQ0kKPiBleHByZXNzIGZhYnJp
Yy4KPiAKPiBJbmNsdWRlIHRoZSBhc20tZ2VuZXJpYyBpb3JlbWFwX25vcG9zdCgpIGltcGxlbWVu
dGF0aW9uIChjdXJyZW50bHkKPiBmYWxsaW5nIGJhY2sgdG8gaW9yZW1hcF9ub2NhY2hlKCkpIHRv
IHByb3ZpZGUgYSBub24tcG9zdGVkIHdyaXRlcwo+IGlvcmVtYXAgaW50ZXJmYWNlIHRvIGtlcm5l
bCBzdWJzeXN0ZW1zLgoKTkFLLiBBcyBleHBsYWluZWQgaW4gbXkgcmVwbHkgdG8gcGF0Y2ggMC4K
Cj4gU2lnbmVkLW9mZi1ieTogTG9yZW56byBQaWVyYWxpc2kgPGxvcmVuem8ucGllcmFsaXNpQGFy
bS5jb20+Cj4gPiBDYzogTWljaGFlbCBFbGxlcm1hbiA8bXBlQGVsbGVybWFuLmlkLmF1Pgo+ID4g
Q2M6IEJqb3JuIEhlbGdhYXMgPGJoZWxnYWFzQGdvb2dsZS5jb20+Cj4gPiBDYzogQmVuamFtaW4g
SGVycmVuc2NobWlkdCA8YmVuaEBrZXJuZWwuY3Jhc2hpbmcub3JnPgo+ID4gQ2M6IFBhdWwgTWFj
a2VycmFzIDxwYXVsdXNAc2FtYmEub3JnPgo+IC0tLQo+IMKgYXJjaC9wb3dlcnBjL2luY2x1ZGUv
YXNtL2lvLmggfCAxICsKPiDCoDEgZmlsZSBjaGFuZ2VkLCAxIGluc2VydGlvbigrKQo+IAo+IGRp
ZmYgLS1naXQgYS9hcmNoL3Bvd2VycGMvaW5jbHVkZS9hc20vaW8uaCBiL2FyY2gvcG93ZXJwYy9p
bmNsdWRlL2FzbS9pby5oCj4gaW5kZXggNWVkMjkyNC4uNmRjZDBlMiAxMDA2NDQKPiAtLS0gYS9h
cmNoL3Bvd2VycGMvaW5jbHVkZS9hc20vaW8uaAo+ICsrKyBiL2FyY2gvcG93ZXJwYy9pbmNsdWRl
L2FzbS9pby5oCj4gQEAgLTc1Nyw2ICs3NTcsNyBAQCBleHRlcm4gdm9pZCBfX2lvbWVtICppb3Jl
bWFwX3Byb3QocGh5c19hZGRyX3QgYWRkcmVzcywgdW5zaWduZWQgbG9uZyBzaXplLAo+IMKgZXh0
ZXJuIHZvaWQgX19pb21lbSAqaW9yZW1hcF93YyhwaHlzX2FkZHJfdCBhZGRyZXNzLCB1bnNpZ25l
ZCBsb25nIHNpemUpOwo+ID4gwqAjZGVmaW5lIGlvcmVtYXBfbm9jYWNoZShhZGRyLCBzaXplKQlp
b3JlbWFwKChhZGRyKSwgKHNpemUpKQo+ID4gwqAjZGVmaW5lIGlvcmVtYXBfdWMoYWRkciwgc2l6
ZSkJCWlvcmVtYXAoKGFkZHIpLCAoc2l6ZSkpCj4gKyNpbmNsdWRlIDxhc20tZ2VuZXJpYy9pb3Jl
bWFwLW5vcG9zdC5oPgo+IMKgCj4gwqBleHRlcm4gdm9pZCBpb3VubWFwKHZvbGF0aWxlIHZvaWQg
X19pb21lbSAqYWRkcik7Cj4gwqAKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fCmxpbnV4LWFybS1rZXJuZWwgbWFpbGluZyBsaXN0CmxpbnV4LWFybS1rZXJu
ZWxAbGlzdHMuaW5mcmFkZWFkLm9yZwpodHRwOi8vbGlzdHMuaW5mcmFkZWFkLm9yZy9tYWlsbWFu
L2xpc3RpbmZvL2xpbnV4LWFybS1rZXJuZWwK
^ permalink raw reply [flat|nested] 171+ messages in thread
* Re: [PATCH v3 21/32] powerpc: include default ioremap_nopost() implementation
2017-04-11 13:38 ` Benjamin Herrenschmidt
(?)
@ 2017-04-11 14:24 ` Lorenzo Pieralisi
-1 siblings, 0 replies; 171+ messages in thread
From: Lorenzo Pieralisi @ 2017-04-11 14:24 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: linux-pci, linux-arch, linux-kernel, linux-arm-kernel,
Michael Ellerman, Bjorn Helgaas, Paul Mackerras
On Tue, Apr 11, 2017 at 11:38:48PM +1000, Benjamin Herrenschmidt wrote:
> On Tue, 2017-04-11 at 13:29 +0100, Lorenzo Pieralisi wrote:
> > 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.
> >
> > Include the asm-generic ioremap_nopost() implementation (currently
> > falling back to ioremap_nocache()) to provide a non-posted writes
> > ioremap interface to kernel subsystems.
>
> NAK. As explained in my reply to patch 0.
Ok, point taken. BTW, may I ask you guys to have a look into this
please ?
https://lkml.org/lkml/2017/4/6/743
It is a side effect of this thread (v2), not sure why <asm/io.h>
on powerpc has to include <linux/io.h>.
Thanks,
Lorenzo
> > Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> > > Cc: Michael Ellerman <mpe@ellerman.id.au>
> > > Cc: Bjorn Helgaas <bhelgaas@google.com>
> > > Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> > > Cc: Paul Mackerras <paulus@samba.org>
> > ---
> > arch/powerpc/include/asm/io.h | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/arch/powerpc/include/asm/io.h b/arch/powerpc/include/asm/io.h
> > index 5ed2924..6dcd0e2 100644
> > --- a/arch/powerpc/include/asm/io.h
> > +++ b/arch/powerpc/include/asm/io.h
> > @@ -757,6 +757,7 @@ extern void __iomem *ioremap_prot(phys_addr_t address, unsigned long size,
> > extern void __iomem *ioremap_wc(phys_addr_t address, unsigned long size);
> > > #define ioremap_nocache(addr, size) ioremap((addr), (size))
> > > #define ioremap_uc(addr, size) ioremap((addr), (size))
> > +#include <asm-generic/ioremap-nopost.h>
> >
> > extern void iounmap(volatile void __iomem *addr);
> >
^ permalink raw reply [flat|nested] 171+ messages in thread
* [PATCH v3 21/32] powerpc: include default ioremap_nopost() implementation
@ 2017-04-11 14:24 ` Lorenzo Pieralisi
0 siblings, 0 replies; 171+ messages in thread
From: Lorenzo Pieralisi @ 2017-04-11 14:24 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, Apr 11, 2017 at 11:38:48PM +1000, Benjamin Herrenschmidt wrote:
> On Tue, 2017-04-11 at 13:29 +0100, Lorenzo Pieralisi wrote:
> > 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.
> >
> > Include the asm-generic ioremap_nopost() implementation (currently
> > falling back to ioremap_nocache()) to provide a non-posted writes
> > ioremap interface to kernel subsystems.
>
> NAK. As explained in my reply to patch 0.
Ok, point taken. BTW, may I ask you guys to have a look into this
please ?
https://lkml.org/lkml/2017/4/6/743
It is a side effect of this thread (v2), not sure why <asm/io.h>
on powerpc has to include <linux/io.h>.
Thanks,
Lorenzo
> > Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> > > Cc: Michael Ellerman <mpe@ellerman.id.au>
> > > Cc: Bjorn Helgaas <bhelgaas@google.com>
> > > Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> > > Cc: Paul Mackerras <paulus@samba.org>
> > ---
> > ?arch/powerpc/include/asm/io.h | 1 +
> > ?1 file changed, 1 insertion(+)
> >
> > diff --git a/arch/powerpc/include/asm/io.h b/arch/powerpc/include/asm/io.h
> > index 5ed2924..6dcd0e2 100644
> > --- a/arch/powerpc/include/asm/io.h
> > +++ b/arch/powerpc/include/asm/io.h
> > @@ -757,6 +757,7 @@ extern void __iomem *ioremap_prot(phys_addr_t address, unsigned long size,
> > ?extern void __iomem *ioremap_wc(phys_addr_t address, unsigned long size);
> > > ?#define ioremap_nocache(addr, size) ioremap((addr), (size))
> > > ?#define ioremap_uc(addr, size) ioremap((addr), (size))
> > +#include <asm-generic/ioremap-nopost.h>
> > ?
> > ?extern void iounmap(volatile void __iomem *addr);
> > ?
^ permalink raw reply [flat|nested] 171+ messages in thread
* Re: [PATCH v3 21/32] powerpc: include default ioremap_nopost() implementation
@ 2017-04-11 14:24 ` Lorenzo Pieralisi
0 siblings, 0 replies; 171+ messages in thread
From: Lorenzo Pieralisi @ 2017-04-11 14:24 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: linux-arch, linux-pci, linux-kernel, Paul Mackerras,
Michael Ellerman, Bjorn Helgaas, linux-arm-kernel
On Tue, Apr 11, 2017 at 11:38:48PM +1000, Benjamin Herrenschmidt wrote:
> On Tue, 2017-04-11 at 13:29 +0100, Lorenzo Pieralisi wrote:
> > The PCI specifications (Rev 3.0, 3.2.5 "Transaction Ordering and Postin=
g")
> > 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.
> > =
> > Include the asm-generic ioremap_nopost() implementation (currently
> > falling back to ioremap_nocache()) to provide a non-posted writes
> > ioremap interface to kernel subsystems.
> =
> NAK. As explained in my reply to patch 0.
Ok, point taken. BTW, may I ask you guys to have a look into this
please ?
https://lkml.org/lkml/2017/4/6/743
It is a side effect of this thread (v2), not sure why <asm/io.h>
on powerpc has to include <linux/io.h>.
Thanks,
Lorenzo
> > Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> > > Cc: Michael Ellerman <mpe@ellerman.id.au>
> > > Cc: Bjorn Helgaas <bhelgaas@google.com>
> > > Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> > > Cc: Paul Mackerras <paulus@samba.org>
> > ---
> > =A0arch/powerpc/include/asm/io.h | 1 +
> > =A01 file changed, 1 insertion(+)
> > =
> > diff --git a/arch/powerpc/include/asm/io.h b/arch/powerpc/include/asm/i=
o.h
> > index 5ed2924..6dcd0e2 100644
> > --- a/arch/powerpc/include/asm/io.h
> > +++ b/arch/powerpc/include/asm/io.h
> > @@ -757,6 +757,7 @@ extern void __iomem *ioremap_prot(phys_addr_t addre=
ss, unsigned long size,
> > =A0extern void __iomem *ioremap_wc(phys_addr_t address, unsigned long s=
ize);
> > > =A0#define ioremap_nocache(addr, size) ioremap((addr), (size))
> > > =A0#define ioremap_uc(addr, size) ioremap((addr), (size))
> > +#include <asm-generic/ioremap-nopost.h>
> > =A0
> > =A0extern void iounmap(volatile void __iomem *addr);
> > =A0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 171+ messages in thread
* Re: [PATCH v3 21/32] powerpc: include default ioremap_nopost() implementation
2017-04-11 14:24 ` Lorenzo Pieralisi
(?)
(?)
@ 2017-04-11 23:15 ` Benjamin Herrenschmidt
-1 siblings, 0 replies; 171+ messages in thread
From: Benjamin Herrenschmidt @ 2017-04-11 23:15 UTC (permalink / raw)
To: Lorenzo Pieralisi
Cc: linux-pci, linux-arch, linux-kernel, linux-arm-kernel,
Michael Ellerman, Bjorn Helgaas, Paul Mackerras
On Tue, 2017-04-11 at 15:24 +0100, Lorenzo Pieralisi wrote:
> Ok, point taken. BTW, may I ask you guys to have a look into this
> please ?
>
> https://lkml.org/lkml/2017/4/6/743
>
> It is a side effect of this thread (v2), not sure why <asm/io.h>
> on powerpc has to include <linux/io.h>.
Not sure how we ended up with that... it's odd indeed.
Michael ? Any reason we can't just remove it ?
Cheers,
Ben.
^ permalink raw reply [flat|nested] 171+ messages in thread
* [PATCH v3 21/32] powerpc: include default ioremap_nopost() implementation
@ 2017-04-11 23:15 ` Benjamin Herrenschmidt
0 siblings, 0 replies; 171+ messages in thread
From: Benjamin Herrenschmidt @ 2017-04-11 23:15 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, 2017-04-11 at 15:24 +0100, Lorenzo Pieralisi wrote:
> Ok, point taken. BTW, may I ask you guys to have a look into this
> please ?
>
> https://lkml.org/lkml/2017/4/6/743
>
> It is a side effect of this thread (v2), not sure why <asm/io.h>
> on powerpc has to include <linux/io.h>.
Not sure how we ended up with that... it's odd indeed.
Michael ? Any reason we can't just remove it ?
Cheers,
Ben.
^ permalink raw reply [flat|nested] 171+ messages in thread
* Re: [PATCH v3 21/32] powerpc: include default ioremap_nopost() implementation
@ 2017-04-11 23:15 ` Benjamin Herrenschmidt
0 siblings, 0 replies; 171+ messages in thread
From: Benjamin Herrenschmidt @ 2017-04-11 23:15 UTC (permalink / raw)
To: Lorenzo Pieralisi
Cc: linux-arch, linux-pci, linux-kernel, Paul Mackerras,
Michael Ellerman, Bjorn Helgaas, linux-arm-kernel
On Tue, 2017-04-11 at 15:24 +0100, Lorenzo Pieralisi wrote:
> Ok, point taken. BTW, may I ask you guys to have a look into this
> please ?
>
> https://lkml.org/lkml/2017/4/6/743
>
> It is a side effect of this thread (v2), not sure why <asm/io.h>
> on powerpc has to include <linux/io.h>.
Not sure how we ended up with that... it's odd indeed.
Michael ? Any reason we can't just remove it ?
Cheers,
Ben.
^ permalink raw reply [flat|nested] 171+ messages in thread
* Re: [PATCH v3 21/32] powerpc: include default ioremap_nopost() implementation
@ 2017-04-11 23:15 ` Benjamin Herrenschmidt
0 siblings, 0 replies; 171+ messages in thread
From: Benjamin Herrenschmidt @ 2017-04-11 23:15 UTC (permalink / raw)
To: Lorenzo Pieralisi
Cc: linux-arch, linux-pci, linux-kernel, Paul Mackerras,
Michael Ellerman, Bjorn Helgaas, linux-arm-kernel
On Tue, 2017-04-11 at 15:24 +0100, Lorenzo Pieralisi wrote:
> Ok, point taken. BTW, may I ask you guys to have a look into this
> please ?
>
> https://lkml.org/lkml/2017/4/6/743
>
> It is a side effect of this thread (v2), not sure why <asm/io.h>
> on powerpc has to include <linux/io.h>.
Not sure how we ended up with that... it's odd indeed.
Michael ? Any reason we can't just remove it ?
Cheers,
Ben.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 171+ messages in thread
* Re: [PATCH v3 21/32] powerpc: include default ioremap_nopost() implementation
2017-04-11 23:15 ` Benjamin Herrenschmidt
@ 2017-04-13 3:35 ` Michael Ellerman
-1 siblings, 0 replies; 171+ messages in thread
From: Michael Ellerman @ 2017-04-13 3:35 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Lorenzo Pieralisi
Cc: linux-pci, linux-arch, linux-kernel, linux-arm-kernel,
Bjorn Helgaas, Paul Mackerras
Benjamin Herrenschmidt <benh@kernel.crashing.org> writes:
> On Tue, 2017-04-11 at 15:24 +0100, Lorenzo Pieralisi wrote:
>> Ok, point taken. BTW, may I ask you guys to have a look into this
>> please ?
>>
>> https://lkml.org/lkml/2017/4/6/743
>>
>> It is a side effect of this thread (v2), not sure why <asm/io.h>
>> on powerpc has to include <linux/io.h>.
>
> Not sure how we ended up with that... it's odd indeed.
>
> Michael ? Any reason we can't just remove it ?
No ... idea.
Looks like it was added in:
commit b41e5fffe8b81fc939067d8c1c195cc79115d5a3
Author: Emil Medve <Emilian.Medve@Freescale.com>
AuthorDate: Sat May 3 06:34:04 2008 +1000
Commit: Paul Mackerras <paulus@samba.org>
CommitDate: Mon May 5 16:47:14 2008 +1000
[POWERPC] devres: Add devm_ioremap_prot()
We provide an ioremap_flags, so this provides a corresponding
devm_ioremap_prot. The slight name difference is at Ben
Herrenschmidt's request as he plans on changing ioremap_flags to
ioremap_prot in the future.
Signed-off-by: Emil Medve <Emilian.Medve@Freescale.com>
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
Acked-by: Tejun Heo <htejun@gmail.com>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Paul Mackerras <paulus@samba.org>
diff --git a/include/asm-powerpc/io.h b/include/asm-powerpc/io.h
index afae0697e8ce..e0062d73db1c 100644
--- a/include/asm-powerpc/io.h
+++ b/include/asm-powerpc/io.h
@@ -18,6 +18,9 @@ extern int check_legacy_ioport(unsigned long base_port);
#define _PNPWRP 0xa79
#define PNPBIOS_BASE 0xf000
+#include <linux/device.h>
+#include <linux/io.h>
+
#include <linux/compiler.h>
#include <asm/page.h>
#include <asm/byteorder.h>
@@ -744,6 +747,9 @@ static inline void * bus_to_virt(unsigned long address)
#define clrsetbits_8(addr, clear, set) clrsetbits(8, addr, clear, set)
+void __iomem *devm_ioremap_prot(struct device *dev, resource_size_t offset,
+ size_t size, unsigned long flags);
+
#endif /* __KERNEL__ */
#endif /* _ASM_POWERPC_IO_H */
I'll try removing it and see what breaks.
cheers
^ permalink raw reply related [flat|nested] 171+ messages in thread* [PATCH v3 21/32] powerpc: include default ioremap_nopost() implementation
@ 2017-04-13 3:35 ` Michael Ellerman
0 siblings, 0 replies; 171+ messages in thread
From: Michael Ellerman @ 2017-04-13 3:35 UTC (permalink / raw)
To: linux-arm-kernel
Benjamin Herrenschmidt <benh@kernel.crashing.org> writes:
> On Tue, 2017-04-11 at 15:24 +0100, Lorenzo Pieralisi wrote:
>> Ok, point taken. BTW, may I ask you guys to have a look into this
>> please ?
>>
>> https://lkml.org/lkml/2017/4/6/743
>>
>> It is a side effect of this thread (v2), not sure why <asm/io.h>
>> on powerpc has to include <linux/io.h>.
>
> Not sure how we ended up with that... it's odd indeed.
>
> Michael ? Any reason we can't just remove it ?
No ... idea.
Looks like it was added in:
commit b41e5fffe8b81fc939067d8c1c195cc79115d5a3
Author: Emil Medve <Emilian.Medve@Freescale.com>
AuthorDate: Sat May 3 06:34:04 2008 +1000
Commit: Paul Mackerras <paulus@samba.org>
CommitDate: Mon May 5 16:47:14 2008 +1000
[POWERPC] devres: Add devm_ioremap_prot()
We provide an ioremap_flags, so this provides a corresponding
devm_ioremap_prot. The slight name difference is at Ben
Herrenschmidt's request as he plans on changing ioremap_flags to
ioremap_prot in the future.
Signed-off-by: Emil Medve <Emilian.Medve@Freescale.com>
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
Acked-by: Tejun Heo <htejun@gmail.com>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Paul Mackerras <paulus@samba.org>
diff --git a/include/asm-powerpc/io.h b/include/asm-powerpc/io.h
index afae0697e8ce..e0062d73db1c 100644
--- a/include/asm-powerpc/io.h
+++ b/include/asm-powerpc/io.h
@@ -18,6 +18,9 @@ extern int check_legacy_ioport(unsigned long base_port);
#define _PNPWRP 0xa79
#define PNPBIOS_BASE 0xf000
+#include <linux/device.h>
+#include <linux/io.h>
+
#include <linux/compiler.h>
#include <asm/page.h>
#include <asm/byteorder.h>
@@ -744,6 +747,9 @@ static inline void * bus_to_virt(unsigned long address)
#define clrsetbits_8(addr, clear, set) clrsetbits(8, addr, clear, set)
+void __iomem *devm_ioremap_prot(struct device *dev, resource_size_t offset,
+ size_t size, unsigned long flags);
+
#endif /* __KERNEL__ */
#endif /* _ASM_POWERPC_IO_H */
I'll try removing it and see what breaks.
cheers
^ permalink raw reply related [flat|nested] 171+ messages in thread
* [PATCH v3 22/32] s390: include default ioremap_nopost() implementation
2017-04-11 12:28 ` Lorenzo Pieralisi
@ 2017-04-11 12:29 ` Lorenzo Pieralisi
-1 siblings, 0 replies; 171+ messages in thread
From: Lorenzo Pieralisi @ 2017-04-11 12:29 UTC (permalink / raw)
To: linux-pci
Cc: linux-arch, linux-kernel, linux-arm-kernel, Lorenzo Pieralisi,
Heiko Carstens, Bjorn Helgaas, Martin Schwidefsky
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.
Include the asm-generic ioremap_nopost() implementation (currently
falling back to ioremap_nocache()) to provide a non-posted writes
ioremap interface to kernel subsystems.
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
---
arch/s390/include/asm/io.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/s390/include/asm/io.h b/arch/s390/include/asm/io.h
index 437e9af..374fb43 100644
--- a/arch/s390/include/asm/io.h
+++ b/arch/s390/include/asm/io.h
@@ -39,6 +39,7 @@ static inline void __iomem *ioremap(unsigned long offset, unsigned long size)
static inline void iounmap(volatile void __iomem *addr)
{
}
+#include <asm-generic/ioremap-nopost.h>
static inline void __iomem *ioport_map(unsigned long port, unsigned int nr)
{
--
2.10.0
^ permalink raw reply related [flat|nested] 171+ messages in thread* [PATCH v3 22/32] s390: include default ioremap_nopost() implementation
@ 2017-04-11 12:29 ` Lorenzo Pieralisi
0 siblings, 0 replies; 171+ messages in thread
From: Lorenzo Pieralisi @ 2017-04-11 12:29 UTC (permalink / raw)
To: linux-arm-kernel
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.
Include the asm-generic ioremap_nopost() implementation (currently
falling back to ioremap_nocache()) to provide a non-posted writes
ioremap interface to kernel subsystems.
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
---
arch/s390/include/asm/io.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/s390/include/asm/io.h b/arch/s390/include/asm/io.h
index 437e9af..374fb43 100644
--- a/arch/s390/include/asm/io.h
+++ b/arch/s390/include/asm/io.h
@@ -39,6 +39,7 @@ static inline void __iomem *ioremap(unsigned long offset, unsigned long size)
static inline void iounmap(volatile void __iomem *addr)
{
}
+#include <asm-generic/ioremap-nopost.h>
static inline void __iomem *ioport_map(unsigned long port, unsigned int nr)
{
--
2.10.0
^ permalink raw reply related [flat|nested] 171+ messages in thread
* [PATCH v3 23/32] sh: include default ioremap_nopost() implementation
2017-04-11 12:28 ` Lorenzo Pieralisi
@ 2017-04-11 12:29 ` Lorenzo Pieralisi
-1 siblings, 0 replies; 171+ messages in thread
From: Lorenzo Pieralisi @ 2017-04-11 12:29 UTC (permalink / raw)
To: linux-pci
Cc: linux-arch, linux-kernel, linux-arm-kernel, Lorenzo Pieralisi,
Rich Felker, Bjorn Helgaas, Yoshinori Sato
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.
Include the asm-generic ioremap_nopost() implementation (currently
falling back to ioremap_nocache()) to provide a non-posted writes
ioremap interface to kernel subsystems.
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Cc: Rich Felker <dalias@libc.org>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Cc: Yoshinori Sato <ysato@users.sourceforge.jp>
---
arch/sh/include/asm/io.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/sh/include/asm/io.h b/arch/sh/include/asm/io.h
index 3280a6b..23814cd 100644
--- a/arch/sh/include/asm/io.h
+++ b/arch/sh/include/asm/io.h
@@ -371,6 +371,7 @@ static inline int iounmap_fixed(void __iomem *addr) { return -EINVAL; }
#define ioremap_nocache ioremap
#define ioremap_uc ioremap
#define iounmap __iounmap
+#include <asm-generic/ioremap-nopost.h>
/*
* Convert a physical pointer to a virtual kernel pointer for /dev/mem
--
2.10.0
^ permalink raw reply related [flat|nested] 171+ messages in thread* [PATCH v3 23/32] sh: include default ioremap_nopost() implementation
@ 2017-04-11 12:29 ` Lorenzo Pieralisi
0 siblings, 0 replies; 171+ messages in thread
From: Lorenzo Pieralisi @ 2017-04-11 12:29 UTC (permalink / raw)
To: linux-arm-kernel
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.
Include the asm-generic ioremap_nopost() implementation (currently
falling back to ioremap_nocache()) to provide a non-posted writes
ioremap interface to kernel subsystems.
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Cc: Rich Felker <dalias@libc.org>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Cc: Yoshinori Sato <ysato@users.sourceforge.jp>
---
arch/sh/include/asm/io.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/sh/include/asm/io.h b/arch/sh/include/asm/io.h
index 3280a6b..23814cd 100644
--- a/arch/sh/include/asm/io.h
+++ b/arch/sh/include/asm/io.h
@@ -371,6 +371,7 @@ static inline int iounmap_fixed(void __iomem *addr) { return -EINVAL; }
#define ioremap_nocache ioremap
#define ioremap_uc ioremap
#define iounmap __iounmap
+#include <asm-generic/ioremap-nopost.h>
/*
* Convert a physical pointer to a virtual kernel pointer for /dev/mem
--
2.10.0
^ permalink raw reply related [flat|nested] 171+ messages in thread
* [PATCH v3 24/32] sparc: include default ioremap_nopost() implementation
2017-04-11 12:28 ` Lorenzo Pieralisi
@ 2017-04-11 12:29 ` Lorenzo Pieralisi
-1 siblings, 0 replies; 171+ messages in thread
From: Lorenzo Pieralisi @ 2017-04-11 12:29 UTC (permalink / raw)
To: linux-pci
Cc: linux-arch, linux-kernel, linux-arm-kernel, Lorenzo Pieralisi,
Bjorn Helgaas, David S. Miller
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.
Include the asm-generic ioremap_nopost() implementation (currently
falling back to ioremap_nocache()) to provide a non-posted writes
ioremap interface to kernel subsystems.
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Cc: "David S. Miller" <davem@davemloft.net>
---
arch/sparc/include/asm/io.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/sparc/include/asm/io.h b/arch/sparc/include/asm/io.h
index f6902cf..09bb613 100644
--- a/arch/sparc/include/asm/io.h
+++ b/arch/sparc/include/asm/io.h
@@ -5,6 +5,7 @@
#else
#include <asm/io_32.h>
#endif
+#include <asm-generic/ioremap-nopost.h>
/*
* Defines used for both SPARC32 and SPARC64
--
2.10.0
^ permalink raw reply related [flat|nested] 171+ messages in thread
* [PATCH v3 24/32] sparc: include default ioremap_nopost() implementation
@ 2017-04-11 12:29 ` Lorenzo Pieralisi
0 siblings, 0 replies; 171+ messages in thread
From: Lorenzo Pieralisi @ 2017-04-11 12:29 UTC (permalink / raw)
To: linux-arm-kernel
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.
Include the asm-generic ioremap_nopost() implementation (currently
falling back to ioremap_nocache()) to provide a non-posted writes
ioremap interface to kernel subsystems.
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Cc: "David S. Miller" <davem@davemloft.net>
---
arch/sparc/include/asm/io.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/sparc/include/asm/io.h b/arch/sparc/include/asm/io.h
index f6902cf..09bb613 100644
--- a/arch/sparc/include/asm/io.h
+++ b/arch/sparc/include/asm/io.h
@@ -5,6 +5,7 @@
#else
#include <asm/io_32.h>
#endif
+#include <asm-generic/ioremap-nopost.h>
/*
* Defines used for both SPARC32 and SPARC64
--
2.10.0
^ permalink raw reply related [flat|nested] 171+ messages in thread
* [PATCH v3 25/32] tile: include default ioremap_nopost() implementation
2017-04-11 12:28 ` Lorenzo Pieralisi
@ 2017-04-11 12:29 ` Lorenzo Pieralisi
-1 siblings, 0 replies; 171+ messages in thread
From: Lorenzo Pieralisi @ 2017-04-11 12:29 UTC (permalink / raw)
To: linux-pci
Cc: linux-arch, linux-kernel, linux-arm-kernel, Lorenzo Pieralisi,
Bjorn Helgaas, Chris Metcalf
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.
Include the asm-generic ioremap_nopost() implementation (currently
falling back to ioremap_nocache()) to provide a non-posted writes
ioremap interface to kernel subsystems.
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Cc: Chris Metcalf <cmetcalf@mellanox.com>
---
arch/tile/include/asm/io.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/tile/include/asm/io.h b/arch/tile/include/asm/io.h
index 30f4a21..d3f2b77 100644
--- a/arch/tile/include/asm/io.h
+++ b/arch/tile/include/asm/io.h
@@ -57,6 +57,7 @@ extern void iounmap(volatile void __iomem *addr);
#define ioremap_wt(physaddr, size) ioremap(physaddr, size)
#define ioremap_uc(physaddr, size) ioremap(physaddr, size)
#define ioremap_fullcache(physaddr, size) ioremap(physaddr, size)
+#include <asm-generic/ioremap-nopost.h>
#define mmiowb()
--
2.10.0
^ permalink raw reply related [flat|nested] 171+ messages in thread
* [PATCH v3 25/32] tile: include default ioremap_nopost() implementation
@ 2017-04-11 12:29 ` Lorenzo Pieralisi
0 siblings, 0 replies; 171+ messages in thread
From: Lorenzo Pieralisi @ 2017-04-11 12:29 UTC (permalink / raw)
To: linux-arm-kernel
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.
Include the asm-generic ioremap_nopost() implementation (currently
falling back to ioremap_nocache()) to provide a non-posted writes
ioremap interface to kernel subsystems.
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Cc: Chris Metcalf <cmetcalf@mellanox.com>
---
arch/tile/include/asm/io.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/tile/include/asm/io.h b/arch/tile/include/asm/io.h
index 30f4a21..d3f2b77 100644
--- a/arch/tile/include/asm/io.h
+++ b/arch/tile/include/asm/io.h
@@ -57,6 +57,7 @@ extern void iounmap(volatile void __iomem *addr);
#define ioremap_wt(physaddr, size) ioremap(physaddr, size)
#define ioremap_uc(physaddr, size) ioremap(physaddr, size)
#define ioremap_fullcache(physaddr, size) ioremap(physaddr, size)
+#include <asm-generic/ioremap-nopost.h>
#define mmiowb()
--
2.10.0
^ permalink raw reply related [flat|nested] 171+ messages in thread
* [PATCH v3 26/32] unicore32: include default ioremap_nopost() implementation
2017-04-11 12:28 ` Lorenzo Pieralisi
@ 2017-04-11 12:29 ` Lorenzo Pieralisi
-1 siblings, 0 replies; 171+ messages in thread
From: Lorenzo Pieralisi @ 2017-04-11 12:29 UTC (permalink / raw)
To: linux-pci
Cc: linux-arch, linux-kernel, linux-arm-kernel, Lorenzo Pieralisi,
Bjorn Helgaas, Guan Xuetao
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.
Include the asm-generic ioremap_nopost() implementation (currently
falling back to ioremap_nocache()) to provide a non-posted writes
ioremap interface to kernel subsystems.
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Cc: Guan Xuetao <gxt@mprc.pku.edu.cn>
---
arch/unicore32/include/asm/io.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/unicore32/include/asm/io.h b/arch/unicore32/include/asm/io.h
index cb1d8fd..71fdfa2 100644
--- a/arch/unicore32/include/asm/io.h
+++ b/arch/unicore32/include/asm/io.h
@@ -38,6 +38,7 @@ extern void __uc32_iounmap(volatile void __iomem *addr);
#define ioremap_cached(cookie, size) __uc32_ioremap_cached(cookie, size)
#define ioremap_nocache(cookie, size) __uc32_ioremap(cookie, size)
#define iounmap(cookie) __uc32_iounmap(cookie)
+#include <asm-generic/ioremap-nopost.h>
#define readb_relaxed readb
#define readw_relaxed readw
--
2.10.0
^ permalink raw reply related [flat|nested] 171+ messages in thread
* [PATCH v3 26/32] unicore32: include default ioremap_nopost() implementation
@ 2017-04-11 12:29 ` Lorenzo Pieralisi
0 siblings, 0 replies; 171+ messages in thread
From: Lorenzo Pieralisi @ 2017-04-11 12:29 UTC (permalink / raw)
To: linux-arm-kernel
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.
Include the asm-generic ioremap_nopost() implementation (currently
falling back to ioremap_nocache()) to provide a non-posted writes
ioremap interface to kernel subsystems.
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Cc: Guan Xuetao <gxt@mprc.pku.edu.cn>
---
arch/unicore32/include/asm/io.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/unicore32/include/asm/io.h b/arch/unicore32/include/asm/io.h
index cb1d8fd..71fdfa2 100644
--- a/arch/unicore32/include/asm/io.h
+++ b/arch/unicore32/include/asm/io.h
@@ -38,6 +38,7 @@ extern void __uc32_iounmap(volatile void __iomem *addr);
#define ioremap_cached(cookie, size) __uc32_ioremap_cached(cookie, size)
#define ioremap_nocache(cookie, size) __uc32_ioremap(cookie, size)
#define iounmap(cookie) __uc32_iounmap(cookie)
+#include <asm-generic/ioremap-nopost.h>
#define readb_relaxed readb
#define readw_relaxed readw
--
2.10.0
^ permalink raw reply related [flat|nested] 171+ messages in thread
* [PATCH v3 27/32] x86: include default ioremap_nopost() implementation
2017-04-11 12:28 ` Lorenzo Pieralisi
@ 2017-04-11 12:29 ` Lorenzo Pieralisi
-1 siblings, 0 replies; 171+ messages in thread
From: Lorenzo Pieralisi @ 2017-04-11 12:29 UTC (permalink / raw)
To: linux-pci
Cc: linux-arch, linux-kernel, linux-arm-kernel, Lorenzo Pieralisi,
Thomas Gleixner, Bjorn Helgaas, Ingo Molnar
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.
Include the asm-generic ioremap_nopost() implementation (currently
falling back to ioremap_nocache()) to provide a non-posted writes
ioremap interface to kernel subsystems.
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Cc: Ingo Molnar <mingo@redhat.com>
---
arch/x86/include/asm/io.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/x86/include/asm/io.h b/arch/x86/include/asm/io.h
index 7afb0e2..9d431ef 100644
--- a/arch/x86/include/asm/io.h
+++ b/arch/x86/include/asm/io.h
@@ -201,6 +201,7 @@ extern void set_iounmap_nonlazy(void);
#ifdef __KERNEL__
#include <asm-generic/iomap.h>
+#include <asm-generic/ioremap-nopost.h>
/*
* Convert a virtual cached pointer to an uncached pointer
--
2.10.0
^ permalink raw reply related [flat|nested] 171+ messages in thread
* [PATCH v3 27/32] x86: include default ioremap_nopost() implementation
@ 2017-04-11 12:29 ` Lorenzo Pieralisi
0 siblings, 0 replies; 171+ messages in thread
From: Lorenzo Pieralisi @ 2017-04-11 12:29 UTC (permalink / raw)
To: linux-arm-kernel
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.
Include the asm-generic ioremap_nopost() implementation (currently
falling back to ioremap_nocache()) to provide a non-posted writes
ioremap interface to kernel subsystems.
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Cc: Ingo Molnar <mingo@redhat.com>
---
arch/x86/include/asm/io.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/x86/include/asm/io.h b/arch/x86/include/asm/io.h
index 7afb0e2..9d431ef 100644
--- a/arch/x86/include/asm/io.h
+++ b/arch/x86/include/asm/io.h
@@ -201,6 +201,7 @@ extern void set_iounmap_nonlazy(void);
#ifdef __KERNEL__
#include <asm-generic/iomap.h>
+#include <asm-generic/ioremap-nopost.h>
/*
* Convert a virtual cached pointer to an uncached pointer
--
2.10.0
^ permalink raw reply related [flat|nested] 171+ messages in thread
* [PATCH v3 28/32] xtensa: include default ioremap_nopost() implementation
2017-04-11 12:28 ` Lorenzo Pieralisi
@ 2017-04-11 12:29 ` Lorenzo Pieralisi
-1 siblings, 0 replies; 171+ messages in thread
From: Lorenzo Pieralisi @ 2017-04-11 12:29 UTC (permalink / raw)
To: linux-pci
Cc: linux-arch, linux-kernel, linux-arm-kernel, Lorenzo Pieralisi,
Max Filippov, Bjorn Helgaas, Chris Zankel
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.
Include the asm-generic ioremap_nopost() implementation (currently
falling back to ioremap_nocache()) to provide a non-posted writes
ioremap interface to kernel subsystems.
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Cc: Max Filippov <jcmvbkbc@gmail.com>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Cc: Chris Zankel <chris@zankel.net>
---
arch/xtensa/include/asm/io.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/xtensa/include/asm/io.h b/arch/xtensa/include/asm/io.h
index c38e5a7..a469bef 100644
--- a/arch/xtensa/include/asm/io.h
+++ b/arch/xtensa/include/asm/io.h
@@ -55,6 +55,7 @@ static inline void __iomem *ioremap_cache(unsigned long offset,
#define ioremap_wc ioremap_nocache
#define ioremap_wt ioremap_nocache
+#include <asm-generic/ioremap-nopost.h>
static inline void __iomem *ioremap(unsigned long offset, unsigned long size)
{
--
2.10.0
^ permalink raw reply related [flat|nested] 171+ messages in thread* [PATCH v3 28/32] xtensa: include default ioremap_nopost() implementation
@ 2017-04-11 12:29 ` Lorenzo Pieralisi
0 siblings, 0 replies; 171+ messages in thread
From: Lorenzo Pieralisi @ 2017-04-11 12:29 UTC (permalink / raw)
To: linux-arm-kernel
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.
Include the asm-generic ioremap_nopost() implementation (currently
falling back to ioremap_nocache()) to provide a non-posted writes
ioremap interface to kernel subsystems.
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Cc: Max Filippov <jcmvbkbc@gmail.com>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Cc: Chris Zankel <chris@zankel.net>
---
arch/xtensa/include/asm/io.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/xtensa/include/asm/io.h b/arch/xtensa/include/asm/io.h
index c38e5a7..a469bef 100644
--- a/arch/xtensa/include/asm/io.h
+++ b/arch/xtensa/include/asm/io.h
@@ -55,6 +55,7 @@ static inline void __iomem *ioremap_cache(unsigned long offset,
#define ioremap_wc ioremap_nocache
#define ioremap_wt ioremap_nocache
+#include <asm-generic/ioremap-nopost.h>
static inline void __iomem *ioremap(unsigned long offset, unsigned long size)
{
--
2.10.0
^ permalink raw reply related [flat|nested] 171+ messages in thread
* [PATCH v3 29/32] arm64: implement ioremap_nopost() interface
2017-04-11 12:28 ` Lorenzo Pieralisi
(?)
(?)
@ 2017-04-11 12:29 ` Lorenzo Pieralisi
-1 siblings, 0 replies; 171+ messages in thread
From: Lorenzo Pieralisi @ 2017-04-11 12:29 UTC (permalink / raw)
To: linux-pci
Cc: linux-arch, linux-kernel, linux-arm-kernel, Lorenzo Pieralisi,
Will Deacon, Catalin Marinas
The PCI bus specifications (rev 3.0, 3.2.5 "Transaction Ordering
and Posting") defines rules for PCI configuration space transactions
ordering and posting, that state that configuration writes
are non-posted transactions.
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.
Current ioremap interface on ARM64 implements mapping functions
where the Early Write Acknowledgment hint is enabled, so they
cannot be used to map PCI configuration space in a PCI specs
compliant way.
Implement an ARM64 specific ioremap_nopost() interface
that allows to map PCI config region with nGnRnE attributes, providing
a remap function that complies with PCI specifications and the ARMv8
architecture reference manual recommendations.
Acked-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
---
arch/arm64/include/asm/io.h | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/arch/arm64/include/asm/io.h b/arch/arm64/include/asm/io.h
index 0c00c87..1a703e5 100644
--- a/arch/arm64/include/asm/io.h
+++ b/arch/arm64/include/asm/io.h
@@ -173,6 +173,18 @@ extern void __iomem *ioremap_cache(phys_addr_t phys_addr, size_t size);
#define iounmap __iounmap
/*
+ * ioremap implementation providing non-posted writes (ie v8 no Early
+ * Write Acknowledgment) semantics.
+ *
+ * PCI specifications disallows posted write configuration transactions.
+ * Add an arch specific ioremap_post definition that is implemented
+ * through nGnRnE device memory attribute as recommended by the ARM v8
+ * Architecture reference manual Issue A.k B2.8.2 "Device memory" so
+ * that it can be used to map PCI config space memory areas.
+ */
+#define ioremap_nopost(addr, size) __ioremap((addr), (size), __pgprot(PROT_DEVICE_nGnRnE))
+
+/*
* io{read,write}{16,32,64}be() macros
*/
#define ioread16be(p) ({ __u16 __v = be16_to_cpu((__force __be16)__raw_readw(p)); __iormb(); __v; })
--
2.10.0
^ permalink raw reply related [flat|nested] 171+ messages in thread* [PATCH v3 29/32] arm64: implement ioremap_nopost() interface
@ 2017-04-11 12:29 ` Lorenzo Pieralisi
0 siblings, 0 replies; 171+ messages in thread
From: Lorenzo Pieralisi @ 2017-04-11 12:29 UTC (permalink / raw)
To: linux-arm-kernel
The PCI bus specifications (rev 3.0, 3.2.5 "Transaction Ordering
and Posting") defines rules for PCI configuration space transactions
ordering and posting, that state that configuration writes
are non-posted transactions.
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.
Current ioremap interface on ARM64 implements mapping functions
where the Early Write Acknowledgment hint is enabled, so they
cannot be used to map PCI configuration space in a PCI specs
compliant way.
Implement an ARM64 specific ioremap_nopost() interface
that allows to map PCI config region with nGnRnE attributes, providing
a remap function that complies with PCI specifications and the ARMv8
architecture reference manual recommendations.
Acked-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
---
arch/arm64/include/asm/io.h | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/arch/arm64/include/asm/io.h b/arch/arm64/include/asm/io.h
index 0c00c87..1a703e5 100644
--- a/arch/arm64/include/asm/io.h
+++ b/arch/arm64/include/asm/io.h
@@ -173,6 +173,18 @@ extern void __iomem *ioremap_cache(phys_addr_t phys_addr, size_t size);
#define iounmap __iounmap
/*
+ * ioremap implementation providing non-posted writes (ie v8 no Early
+ * Write Acknowledgment) semantics.
+ *
+ * PCI specifications disallows posted write configuration transactions.
+ * Add an arch specific ioremap_post definition that is implemented
+ * through nGnRnE device memory attribute as recommended by the ARM v8
+ * Architecture reference manual Issue A.k B2.8.2 "Device memory" so
+ * that it can be used to map PCI config space memory areas.
+ */
+#define ioremap_nopost(addr, size) __ioremap((addr), (size), __pgprot(PROT_DEVICE_nGnRnE))
+
+/*
* io{read,write}{16,32,64}be() macros
*/
#define ioread16be(p) ({ __u16 __v = be16_to_cpu((__force __be16)__raw_readw(p)); __iormb(); __v; })
--
2.10.0
^ permalink raw reply related [flat|nested] 171+ messages in thread* [PATCH v3 29/32] arm64: implement ioremap_nopost() interface
@ 2017-04-11 12:29 ` Lorenzo Pieralisi
0 siblings, 0 replies; 171+ messages in thread
From: Lorenzo Pieralisi @ 2017-04-11 12:29 UTC (permalink / raw)
To: linux-pci
Cc: linux-arch, Lorenzo Pieralisi, Catalin Marinas, Will Deacon,
linux-kernel, linux-arm-kernel
The PCI bus specifications (rev 3.0, 3.2.5 "Transaction Ordering
and Posting") defines rules for PCI configuration space transactions
ordering and posting, that state that configuration writes
are non-posted transactions.
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.
Current ioremap interface on ARM64 implements mapping functions
where the Early Write Acknowledgment hint is enabled, so they
cannot be used to map PCI configuration space in a PCI specs
compliant way.
Implement an ARM64 specific ioremap_nopost() interface
that allows to map PCI config region with nGnRnE attributes, providing
a remap function that complies with PCI specifications and the ARMv8
architecture reference manual recommendations.
Acked-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
---
arch/arm64/include/asm/io.h | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/arch/arm64/include/asm/io.h b/arch/arm64/include/asm/io.h
index 0c00c87..1a703e5 100644
--- a/arch/arm64/include/asm/io.h
+++ b/arch/arm64/include/asm/io.h
@@ -173,6 +173,18 @@ extern void __iomem *ioremap_cache(phys_addr_t phys_addr, size_t size);
#define iounmap __iounmap
/*
+ * ioremap implementation providing non-posted writes (ie v8 no Early
+ * Write Acknowledgment) semantics.
+ *
+ * PCI specifications disallows posted write configuration transactions.
+ * Add an arch specific ioremap_post definition that is implemented
+ * through nGnRnE device memory attribute as recommended by the ARM v8
+ * Architecture reference manual Issue A.k B2.8.2 "Device memory" so
+ * that it can be used to map PCI config space memory areas.
+ */
+#define ioremap_nopost(addr, size) __ioremap((addr), (size), __pgprot(PROT_DEVICE_nGnRnE))
+
+/*
* io{read,write}{16,32,64}be() macros
*/
#define ioread16be(p) ({ __u16 __v = be16_to_cpu((__force __be16)__raw_readw(p)); __iormb(); __v; })
--
2.10.0
^ permalink raw reply related [flat|nested] 171+ messages in thread* [PATCH v3 29/32] arm64: implement ioremap_nopost() interface
@ 2017-04-11 12:29 ` Lorenzo Pieralisi
0 siblings, 0 replies; 171+ messages in thread
From: Lorenzo Pieralisi @ 2017-04-11 12:29 UTC (permalink / raw)
To: linux-pci
Cc: linux-arch, Lorenzo Pieralisi, Catalin Marinas, Will Deacon,
linux-kernel, linux-arm-kernel
The PCI bus specifications (rev 3.0, 3.2.5 "Transaction Ordering
and Posting") defines rules for PCI configuration space transactions
ordering and posting, that state that configuration writes
are non-posted transactions.
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.
Current ioremap interface on ARM64 implements mapping functions
where the Early Write Acknowledgment hint is enabled, so they
cannot be used to map PCI configuration space in a PCI specs
compliant way.
Implement an ARM64 specific ioremap_nopost() interface
that allows to map PCI config region with nGnRnE attributes, providing
a remap function that complies with PCI specifications and the ARMv8
architecture reference manual recommendations.
Acked-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
---
arch/arm64/include/asm/io.h | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/arch/arm64/include/asm/io.h b/arch/arm64/include/asm/io.h
index 0c00c87..1a703e5 100644
--- a/arch/arm64/include/asm/io.h
+++ b/arch/arm64/include/asm/io.h
@@ -173,6 +173,18 @@ extern void __iomem *ioremap_cache(phys_addr_t phys_addr, size_t size);
#define iounmap __iounmap
/*
+ * ioremap implementation providing non-posted writes (ie v8 no Early
+ * Write Acknowledgment) semantics.
+ *
+ * PCI specifications disallows posted write configuration transactions.
+ * Add an arch specific ioremap_post definition that is implemented
+ * through nGnRnE device memory attribute as recommended by the ARM v8
+ * Architecture reference manual Issue A.k B2.8.2 "Device memory" so
+ * that it can be used to map PCI config space memory areas.
+ */
+#define ioremap_nopost(addr, size) __ioremap((addr), (size), __pgprot(PROT_DEVICE_nGnRnE))
+
+/*
* io{read,write}{16,32,64}be() macros
*/
#define ioread16be(p) ({ __u16 __v = be16_to_cpu((__force __be16)__raw_readw(p)); __iormb(); __v; })
--
2.10.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 171+ messages in thread
* [PATCH v3 30/32] arm: implement ioremap_nopost() interface
2017-04-11 12:28 ` Lorenzo Pieralisi
@ 2017-04-11 12:29 ` Lorenzo Pieralisi
-1 siblings, 0 replies; 171+ messages in thread
From: Lorenzo Pieralisi @ 2017-04-11 12:29 UTC (permalink / raw)
To: linux-pci
Cc: linux-arch, linux-kernel, linux-arm-kernel, Lorenzo Pieralisi,
Arnd Bergmann, Russell King
The PCI bus specifications (rev 3.0, 3.2.5 "Transaction Ordering
and Posting") define rules for PCI configuration space transactions
ordering and posting, that state that configuration writes have to
be non-posted transactions.
Current ioremap interface on ARM provides mapping functions that
provide "bufferable" writes transactions (ie ioremap uses MT_DEVICE
memory type) aka posted writes, so PCI host controller drivers have
no arch interface to remap PCI configuration space with memory
attributes that comply with the PCI specifications for configuration
space.
Implement an ARM specific ioremap_nopost() interface that allows to
map PCI config memory regions with MT_UNCACHED memory type (ie strongly
ordered - non-posted writes), providing a remap function that complies
with PCI specifications for config space transactions.
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Russell King <linux@armlinux.org.uk>
---
arch/arm/include/asm/io.h | 9 +++++++++
arch/arm/mm/ioremap.c | 7 +++++++
arch/arm/mm/nommu.c | 9 +++++++++
3 files changed, 25 insertions(+)
diff --git a/arch/arm/include/asm/io.h b/arch/arm/include/asm/io.h
index 42871fb..28b15be 100644
--- a/arch/arm/include/asm/io.h
+++ b/arch/arm/include/asm/io.h
@@ -352,6 +352,7 @@ static inline void memcpy_toio(volatile void __iomem *to, const void *from,
* mapping has specific properties.
*
* Function Memory type Cacheability Cache hint
+ * ioremap_nopost() SO n/a n/a
* ioremap() Device n/a n/a
* ioremap_nocache() Device n/a n/a
* ioremap_cache() Normal Writeback Read allocate
@@ -372,6 +373,12 @@ static inline void memcpy_toio(volatile void __iomem *to, const void *from,
* compiler may generate unaligned accesses - eg, via inlining its own
* memcpy.
*
+ * ioremap_nopost() maps memory as strongly ordered, to be used for
+ * specific mappings (eg PCI config space) that require non-posted
+ * write transactions. Strongly ordered transactions are ordered wrt
+ * device mappings, which means that ioremap_nopost() is the same
+ * as ioremap() except for non-posted writes behaviour.
+ *
* All normal memory mappings have the following properties:
* - reads can be repeated with no side effects
* - repeated reads return the last value written
@@ -407,6 +414,8 @@ void __iomem *ioremap_wc(resource_size_t res_cookie, size_t size);
#define ioremap_wc ioremap_wc
#define ioremap_wt ioremap_wc
+void __iomem *ioremap_nopost(resource_size_t res_cookie, size_t size);
+
void iounmap(volatile void __iomem *iomem_cookie);
#define iounmap iounmap
diff --git a/arch/arm/mm/ioremap.c b/arch/arm/mm/ioremap.c
index ff0eed2..4ffaf16 100644
--- a/arch/arm/mm/ioremap.c
+++ b/arch/arm/mm/ioremap.c
@@ -463,6 +463,13 @@ void iounmap(volatile void __iomem *cookie)
}
EXPORT_SYMBOL(iounmap);
+void __iomem *ioremap_nopost(resource_size_t res_cookie, size_t size)
+{
+ return arch_ioremap_caller(res_cookie, size, MT_UNCACHED,
+ __builtin_return_address(0));
+}
+EXPORT_SYMBOL_GPL(ioremap_nopost);
+
#ifdef CONFIG_PCI
static int pci_ioremap_mem_type = MT_DEVICE;
diff --git a/arch/arm/mm/nommu.c b/arch/arm/mm/nommu.c
index 3b5c7aa..dfd736a 100644
--- a/arch/arm/mm/nommu.c
+++ b/arch/arm/mm/nommu.c
@@ -21,6 +21,8 @@
#include <asm/mpu.h>
#include <asm/procinfo.h>
+#include <asm/mach/map.h>
+
#include "mm.h"
unsigned long vectors_base;
@@ -433,6 +435,13 @@ void __iomem *ioremap_wc(resource_size_t res_cookie, size_t size)
}
EXPORT_SYMBOL(ioremap_wc);
+void __iomem *ioremap_nopost(resource_size_t res_cookie, size_t size)
+{
+ return __arm_ioremap_caller(res_cookie, size, MT_UNCACHED,
+ __builtin_return_address(0));
+}
+EXPORT_SYMBOL(ioremap_nopost);
+
void *arch_memremap_wb(phys_addr_t phys_addr, size_t size)
{
return (void *)phys_addr;
--
2.10.0
^ permalink raw reply related [flat|nested] 171+ messages in thread* [PATCH v3 30/32] arm: implement ioremap_nopost() interface
@ 2017-04-11 12:29 ` Lorenzo Pieralisi
0 siblings, 0 replies; 171+ messages in thread
From: Lorenzo Pieralisi @ 2017-04-11 12:29 UTC (permalink / raw)
To: linux-arm-kernel
The PCI bus specifications (rev 3.0, 3.2.5 "Transaction Ordering
and Posting") define rules for PCI configuration space transactions
ordering and posting, that state that configuration writes have to
be non-posted transactions.
Current ioremap interface on ARM provides mapping functions that
provide "bufferable" writes transactions (ie ioremap uses MT_DEVICE
memory type) aka posted writes, so PCI host controller drivers have
no arch interface to remap PCI configuration space with memory
attributes that comply with the PCI specifications for configuration
space.
Implement an ARM specific ioremap_nopost() interface that allows to
map PCI config memory regions with MT_UNCACHED memory type (ie strongly
ordered - non-posted writes), providing a remap function that complies
with PCI specifications for config space transactions.
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Russell King <linux@armlinux.org.uk>
---
arch/arm/include/asm/io.h | 9 +++++++++
arch/arm/mm/ioremap.c | 7 +++++++
arch/arm/mm/nommu.c | 9 +++++++++
3 files changed, 25 insertions(+)
diff --git a/arch/arm/include/asm/io.h b/arch/arm/include/asm/io.h
index 42871fb..28b15be 100644
--- a/arch/arm/include/asm/io.h
+++ b/arch/arm/include/asm/io.h
@@ -352,6 +352,7 @@ static inline void memcpy_toio(volatile void __iomem *to, const void *from,
* mapping has specific properties.
*
* Function Memory type Cacheability Cache hint
+ * ioremap_nopost() SO n/a n/a
* ioremap() Device n/a n/a
* ioremap_nocache() Device n/a n/a
* ioremap_cache() Normal Writeback Read allocate
@@ -372,6 +373,12 @@ static inline void memcpy_toio(volatile void __iomem *to, const void *from,
* compiler may generate unaligned accesses - eg, via inlining its own
* memcpy.
*
+ * ioremap_nopost() maps memory as strongly ordered, to be used for
+ * specific mappings (eg PCI config space) that require non-posted
+ * write transactions. Strongly ordered transactions are ordered wrt
+ * device mappings, which means that ioremap_nopost() is the same
+ * as ioremap() except for non-posted writes behaviour.
+ *
* All normal memory mappings have the following properties:
* - reads can be repeated with no side effects
* - repeated reads return the last value written
@@ -407,6 +414,8 @@ void __iomem *ioremap_wc(resource_size_t res_cookie, size_t size);
#define ioremap_wc ioremap_wc
#define ioremap_wt ioremap_wc
+void __iomem *ioremap_nopost(resource_size_t res_cookie, size_t size);
+
void iounmap(volatile void __iomem *iomem_cookie);
#define iounmap iounmap
diff --git a/arch/arm/mm/ioremap.c b/arch/arm/mm/ioremap.c
index ff0eed2..4ffaf16 100644
--- a/arch/arm/mm/ioremap.c
+++ b/arch/arm/mm/ioremap.c
@@ -463,6 +463,13 @@ void iounmap(volatile void __iomem *cookie)
}
EXPORT_SYMBOL(iounmap);
+void __iomem *ioremap_nopost(resource_size_t res_cookie, size_t size)
+{
+ return arch_ioremap_caller(res_cookie, size, MT_UNCACHED,
+ __builtin_return_address(0));
+}
+EXPORT_SYMBOL_GPL(ioremap_nopost);
+
#ifdef CONFIG_PCI
static int pci_ioremap_mem_type = MT_DEVICE;
diff --git a/arch/arm/mm/nommu.c b/arch/arm/mm/nommu.c
index 3b5c7aa..dfd736a 100644
--- a/arch/arm/mm/nommu.c
+++ b/arch/arm/mm/nommu.c
@@ -21,6 +21,8 @@
#include <asm/mpu.h>
#include <asm/procinfo.h>
+#include <asm/mach/map.h>
+
#include "mm.h"
unsigned long vectors_base;
@@ -433,6 +435,13 @@ void __iomem *ioremap_wc(resource_size_t res_cookie, size_t size)
}
EXPORT_SYMBOL(ioremap_wc);
+void __iomem *ioremap_nopost(resource_size_t res_cookie, size_t size)
+{
+ return __arm_ioremap_caller(res_cookie, size, MT_UNCACHED,
+ __builtin_return_address(0));
+}
+EXPORT_SYMBOL(ioremap_nopost);
+
void *arch_memremap_wb(phys_addr_t phys_addr, size_t size)
{
return (void *)phys_addr;
--
2.10.0
^ permalink raw reply related [flat|nested] 171+ messages in thread
* [PATCH v3 31/32] lib: fix Devres devm_ioremap_* offset parameter kerneldoc description
2017-04-11 12:28 ` Lorenzo Pieralisi
(?)
@ 2017-04-11 12:29 ` Lorenzo Pieralisi
-1 siblings, 0 replies; 171+ messages in thread
From: Lorenzo Pieralisi @ 2017-04-11 12:29 UTC (permalink / raw)
To: linux-pci
Cc: linux-arch, linux-kernel, linux-arm-kernel, Lorenzo Pieralisi,
Bjorn Helgaas, Tejun Heo
The offset parameter in Devres devm_ioremap_* functions kerneldoc
entries is erroneously defined as BUS offset whereas it is actually
a resource address.
Since it is actually misleading, fix the Devres devm_ioremap_* offset
parameter kerneldoc entry by replacing BUS offset with a more
suitable description (ie Resource address).
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Cc: Tejun Heo <tj@kernel.org>
---
lib/devres.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/lib/devres.c b/lib/devres.c
index cb1464c..78eca71 100644
--- a/lib/devres.c
+++ b/lib/devres.c
@@ -17,7 +17,7 @@ static int devm_ioremap_match(struct device *dev, void *res, void *match_data)
/**
* devm_ioremap - Managed ioremap()
* @dev: Generic device to remap IO address for
- * @offset: BUS offset to map
+ * @offset: Resource address to map
* @size: Size of map
*
* Managed ioremap(). Map is automatically unmapped on driver detach.
@@ -45,7 +45,7 @@ EXPORT_SYMBOL(devm_ioremap);
/**
* devm_ioremap_nocache - Managed ioremap_nocache()
* @dev: Generic device to remap IO address for
- * @offset: BUS offset to map
+ * @offset: Resource address to map
* @size: Size of map
*
* Managed ioremap_nocache(). Map is automatically unmapped on driver
@@ -74,7 +74,7 @@ EXPORT_SYMBOL(devm_ioremap_nocache);
/**
* devm_ioremap_wc - Managed ioremap_wc()
* @dev: Generic device to remap IO address for
- * @offset: BUS offset to map
+ * @offset: Resource address to map
* @size: Size of map
*
* Managed ioremap_wc(). Map is automatically unmapped on driver detach.
--
2.10.0
^ permalink raw reply related [flat|nested] 171+ messages in thread
* [PATCH v3 31/32] lib: fix Devres devm_ioremap_* offset parameter kerneldoc description
@ 2017-04-11 12:29 ` Lorenzo Pieralisi
0 siblings, 0 replies; 171+ messages in thread
From: Lorenzo Pieralisi @ 2017-04-11 12:29 UTC (permalink / raw)
To: linux-arm-kernel
The offset parameter in Devres devm_ioremap_* functions kerneldoc
entries is erroneously defined as BUS offset whereas it is actually
a resource address.
Since it is actually misleading, fix the Devres devm_ioremap_* offset
parameter kerneldoc entry by replacing BUS offset with a more
suitable description (ie Resource address).
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Cc: Tejun Heo <tj@kernel.org>
---
lib/devres.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/lib/devres.c b/lib/devres.c
index cb1464c..78eca71 100644
--- a/lib/devres.c
+++ b/lib/devres.c
@@ -17,7 +17,7 @@ static int devm_ioremap_match(struct device *dev, void *res, void *match_data)
/**
* devm_ioremap - Managed ioremap()
* @dev: Generic device to remap IO address for
- * @offset: BUS offset to map
+ * @offset: Resource address to map
* @size: Size of map
*
* Managed ioremap(). Map is automatically unmapped on driver detach.
@@ -45,7 +45,7 @@ EXPORT_SYMBOL(devm_ioremap);
/**
* devm_ioremap_nocache - Managed ioremap_nocache()
* @dev: Generic device to remap IO address for
- * @offset: BUS offset to map
+ * @offset: Resource address to map
* @size: Size of map
*
* Managed ioremap_nocache(). Map is automatically unmapped on driver
@@ -74,7 +74,7 @@ EXPORT_SYMBOL(devm_ioremap_nocache);
/**
* devm_ioremap_wc - Managed ioremap_wc()
* @dev: Generic device to remap IO address for
- * @offset: BUS offset to map
+ * @offset: Resource address to map
* @size: Size of map
*
* Managed ioremap_wc(). Map is automatically unmapped on driver detach.
--
2.10.0
^ permalink raw reply related [flat|nested] 171+ messages in thread
* [PATCH v3 31/32] lib: fix Devres devm_ioremap_* offset parameter kerneldoc description
@ 2017-04-11 12:29 ` Lorenzo Pieralisi
0 siblings, 0 replies; 171+ messages in thread
From: Lorenzo Pieralisi @ 2017-04-11 12:29 UTC (permalink / raw)
To: linux-pci
Cc: linux-arch, Lorenzo Pieralisi, linux-kernel, Tejun Heo,
Bjorn Helgaas, linux-arm-kernel
The offset parameter in Devres devm_ioremap_* functions kerneldoc
entries is erroneously defined as BUS offset whereas it is actually
a resource address.
Since it is actually misleading, fix the Devres devm_ioremap_* offset
parameter kerneldoc entry by replacing BUS offset with a more
suitable description (ie Resource address).
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Cc: Tejun Heo <tj@kernel.org>
---
lib/devres.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/lib/devres.c b/lib/devres.c
index cb1464c..78eca71 100644
--- a/lib/devres.c
+++ b/lib/devres.c
@@ -17,7 +17,7 @@ static int devm_ioremap_match(struct device *dev, void *res, void *match_data)
/**
* devm_ioremap - Managed ioremap()
* @dev: Generic device to remap IO address for
- * @offset: BUS offset to map
+ * @offset: Resource address to map
* @size: Size of map
*
* Managed ioremap(). Map is automatically unmapped on driver detach.
@@ -45,7 +45,7 @@ EXPORT_SYMBOL(devm_ioremap);
/**
* devm_ioremap_nocache - Managed ioremap_nocache()
* @dev: Generic device to remap IO address for
- * @offset: BUS offset to map
+ * @offset: Resource address to map
* @size: Size of map
*
* Managed ioremap_nocache(). Map is automatically unmapped on driver
@@ -74,7 +74,7 @@ EXPORT_SYMBOL(devm_ioremap_nocache);
/**
* devm_ioremap_wc - Managed ioremap_wc()
* @dev: Generic device to remap IO address for
- * @offset: BUS offset to map
+ * @offset: Resource address to map
* @size: Size of map
*
* Managed ioremap_wc(). Map is automatically unmapped on driver detach.
--
2.10.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 171+ messages in thread
* [PATCH v3 32/32] lib: implement Devres ioremap_nopost() interface
2017-04-11 12:28 ` Lorenzo Pieralisi
(?)
@ 2017-04-11 12:29 ` Lorenzo Pieralisi
-1 siblings, 0 replies; 171+ messages in thread
From: Lorenzo Pieralisi @ 2017-04-11 12:29 UTC (permalink / raw)
To: linux-pci
Cc: linux-arch, linux-kernel, linux-arm-kernel, Lorenzo Pieralisi,
Jonathan Corbet, Bjorn Helgaas, Tejun Heo
The introduction of the ioremap_nopost() interface allows
kernel drivers to map memory through a dedicated kernel
interface providing non-posted writes semantics.
Introduce two new functions in the Devres kernel layer and Devres
documentation:
- devm_ioremap_nopost()
- devm_ioremap_nopost_resource()
so that drivers can make use of devm_* interface to map memory
regions requiring non-posted writes memory attributes.
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Cc: Tejun Heo <tj@kernel.org>
---
Documentation/driver-model/devres.txt | 3 ++
include/linux/device.h | 2 +
include/linux/io.h | 2 +
lib/devres.c | 78 +++++++++++++++++++++++++++++++++++
4 files changed, 85 insertions(+)
diff --git a/Documentation/driver-model/devres.txt b/Documentation/driver-model/devres.txt
index bf34d5b..9991a66 100644
--- a/Documentation/driver-model/devres.txt
+++ b/Documentation/driver-model/devres.txt
@@ -294,7 +294,10 @@ IOMAP
devm_ioremap()
devm_ioremap_nocache()
devm_ioremap_wc()
+ devm_ioremap_nopost()
devm_ioremap_resource() : checks resource, requests memory region, ioremaps
+ devm_ioremap_nopost_resource() : do devm_ioremap_resource() with nopost
+ memory attributes
devm_iounmap()
pcim_iomap()
pcim_iomap_regions() : do request_region() and iomap() on multiple BARs
diff --git a/include/linux/device.h b/include/linux/device.h
index 9ef518a..1dce865 100644
--- a/include/linux/device.h
+++ b/include/linux/device.h
@@ -689,6 +689,8 @@ extern unsigned long devm_get_free_pages(struct device *dev,
extern void devm_free_pages(struct device *dev, unsigned long addr);
void __iomem *devm_ioremap_resource(struct device *dev, struct resource *res);
+void __iomem *devm_ioremap_nopost_resource(struct device *dev,
+ struct resource *res);
/* allows to add/remove a custom action to devres stack */
int devm_add_action(struct device *dev, void (*action)(void *), void *data);
diff --git a/include/linux/io.h b/include/linux/io.h
index 82ef36e..e34d799 100644
--- a/include/linux/io.h
+++ b/include/linux/io.h
@@ -79,6 +79,8 @@ void __iomem *devm_ioremap_nocache(struct device *dev, resource_size_t offset,
resource_size_t size);
void __iomem *devm_ioremap_wc(struct device *dev, resource_size_t offset,
resource_size_t size);
+void __iomem *devm_ioremap_nopost(struct device *dev, resource_size_t offset,
+ resource_size_t size);
void devm_iounmap(struct device *dev, void __iomem *addr);
int check_signature(const volatile void __iomem *io_addr,
const unsigned char *signature, int length);
diff --git a/lib/devres.c b/lib/devres.c
index 78eca71..d16bd76 100644
--- a/lib/devres.c
+++ b/lib/devres.c
@@ -100,6 +100,34 @@ void __iomem *devm_ioremap_wc(struct device *dev, resource_size_t offset,
EXPORT_SYMBOL(devm_ioremap_wc);
/**
+ * devm_ioremap_nopost - Managed ioremap_nopost()
+ * @dev: Generic device to remap IO address for
+ * @offset: Resource address to map
+ * @size: Size of map
+ *
+ * Managed ioremap_nopost(). Map is automatically unmapped on driver detach.
+ */
+void __iomem *devm_ioremap_nopost(struct device *dev, resource_size_t offset,
+ resource_size_t size)
+{
+ void __iomem **ptr, *addr;
+
+ ptr = devres_alloc(devm_ioremap_release, sizeof(*ptr), GFP_KERNEL);
+ if (!ptr)
+ return NULL;
+
+ addr = ioremap_nopost(offset, size);
+ if (addr) {
+ *ptr = addr;
+ devres_add(dev, ptr);
+ } else
+ devres_free(ptr);
+
+ return addr;
+}
+EXPORT_SYMBOL(devm_ioremap_nopost);
+
+/**
* devm_iounmap - Managed iounmap()
* @dev: Generic device to unmap for
* @addr: Address to unmap
@@ -163,6 +191,56 @@ void __iomem *devm_ioremap_resource(struct device *dev, struct resource *res)
}
EXPORT_SYMBOL(devm_ioremap_resource);
+/**
+ * devm_ioremap_nopost_resource() - devm_ioremap_resource() nopost version
+ * @dev: generic device to handle the resource for
+ * @res: resource to be handled
+ *
+ * Checks that a resource is a valid memory region, requests the memory
+ * region and ioremaps it with ioremap_nopost() interface.
+ * All operations are managed and will be undone on driver detach.
+ *
+ * Returns a pointer to the remapped memory or an ERR_PTR() encoded error code
+ * on failure. Usage example:
+ *
+ * res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ * base = devm_ioremap_nopost_resource(&pdev->dev, res);
+ * if (IS_ERR(base))
+ * return PTR_ERR(base);
+ */
+void __iomem *devm_ioremap_nopost_resource(struct device *dev,
+ struct resource *res)
+{
+ resource_size_t size;
+ const char *name;
+ void __iomem *dest_ptr;
+
+ BUG_ON(!dev);
+
+ if (!res || resource_type(res) != IORESOURCE_MEM) {
+ dev_err(dev, "invalid resource\n");
+ return IOMEM_ERR_PTR(-EINVAL);
+ }
+
+ size = resource_size(res);
+ name = res->name ?: dev_name(dev);
+
+ if (!devm_request_mem_region(dev, res->start, size, name)) {
+ dev_err(dev, "can't request region for resource %pR\n", res);
+ return IOMEM_ERR_PTR(-EBUSY);
+ }
+
+ dest_ptr = devm_ioremap_nopost(dev, res->start, size);
+ if (!dest_ptr) {
+ dev_err(dev, "ioremap failed for resource %pR\n", res);
+ devm_release_mem_region(dev, res->start, size);
+ dest_ptr = IOMEM_ERR_PTR(-ENOMEM);
+ }
+
+ return dest_ptr;
+}
+EXPORT_SYMBOL(devm_ioremap_nopost_resource);
+
#ifdef CONFIG_HAS_IOPORT_MAP
/*
* Generic iomap devres
--
2.10.0
^ permalink raw reply related [flat|nested] 171+ messages in thread* [PATCH v3 32/32] lib: implement Devres ioremap_nopost() interface
@ 2017-04-11 12:29 ` Lorenzo Pieralisi
0 siblings, 0 replies; 171+ messages in thread
From: Lorenzo Pieralisi @ 2017-04-11 12:29 UTC (permalink / raw)
To: linux-arm-kernel
The introduction of the ioremap_nopost() interface allows
kernel drivers to map memory through a dedicated kernel
interface providing non-posted writes semantics.
Introduce two new functions in the Devres kernel layer and Devres
documentation:
- devm_ioremap_nopost()
- devm_ioremap_nopost_resource()
so that drivers can make use of devm_* interface to map memory
regions requiring non-posted writes memory attributes.
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Cc: Tejun Heo <tj@kernel.org>
---
Documentation/driver-model/devres.txt | 3 ++
include/linux/device.h | 2 +
include/linux/io.h | 2 +
lib/devres.c | 78 +++++++++++++++++++++++++++++++++++
4 files changed, 85 insertions(+)
diff --git a/Documentation/driver-model/devres.txt b/Documentation/driver-model/devres.txt
index bf34d5b..9991a66 100644
--- a/Documentation/driver-model/devres.txt
+++ b/Documentation/driver-model/devres.txt
@@ -294,7 +294,10 @@ IOMAP
devm_ioremap()
devm_ioremap_nocache()
devm_ioremap_wc()
+ devm_ioremap_nopost()
devm_ioremap_resource() : checks resource, requests memory region, ioremaps
+ devm_ioremap_nopost_resource() : do devm_ioremap_resource() with nopost
+ memory attributes
devm_iounmap()
pcim_iomap()
pcim_iomap_regions() : do request_region() and iomap() on multiple BARs
diff --git a/include/linux/device.h b/include/linux/device.h
index 9ef518a..1dce865 100644
--- a/include/linux/device.h
+++ b/include/linux/device.h
@@ -689,6 +689,8 @@ extern unsigned long devm_get_free_pages(struct device *dev,
extern void devm_free_pages(struct device *dev, unsigned long addr);
void __iomem *devm_ioremap_resource(struct device *dev, struct resource *res);
+void __iomem *devm_ioremap_nopost_resource(struct device *dev,
+ struct resource *res);
/* allows to add/remove a custom action to devres stack */
int devm_add_action(struct device *dev, void (*action)(void *), void *data);
diff --git a/include/linux/io.h b/include/linux/io.h
index 82ef36e..e34d799 100644
--- a/include/linux/io.h
+++ b/include/linux/io.h
@@ -79,6 +79,8 @@ void __iomem *devm_ioremap_nocache(struct device *dev, resource_size_t offset,
resource_size_t size);
void __iomem *devm_ioremap_wc(struct device *dev, resource_size_t offset,
resource_size_t size);
+void __iomem *devm_ioremap_nopost(struct device *dev, resource_size_t offset,
+ resource_size_t size);
void devm_iounmap(struct device *dev, void __iomem *addr);
int check_signature(const volatile void __iomem *io_addr,
const unsigned char *signature, int length);
diff --git a/lib/devres.c b/lib/devres.c
index 78eca71..d16bd76 100644
--- a/lib/devres.c
+++ b/lib/devres.c
@@ -100,6 +100,34 @@ void __iomem *devm_ioremap_wc(struct device *dev, resource_size_t offset,
EXPORT_SYMBOL(devm_ioremap_wc);
/**
+ * devm_ioremap_nopost - Managed ioremap_nopost()
+ * @dev: Generic device to remap IO address for
+ * @offset: Resource address to map
+ * @size: Size of map
+ *
+ * Managed ioremap_nopost(). Map is automatically unmapped on driver detach.
+ */
+void __iomem *devm_ioremap_nopost(struct device *dev, resource_size_t offset,
+ resource_size_t size)
+{
+ void __iomem **ptr, *addr;
+
+ ptr = devres_alloc(devm_ioremap_release, sizeof(*ptr), GFP_KERNEL);
+ if (!ptr)
+ return NULL;
+
+ addr = ioremap_nopost(offset, size);
+ if (addr) {
+ *ptr = addr;
+ devres_add(dev, ptr);
+ } else
+ devres_free(ptr);
+
+ return addr;
+}
+EXPORT_SYMBOL(devm_ioremap_nopost);
+
+/**
* devm_iounmap - Managed iounmap()
* @dev: Generic device to unmap for
* @addr: Address to unmap
@@ -163,6 +191,56 @@ void __iomem *devm_ioremap_resource(struct device *dev, struct resource *res)
}
EXPORT_SYMBOL(devm_ioremap_resource);
+/**
+ * devm_ioremap_nopost_resource() - devm_ioremap_resource() nopost version
+ * @dev: generic device to handle the resource for
+ * @res: resource to be handled
+ *
+ * Checks that a resource is a valid memory region, requests the memory
+ * region and ioremaps it with ioremap_nopost() interface.
+ * All operations are managed and will be undone on driver detach.
+ *
+ * Returns a pointer to the remapped memory or an ERR_PTR() encoded error code
+ * on failure. Usage example:
+ *
+ * res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ * base = devm_ioremap_nopost_resource(&pdev->dev, res);
+ * if (IS_ERR(base))
+ * return PTR_ERR(base);
+ */
+void __iomem *devm_ioremap_nopost_resource(struct device *dev,
+ struct resource *res)
+{
+ resource_size_t size;
+ const char *name;
+ void __iomem *dest_ptr;
+
+ BUG_ON(!dev);
+
+ if (!res || resource_type(res) != IORESOURCE_MEM) {
+ dev_err(dev, "invalid resource\n");
+ return IOMEM_ERR_PTR(-EINVAL);
+ }
+
+ size = resource_size(res);
+ name = res->name ?: dev_name(dev);
+
+ if (!devm_request_mem_region(dev, res->start, size, name)) {
+ dev_err(dev, "can't request region for resource %pR\n", res);
+ return IOMEM_ERR_PTR(-EBUSY);
+ }
+
+ dest_ptr = devm_ioremap_nopost(dev, res->start, size);
+ if (!dest_ptr) {
+ dev_err(dev, "ioremap failed for resource %pR\n", res);
+ devm_release_mem_region(dev, res->start, size);
+ dest_ptr = IOMEM_ERR_PTR(-ENOMEM);
+ }
+
+ return dest_ptr;
+}
+EXPORT_SYMBOL(devm_ioremap_nopost_resource);
+
#ifdef CONFIG_HAS_IOPORT_MAP
/*
* Generic iomap devres
--
2.10.0
^ permalink raw reply related [flat|nested] 171+ messages in thread* [PATCH v3 32/32] lib: implement Devres ioremap_nopost() interface
@ 2017-04-11 12:29 ` Lorenzo Pieralisi
0 siblings, 0 replies; 171+ messages in thread
From: Lorenzo Pieralisi @ 2017-04-11 12:29 UTC (permalink / raw)
To: linux-pci
Cc: linux-arch, Lorenzo Pieralisi, Jonathan Corbet, linux-kernel,
Tejun Heo, Bjorn Helgaas, linux-arm-kernel
The introduction of the ioremap_nopost() interface allows
kernel drivers to map memory through a dedicated kernel
interface providing non-posted writes semantics.
Introduce two new functions in the Devres kernel layer and Devres
documentation:
- devm_ioremap_nopost()
- devm_ioremap_nopost_resource()
so that drivers can make use of devm_* interface to map memory
regions requiring non-posted writes memory attributes.
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Cc: Tejun Heo <tj@kernel.org>
---
Documentation/driver-model/devres.txt | 3 ++
include/linux/device.h | 2 +
include/linux/io.h | 2 +
lib/devres.c | 78 +++++++++++++++++++++++++++++++++++
4 files changed, 85 insertions(+)
diff --git a/Documentation/driver-model/devres.txt b/Documentation/driver-model/devres.txt
index bf34d5b..9991a66 100644
--- a/Documentation/driver-model/devres.txt
+++ b/Documentation/driver-model/devres.txt
@@ -294,7 +294,10 @@ IOMAP
devm_ioremap()
devm_ioremap_nocache()
devm_ioremap_wc()
+ devm_ioremap_nopost()
devm_ioremap_resource() : checks resource, requests memory region, ioremaps
+ devm_ioremap_nopost_resource() : do devm_ioremap_resource() with nopost
+ memory attributes
devm_iounmap()
pcim_iomap()
pcim_iomap_regions() : do request_region() and iomap() on multiple BARs
diff --git a/include/linux/device.h b/include/linux/device.h
index 9ef518a..1dce865 100644
--- a/include/linux/device.h
+++ b/include/linux/device.h
@@ -689,6 +689,8 @@ extern unsigned long devm_get_free_pages(struct device *dev,
extern void devm_free_pages(struct device *dev, unsigned long addr);
void __iomem *devm_ioremap_resource(struct device *dev, struct resource *res);
+void __iomem *devm_ioremap_nopost_resource(struct device *dev,
+ struct resource *res);
/* allows to add/remove a custom action to devres stack */
int devm_add_action(struct device *dev, void (*action)(void *), void *data);
diff --git a/include/linux/io.h b/include/linux/io.h
index 82ef36e..e34d799 100644
--- a/include/linux/io.h
+++ b/include/linux/io.h
@@ -79,6 +79,8 @@ void __iomem *devm_ioremap_nocache(struct device *dev, resource_size_t offset,
resource_size_t size);
void __iomem *devm_ioremap_wc(struct device *dev, resource_size_t offset,
resource_size_t size);
+void __iomem *devm_ioremap_nopost(struct device *dev, resource_size_t offset,
+ resource_size_t size);
void devm_iounmap(struct device *dev, void __iomem *addr);
int check_signature(const volatile void __iomem *io_addr,
const unsigned char *signature, int length);
diff --git a/lib/devres.c b/lib/devres.c
index 78eca71..d16bd76 100644
--- a/lib/devres.c
+++ b/lib/devres.c
@@ -100,6 +100,34 @@ void __iomem *devm_ioremap_wc(struct device *dev, resource_size_t offset,
EXPORT_SYMBOL(devm_ioremap_wc);
/**
+ * devm_ioremap_nopost - Managed ioremap_nopost()
+ * @dev: Generic device to remap IO address for
+ * @offset: Resource address to map
+ * @size: Size of map
+ *
+ * Managed ioremap_nopost(). Map is automatically unmapped on driver detach.
+ */
+void __iomem *devm_ioremap_nopost(struct device *dev, resource_size_t offset,
+ resource_size_t size)
+{
+ void __iomem **ptr, *addr;
+
+ ptr = devres_alloc(devm_ioremap_release, sizeof(*ptr), GFP_KERNEL);
+ if (!ptr)
+ return NULL;
+
+ addr = ioremap_nopost(offset, size);
+ if (addr) {
+ *ptr = addr;
+ devres_add(dev, ptr);
+ } else
+ devres_free(ptr);
+
+ return addr;
+}
+EXPORT_SYMBOL(devm_ioremap_nopost);
+
+/**
* devm_iounmap - Managed iounmap()
* @dev: Generic device to unmap for
* @addr: Address to unmap
@@ -163,6 +191,56 @@ void __iomem *devm_ioremap_resource(struct device *dev, struct resource *res)
}
EXPORT_SYMBOL(devm_ioremap_resource);
+/**
+ * devm_ioremap_nopost_resource() - devm_ioremap_resource() nopost version
+ * @dev: generic device to handle the resource for
+ * @res: resource to be handled
+ *
+ * Checks that a resource is a valid memory region, requests the memory
+ * region and ioremaps it with ioremap_nopost() interface.
+ * All operations are managed and will be undone on driver detach.
+ *
+ * Returns a pointer to the remapped memory or an ERR_PTR() encoded error code
+ * on failure. Usage example:
+ *
+ * res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ * base = devm_ioremap_nopost_resource(&pdev->dev, res);
+ * if (IS_ERR(base))
+ * return PTR_ERR(base);
+ */
+void __iomem *devm_ioremap_nopost_resource(struct device *dev,
+ struct resource *res)
+{
+ resource_size_t size;
+ const char *name;
+ void __iomem *dest_ptr;
+
+ BUG_ON(!dev);
+
+ if (!res || resource_type(res) != IORESOURCE_MEM) {
+ dev_err(dev, "invalid resource\n");
+ return IOMEM_ERR_PTR(-EINVAL);
+ }
+
+ size = resource_size(res);
+ name = res->name ?: dev_name(dev);
+
+ if (!devm_request_mem_region(dev, res->start, size, name)) {
+ dev_err(dev, "can't request region for resource %pR\n", res);
+ return IOMEM_ERR_PTR(-EBUSY);
+ }
+
+ dest_ptr = devm_ioremap_nopost(dev, res->start, size);
+ if (!dest_ptr) {
+ dev_err(dev, "ioremap failed for resource %pR\n", res);
+ devm_release_mem_region(dev, res->start, size);
+ dest_ptr = IOMEM_ERR_PTR(-ENOMEM);
+ }
+
+ return dest_ptr;
+}
+EXPORT_SYMBOL(devm_ioremap_nopost_resource);
+
#ifdef CONFIG_HAS_IOPORT_MAP
/*
* Generic iomap devres
--
2.10.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 171+ messages in thread
* Re: [PATCH v3 00/32] PCI: fix config and I/O Address space memory mappings
2017-04-11 12:28 ` Lorenzo Pieralisi
(?)
@ 2017-04-11 13:38 ` Benjamin Herrenschmidt
-1 siblings, 0 replies; 171+ messages in thread
From: Benjamin Herrenschmidt @ 2017-04-11 13:38 UTC (permalink / raw)
To: Lorenzo Pieralisi, linux-pci
Cc: Jonas Bonn, Rich Felker, Catalin Marinas, Will Deacon,
James E.J. Bottomley, David Howells, Max Filippov,
Paul Mackerras, Huacai Chen, Guan Xuetao, Thomas Gleixner,
Hans-Christian Egtvedt, linux-arch, Jesper Nilsson,
Yoshinori Sato, Michael Ellerman, Helge Deller, Russell King,
Ingo Molnar, Geert Uytterhoeven, Matt Turner, Haavard Skinnemoen,
Fenghua Yu, James Hogan, Chris Metcalf, Arnd Bergmann,
Heiko Carstens, Stefan Kristiansson, Mikael Starvik,
Ivan Kokshaysky, Bjorn Helgaas, Stafford Horne, linux-arm-kernel,
Richard Henderson, Chris Zankel, Michal Simek, Tony Luck,
Vineet Gupta, linux-kernel, Ralf Baechle, Richard Kuo,
Niklas Cassel, Luis R. Rodriguez, Martin Schwidefsky,
Ley Foon Tan, David S. Miller
T24gVHVlLCAyMDE3LTA0LTExIGF0IDEzOjI4ICswMTAwLCBMb3JlbnpvIFBpZXJhbGlzaSB3cm90
ZToKPiBUaGlzIHBhdGNoIHNlcmllc1sxXSBpcyBhIHYzIG9mIGEgcHJldmlvdXMgdmVyc2lvbjoK
PiAKPiB2MjogaHR0cHM6Ly9sa21sLm9yZy9sa21sLzIwMTcvMy8yNy8yMjAKCkkgYW0gbm90IGEg
ZmFuIG9mIHRoaXMgYXQgQWxsLgoKVGhhdCB3aG9sZSBjb25jZXB0IG9mICJpb3JlbWFwX25vcG9z
dCIgaXMgc2ltcGx5IG5vdCBhcHBsaWNhYmxlIHRvIHRoZQptYWpvcml0eSBvZiBhcmNoaXRlY3R1
cmVzIGFuZCBjZXJ0YWlubHkgbm90IGluIGEgd2F5IHRoYXQgY2FuIGFwcGx5IHRvCmFyYml0cmFy
eSBtYXBwaW5ncy4KCkl0J3MgYWxzbyB2ZXJ5IHdyb25nIHRvIHByb3ZpZGUgYSAiZGVmYXVsdCIg
b3BlcmF0aW9uIHdob3NlIHNlbWFudGljcwphcmUgd2Vha2VyIHRoYW4gd2hhdCBpdCdzIHN1cHBv
c2VkIHRvIGltcGxlbWVudC4gVmVyeSB3cm9uZyBhY3R1YWxseS4KUGVvcGxlIHdpbGwgdXNlIGl0
IGFzc3VtaW5nIHRoZSBub24tcG9zdGVkIGJlaGF2aW91ciBhbmQgdGhpbmdzIHdpbGwKYnJlYWsg
aW4gc3VidGxlIHdheSB3aGVuIGl0IGNhbm5vdCBiZSBwcm92aWRlZC4KCldoYXQgZXhhY3RseSBh
cmUgeW91IHRyeWluZyB0byBmaXggaGVyZSA/CgpJZiBhIGdpdmVuIFBDSWUgaG9zdCBicmlkZ2Ug
KGFyY2hpdGVjdHVyZSBzcGVjaWZpYykgcmVxdWlyZSBhIHNwZWNpYWwKc2F1Y2UgdG8gcHJvdmlk
ZSB0aGUgaWxsdXNpb24gb2Ygbm9uLXBvc3RpbmcsIHRoZW4gaW1wbGVtZW50IHRoaXMgaW4KdGhl
IGFjdHVhbCByb290IGNvbXBsZXggY29kZS4KCkJUVy4gSSdtIHByZXR0eSBzdXJlIHdlICJhY2Np
ZGVudGFsbHkiIG1hZGUgY29uZmlnIHdyaXRlcyBwb3N0ZWQgYXQKbGVhc3QgdG8gdGhlIFBIQiBv
biBhIG51bWJlciBvZiBwb3dlcnBjIHN5c3RlbXMgZm9yZXZlciBhbmQgd2UgKm5ldmVyKgpoYWQg
YSBwcm9ibGVtIGJlY2F1c2Ugb2YgaXQgOykKCj4gdjIgLT4gdjM6Cj4gCS0gQ3JlYXRlZCBhIGRl
ZmF1bHQgaW9yZW1hcF9ub3Bvc3QoKSBpbXBsZW1lbnRhdGlvbiBpbiBhCj4gc2VwYXJhdGUKPiAJ
wqDCoGFzbS1nZW5lcmljIGhlYWRlciBhbmQgcGF0Y2hlZCBhbGwgYXJjaGVzIHRvIG1ha2UgdXNl
IG9mIGl0Cj4gCS0gUmVtb3ZlZCBQQ0kgZHJpdmVycyBwYXRjaGVzIGZyb20gdGhlIHNlcmllcyB0
byBzaW1wbGlmeSB0aGUKPiAJwqDCoHJldmlldywgdGhleSB3aWxsIGJlIHBvc3RlZCBzZXBhcmF0
ZWx5IG9uY2UgdGhlCj4gaW9yZW1hcF9ub3Bvc3QoKQo+IAnCoMKgaW50ZXJmYWNlIGlzIHNldHRs
ZWQKPiAJLSBGaXhlZCBkZXZtX2lvcmVtYXBfKiBCVVMgb2Zmc2V0IGNvbW1lbnRzIGFuZCBpbXBs
ZW1lbnRlZAo+IAnCoMKgbm9wb3N0IGludGVyZmFjZSBvbiB0b3Agb2YgaXQKPiAJLSBBZGRlZCBj
b2xsZWN0ZWQgdGFncwo+IAo+IHYxOiBodHRwczovL2xrbWwub3JnL2xrbWwvMjAxNy8yLzI3LzIy
OAo+IAo+IHYxIC0+IHYyOgo+IAktIENoYW5nZWQgcGNpX3JlbWFwX2NmZ3NwYWNlKCkgdG8gbW9y
ZSBnZW5lcmljIGlvcmVtYXBfbm9wb3N0KCkKPiAJwqDCoGludGVyZmFjZQo+IAktIEFkZGVkIHBn
cHJvdF9ub25wb3N0ZWQKPiAJLSBGaXhlZCBidWlsZCBlcnJvcnMgb24gYXJjaGVzIG5vdCByZWx5
aW5nIG9uIGFzbS1nZW5lcmljCj4gaGVhZGVycwo+IAktIEFkZGVkIFBDSSB2ZXJzYXRpbGUgaG9z
dCBjb250cm9sbGVyIGRyaXZlciBwYXRjaAo+IAktIEFkZGVkIG1pc3NpbmcgY29uZmlnIHNwYWNl
IHJlbWFwcGluZyB0byBoaXNpbGljb24gaG9zdAo+IGNvbnRyb2xsZXIKPiAKPiAtLS0tLS0tLS0t
LS0tLS0tLS0tLS0KPiBPcmlnaW5hbCBjb3ZlciBsZXR0ZXIKPiAtLS0tLS0tLS0tLS0tLS0tLS0t
LS0KPiAKPiBQQ0kgbG9jYWwgYnVzIHNwZWNpZmljYXRpb25zIChSZXYzLjAsIDMuMi41ICJUcmFu
c2FjdGlvbiBPcmRlcmluZwo+IGFuZCBQb3N0aW5nIikgc3RyaWN0bHkgcmVxdWlyZSBQQ0kgY29u
ZmlndXJhdGlvbiBhbmQgSS9PIEFkZHJlc3MKPiBzcGFjZQo+IHdyaXRlIHRyYW5zYWN0aW9ucyB0
byBiZSBub24tcG9zdGVkLgo+IAo+IEN1cnJlbnQgY3JvcCBvZiBEVC9BQ1BJIFBDSSBob3N0IGNv
bnRyb2xsZXJzIGRyaXZlcnMgcmVsaWVzIG9uCj4gdGhlIGlvcmVtYXAgaW50ZXJmYWNlIHRvIG1h
cCBFQ0FNIGFuZCBFQ0FNLWRlcml2YXRpdmUgUENJIGNvbmZpZwo+IHJlZ2lvbnMgYW5kIHBjaV9y
ZW1hcF9pb3NwYWNlKCkgdG8gY3JlYXRlIGEgVk1BIGZvciBtYXBwaW5nCj4gUENJIGhvc3QgYnJp
ZGdlIEkvTyBBZGRyZXNzIHNwYWNlIHRyYW5zYWN0aW9ucyB0byBDUFUgdmlydHVhbCBhZGRyZXNz
Cj4gc3BhY2UuCj4gCj4gT24gc29tZSBwbGF0Zm9ybXMgKGllIEFSTS9BUk02NCkgaW9yZW1hcCBm
YWlscyB0byBjb21wbHkgd2l0aCB0aGUgUENJCj4gY29uZmlndXJhdGlvbiBub24tcG9zdGVkIHdy
aXRlIHRyYW5zYWN0aW9ucyByZXF1aXJlbWVudCwgYmVjYXVzZSBpdAo+IHByb3ZpZGVzIGEgbWVt
b3J5IG1hcHBpbmcgdGhhdCBpc3N1ZXMgImJ1ZmZlcmFibGUiIG9yLCBpbiBQQ0kgdGVybXMKPiAi
cG9zdGVkIiB3cml0ZSB0cmFuc2FjdGlvbnMuIExpa2V3aXNlLCB0aGUgY3VycmVudAo+IHBjaV9y
ZW1hcF9pb3NwYWNlKCkKPiBpbXBsZW1lbnRhdGlvbiBtYXBzIHRoZSBwaHlzaWNhbCBhZGRyZXNz
IHJhbmdlIHRoYXQgdGhlIFBDSQo+IHRyYW5zbGF0ZXMKPiB0byBJL08gc3BhY2UgY3ljbGVzIHRv
IHZpcnR1YWwgYWRkcmVzcyBzcGFjZSB0aHJvdWdoIHBncHJvdF9kZXZpY2UoKQo+IGF0dHJpYnV0
ZXMgdGhhdCBvbiBlZyBBUk02NCBwcm92aWRlcyBhIG1lbW9yeSBtYXBwaW5nIGlzc3VpbmcKPiBw
b3N0ZWQgd3JpdGVzIHRyYW5zYWN0aW9ucywgd2hpY2ggaXMgbm90IFBDSSBzcGVjaWZpY2F0aW9u
cwo+IGNvbXBsaWFudC4KPiAKPiBUaGlzIHBhdGNoIHNlcmllc1sxXSBhZGRyZXNzZXMgYm90aCBp
c3N1ZXMgaW4gb25lIGdvOgo+IAo+IC0gSXQgdXBkYXRlcyB0aGUgcGNpX3JlbWFwX2lvc3BhY2Uo
KSBmdW5jdGlvbiB0byB1c2UgYSBwYWdlIG1hcHBpbmcKPiDCoCB0aGF0IGd1YXJhbnRlZXMgbm9u
LXBvc3RlZCB3cml0ZSB0cmFuc2FjdGlvbnMgZm9yIEkvTyBzcGFjZQo+IGFkZHJlc3Nlcwo+IC0g
SXQgYWRkcyBhIGtlcm5lbCBBUEkgdG8gcmVtYXAgUENJIGNvbmZpZyBzcGFjZSByZXNvdXJjZXMs
IHNvIHRoYXQKPiDCoCBhcmNoaXRlY3R1cmUgY2FuIG92ZXJyaWRlIGl0IHdpdGggYSBtYXBwaW5n
IGltcGxlbWVudGF0aW9uIHRoYXQKPiDCoCBndWFyYW50ZWVzIFBDSSBzcGVjaWZpY2F0aW9ucyBj
b21wbGlhbmN5IHdydCBub24tcG9zdGVkIHdyaXRlCj4gwqAgY29uZmlndXJhdGlvbiB0cmFuc2Fj
dGlvbnMKPiAtIEl0IHVwZGF0ZXMgYWxsIFBDSSBob3N0IGNvbnRyb2xsZXIgaW1wbGVtZW50YXRp
b25zIChhbmQgdGhlIGdlbmVyaWMKPiDCoCBFQ0FNIGxheWVyKSB0byB1c2UgdGhlIG5ld2x5IGlu
dHJvZHVjZWQgbWFwcGluZyBpbnRlcmZhY2UKPiAKPiBUZXN0ZWQgb24gSnVubyBFQ0FNIGJhc2Vk
IGludGVyZmFjZSAoRFQvQUNQSSkuCj4gCj4gTm9uLUVDQU0gUENJIGhvc3QgY29udHJvbGxlciBk
cml2ZXJzIHBhdGNoZXMgbmVlZCBjaGVja2luZyB0byBtYWtlCj4gc3VyZSB0aGF0Ogo+IAo+IC0g
SSBwYXRjaGVkIHRoZSBjb3JyZWN0IHJlc291cmNlIHJlZ2lvbiBtYXBwaW5nIGZvciBjb25maWcg
c3BhY2UKPiAtIFRoZXJlIGFyZSBub3QgYW55IG90aGVyIHdheXMgdG8gZW5zdXJlIHBvc3RlZC13
cml0ZSBjb21wbGV0aW9uCj4gwqAgaW4gdGhlIHJlc3BlY3RpdmUgcGNpX29wcyB0aGF0IG1ha2Ug
dGhlIHJlbGV2YW50IHBhdGNoIHVubmVjZXNzYXJ5Cj4gCj4gWzFdCj4gZ2l0Oi8vZ2l0Lmtlcm5l
bC5vcmcvcHViL3NjbS9saW51eC9rZXJuZWwvZ2l0L2xwaWVyYWxpc2kvbGludXguZ2l0Cj4gcGNp
L2NvbmZpZy1pby1tYXBwaW5ncy1maXgtdjMKPiAKPiBMb3JlbnpvIFBpZXJhbGlzaSAoMzIpOgo+
IMKgIFBDSTogcmVtb3ZlIF9fd2VhayB0YWcgZnJvbSBwY2lfcmVtYXBfaW9zcGFjZSgpCj4gwqAg
YXNtLWdlbmVyaWMvcGd0YWJsZS5oOiBpbnRyb2R1Y2UgcGdwcm90X25vbnBvc3RlZCByZW1hcCBh
dHRyaWJ1dGUKPiDCoCBQQ0k6IGZpeCBwY2lfcmVtYXBfaW9zcGFjZSgpIHJlbWFwIGF0dHJpYnV0
ZQo+IMKgIGFzbS1nZW5lcmljOiBhZGQgaW9yZW1hcF9ub3Bvc3QoKSByZW1hcCBpbnRlcmZhY2UK
PiDCoCBhbHBoYTogaW5jbHVkZSBkZWZhdWx0IGlvcmVtYXBfbm9wb3N0KCkgaW1wbGVtZW50YXRp
b24KPiDCoCBhdnIzMjogaW5jbHVkZSBkZWZhdWx0IGlvcmVtYXBfbm9wb3N0KCkgaW1wbGVtZW50
YXRpb24KPiDCoCBhcmM6IGluY2x1ZGUgZGVmYXVsdCBpb3JlbWFwX25vcG9zdCgpIGltcGxlbWVu
dGF0aW9uCj4gwqAgY3JpczogaW5jbHVkZSBkZWZhdWx0IGlvcmVtYXBfbm9wb3N0KCkgaW1wbGVt
ZW50YXRpb24KPiDCoCBmcnY6IGluY2x1ZGUgZGVmYXVsdCBpb3JlbWFwX25vcG9zdCgpIGltcGxl
bWVudGF0aW9uCj4gwqAgaGV4YWdvbjogaW5jbHVkZSBkZWZhdWx0IGlvcmVtYXBfbm9wb3N0KCkg
aW1wbGVtZW50YXRpb24KPiDCoCBpYTY0OiBpbmNsdWRlIGRlZmF1bHQgaW9yZW1hcF9ub3Bvc3Qo
KSBpbXBsZW1lbnRhdGlvbgo+IMKgIG0zMnI6IGluY2x1ZGUgZGVmYXVsdCBpb3JlbWFwX25vcG9z
dCgpIGltcGxlbWVudGF0aW9uCj4gwqAgbTY4azogaW5jbHVkZSBkZWZhdWx0IGlvcmVtYXBfbm9w
b3N0KCkgaW1wbGVtZW50YXRpb24KPiDCoCBtZXRhZzogaW5jbHVkZSBkZWZhdWx0IGlvcmVtYXBf
bm9wb3N0KCkgaW1wbGVtZW50YXRpb24KPiDCoCBtaWNyb2JsYXplOiBpbmNsdWRlIGRlZmF1bHQg
aW9yZW1hcF9ub3Bvc3QoKSBpbXBsZW1lbnRhdGlvbgo+IMKgIG1pcHM6IGluY2x1ZGUgZGVmYXVs
dCBpb3JlbWFwX25vcG9zdCgpIGltcGxlbWVudGF0aW9uCj4gwqAgbW4xMDMwMDogaW5jbHVkZSBk
ZWZhdWx0IGlvcmVtYXBfbm9wb3N0KCkgaW1wbGVtZW50YXRpb24KPiDCoCBuaW9zMjogaW5jbHVk
ZSBkZWZhdWx0IGlvcmVtYXBfbm9wb3N0KCkgaW1wbGVtZW50YXRpb24KPiDCoCBvcGVucmlzYzog
aW5jbHVkZSBkZWZhdWx0IGlvcmVtYXBfbm9wb3N0KCkgaW1wbGVtZW50YXRpb24KPiDCoCBwYXJp
c2M6IGluY2x1ZGUgZGVmYXVsdCBpb3JlbWFwX25vcG9zdCgpIGltcGxlbWVudGF0aW9uCj4gwqAg
cG93ZXJwYzogaW5jbHVkZSBkZWZhdWx0IGlvcmVtYXBfbm9wb3N0KCkgaW1wbGVtZW50YXRpb24K
PiDCoCBzMzkwOiBpbmNsdWRlIGRlZmF1bHQgaW9yZW1hcF9ub3Bvc3QoKSBpbXBsZW1lbnRhdGlv
bgo+IMKgIHNoOiBpbmNsdWRlIGRlZmF1bHQgaW9yZW1hcF9ub3Bvc3QoKSBpbXBsZW1lbnRhdGlv
bgo+IMKgIHNwYXJjOiBpbmNsdWRlIGRlZmF1bHQgaW9yZW1hcF9ub3Bvc3QoKSBpbXBsZW1lbnRh
dGlvbgo+IMKgIHRpbGU6IGluY2x1ZGUgZGVmYXVsdCBpb3JlbWFwX25vcG9zdCgpIGltcGxlbWVu
dGF0aW9uCj4gwqAgdW5pY29yZTMyOiBpbmNsdWRlIGRlZmF1bHQgaW9yZW1hcF9ub3Bvc3QoKSBp
bXBsZW1lbnRhdGlvbgo+IMKgIHg4NjogaW5jbHVkZSBkZWZhdWx0IGlvcmVtYXBfbm9wb3N0KCkg
aW1wbGVtZW50YXRpb24KPiDCoCB4dGVuc2E6IGluY2x1ZGUgZGVmYXVsdCBpb3JlbWFwX25vcG9z
dCgpIGltcGxlbWVudGF0aW9uCj4gwqAgYXJtNjQ6IGltcGxlbWVudCBpb3JlbWFwX25vcG9zdCgp
IGludGVyZmFjZQo+IMKgIGFybTogaW1wbGVtZW50IGlvcmVtYXBfbm9wb3N0KCkgaW50ZXJmYWNl
Cj4gwqAgbGliOiBmaXggRGV2cmVzIGRldm1faW9yZW1hcF8qIG9mZnNldCBwYXJhbWV0ZXIga2Vy
bmVsZG9jCj4gZGVzY3JpcHRpb24KPiDCoCBsaWI6IGltcGxlbWVudCBEZXZyZXMgaW9yZW1hcF9u
b3Bvc3QoKSBpbnRlcmZhY2UKPiAKPiDCoERvY3VtZW50YXRpb24vZHJpdmVyLW1vZGVsL2RldnJl
cy50eHQgfMKgwqAzICsrCj4gwqBhcmNoL2FscGhhL2luY2x1ZGUvYXNtL2lvLmjCoMKgwqDCoMKg
wqDCoMKgwqDCoMKgfMKgwqAxICsKPiDCoGFyY2gvYXJjL2luY2x1ZGUvYXNtL2lvLmjCoMKgwqDC
oMKgwqDCoMKgwqDCoMKgwqDCoHzCoMKgMSArCj4gwqBhcmNoL2FybS9pbmNsdWRlL2FzbS9pby5o
wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqB8wqDCoDkgKysrKwo+IMKgYXJjaC9hcm0vbW0vaW9y
ZW1hcC5jwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoHzCoMKgNyArKysKPiDCoGFy
Y2gvYXJtL21tL25vbW11LmPCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoHzC
oMKgOSArKysrCj4gwqBhcmNoL2FybTY0L2luY2x1ZGUvYXNtL2lvLmjCoMKgwqDCoMKgwqDCoMKg
wqDCoMKgfCAxMiArKysrKwo+IMKgYXJjaC9hdnIzMi9pbmNsdWRlL2FzbS9pby5owqDCoMKgwqDC
oMKgwqDCoMKgwqDCoHzCoMKgMSArCj4gwqBhcmNoL2NyaXMvaW5jbHVkZS9hc20vaW8uaMKgwqDC
oMKgwqDCoMKgwqDCoMKgwqDCoHzCoMKgMSArCj4gwqBhcmNoL2Zydi9pbmNsdWRlL2FzbS9pby5o
wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqB8wqDCoDEgKwo+IMKgYXJjaC9oZXhhZ29uL2luY2x1
ZGUvYXNtL2lvLmjCoMKgwqDCoMKgwqDCoMKgwqB8wqDCoDIgKwo+IMKgYXJjaC9pYTY0L2luY2x1
ZGUvYXNtL2lvLmjCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqB8wqDCoDEgKwo+IMKgYXJjaC9tMzJy
L2luY2x1ZGUvYXNtL2lvLmjCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqB8wqDCoDEgKwo+IMKgYXJj
aC9tNjhrL2luY2x1ZGUvYXNtL2lvLmjCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqB8wqDCoDEgKwo+
IMKgYXJjaC9tZXRhZy9pbmNsdWRlL2FzbS9pby5owqDCoMKgwqDCoMKgwqDCoMKgwqDCoHzCoMKg
MiArCj4gwqBhcmNoL21pY3JvYmxhemUvaW5jbHVkZS9hc20vaW8uaMKgwqDCoMKgwqDCoHzCoMKg
MSArCj4gwqBhcmNoL21pcHMvaW5jbHVkZS9hc20vaW8uaMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC
oHzCoMKgMSArCj4gwqBhcmNoL21uMTAzMDAvaW5jbHVkZS9hc20vaW8uaMKgwqDCoMKgwqDCoMKg
wqDCoHzCoMKgMSArCj4gwqBhcmNoL25pb3MyL2luY2x1ZGUvYXNtL2lvLmjCoMKgwqDCoMKgwqDC
oMKgwqDCoMKgfMKgwqAxICsKPiDCoGFyY2gvb3BlbnJpc2MvaW5jbHVkZS9hc20vaW8uaMKgwqDC
oMKgwqDCoMKgwqB8wqDCoDIgKwo+IMKgYXJjaC9wYXJpc2MvaW5jbHVkZS9hc20vaW8uaMKgwqDC
oMKgwqDCoMKgwqDCoMKgfMKgwqAxICsKPiDCoGFyY2gvcG93ZXJwYy9pbmNsdWRlL2FzbS9pby5o
wqDCoMKgwqDCoMKgwqDCoMKgfMKgwqAxICsKPiDCoGFyY2gvczM5MC9pbmNsdWRlL2FzbS9pby5o
wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgfMKgwqAxICsKPiDCoGFyY2gvc2gvaW5jbHVkZS9hc20v
aW8uaMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqB8wqDCoDEgKwo+IMKgYXJjaC9zcGFyYy9p
bmNsdWRlL2FzbS9pby5owqDCoMKgwqDCoMKgwqDCoMKgwqDCoHzCoMKgMSArCj4gwqBhcmNoL3Rp
bGUvaW5jbHVkZS9hc20vaW8uaMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoHzCoMKgMSArCj4gwqBh
cmNoL3VuaWNvcmUzMi9pbmNsdWRlL2FzbS9pby5owqDCoMKgwqDCoMKgwqB8wqDCoDEgKwo+IMKg
YXJjaC94ODYvaW5jbHVkZS9hc20vaW8uaMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgfMKgwqAx
ICsKPiDCoGFyY2gveHRlbnNhL2luY2x1ZGUvYXNtL2lvLmjCoMKgwqDCoMKgwqDCoMKgwqDCoHzC
oMKgMSArCj4gwqBkcml2ZXJzL3BjaS9wY2kuY8KgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC
oMKgwqDCoMKgwqDCoHzCoMKgNCArLQo+IMKgaW5jbHVkZS9hc20tZ2VuZXJpYy9pb3JlbWFwLW5v
cG9zdC5owqDCoHzCoMKgOSArKysrCj4gwqBpbmNsdWRlL2FzbS1nZW5lcmljL3BndGFibGUuaMKg
wqDCoMKgwqDCoMKgwqDCoHzCoMKgNCArKwo+IMKgaW5jbHVkZS9saW51eC9kZXZpY2UuaMKgwqDC
oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgfMKgwqAyICsKPiDCoGluY2x1ZGUvbGludXgvaW8u
aMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqB8wqDCoDIgKwo+IMKgbGli
L2RldnJlcy5jwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg
wqDCoHwgODQKPiArKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKystLQo+IMKgMzUgZmls
ZXMgY2hhbmdlZCwgMTY3IGluc2VydGlvbnMoKyksIDUgZGVsZXRpb25zKC0pCj4gwqBjcmVhdGUg
bW9kZSAxMDA2NDQgaW5jbHVkZS9hc20tZ2VuZXJpYy9pb3JlbWFwLW5vcG9zdC5oCj4gCgpfX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpsaW51eC1hcm0ta2Vy
bmVsIG1haWxpbmcgbGlzdApsaW51eC1hcm0ta2VybmVsQGxpc3RzLmluZnJhZGVhZC5vcmcKaHR0
cDovL2xpc3RzLmluZnJhZGVhZC5vcmcvbWFpbG1hbi9saXN0aW5mby9saW51eC1hcm0ta2VybmVs
Cg==
^ permalink raw reply [flat|nested] 171+ messages in thread
* [PATCH v3 00/32] PCI: fix config and I/O Address space memory mappings
@ 2017-04-11 13:38 ` Benjamin Herrenschmidt
0 siblings, 0 replies; 171+ messages in thread
From: Benjamin Herrenschmidt @ 2017-04-11 13:38 UTC (permalink / raw)
To: linux-arm-kernel
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.
What exactly are you trying to fix here ?
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 ;)
> 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
>
^ permalink raw reply [flat|nested] 171+ messages in thread
* Re: [PATCH v3 00/32] PCI: fix config and I/O Address space memory mappings
@ 2017-04-11 13:38 ` Benjamin Herrenschmidt
0 siblings, 0 replies; 171+ messages in thread
From: Benjamin Herrenschmidt @ 2017-04-11 13:38 UTC (permalink / raw)
To: Lorenzo Pieralisi, linux-pci
Cc: Jonas Bonn, Rich Felker, Catalin Marinas, Will Deacon,
James E.J. Bottomley, David Howells, Max Filippov,
Paul Mackerras, Huacai Chen, Guan Xuetao, Thomas Gleixner,
Hans-Christian Egtvedt, linux-arch, Jesper Nilsson,
Yoshinori Sato, Michael Ellerman, Helge Deller, Russell King,
Ingo Molnar, Geert Uytterhoeven, Matt Turner, Haavard Skinnemoen,
Fenghua Yu, James Hogan
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.
What exactly are you trying to fix here ?
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 ;)
> 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
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 171+ messages in thread
* Re: [PATCH v3 00/32] PCI: fix config and I/O Address space memory mappings
2017-04-11 13:38 ` Benjamin Herrenschmidt
(?)
@ 2017-04-11 14:08 ` Lorenzo Pieralisi
-1 siblings, 0 replies; 171+ messages in thread
From: Lorenzo Pieralisi @ 2017-04-11 14:08 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Jonas Bonn, Rich Felker, linux-pci, Will Deacon,
James E.J. Bottomley, David Howells, Max Filippov,
Paul Mackerras, Huacai Chen, Guan Xuetao, Thomas Gleixner,
Hans-Christian Egtvedt, linux-arch, Jesper Nilsson,
Yoshinori Sato, Michael Ellerman, Helge Deller, Russell King,
Ingo Molnar, Geert Uytterhoeven, Catalin Marinas, Matt Turner,
Haavard Skinnemoen, Fenghua Yu, James Hogan, Chris Metcalf,
Arnd Bergmann, Heiko Carstens, Stefan Kristiansson,
Mikael Starvik, Ivan Kokshaysky, Bjorn Helgaas, Stafford Horne,
linux-arm-kernel, Richard Henderson, Chris Zankel, Michal Simek,
Tony Luck, Vineet Gupta, linux-kernel, Ralf Baechle, Richard Kuo,
Niklas Cassel, Luis R. Rodriguez, Martin Schwidefsky,
Ley Foon Tan, David S. Miller
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).
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.
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.
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 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
> > =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 generic
> > =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 unnecessary
> > =
> > [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 attribute
> > =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
^ permalink raw reply [flat|nested] 171+ messages in thread
* [PATCH v3 00/32] PCI: fix config and I/O Address space memory mappings
@ 2017-04-11 14:08 ` Lorenzo Pieralisi
0 siblings, 0 replies; 171+ messages in thread
From: Lorenzo Pieralisi @ 2017-04-11 14:08 UTC (permalink / raw)
To: linux-arm-kernel
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).
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.
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.
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
> >
^ permalink raw reply [flat|nested] 171+ messages in thread
* Re: [PATCH v3 00/32] PCI: fix config and I/O Address space memory mappings
@ 2017-04-11 14:08 ` Lorenzo Pieralisi
0 siblings, 0 replies; 171+ messages in thread
From: Lorenzo Pieralisi @ 2017-04-11 14:08 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Jonas Bonn, Rich Felker, linux-pci, Will Deacon,
James E.J. Bottomley, David Howells, Max Filippov,
Paul Mackerras, Huacai Chen, Guan Xuetao, Thomas Gleixner,
Hans-Christian Egtvedt, linux-arch, Jesper Nilsson,
Yoshinori Sato, Michael Ellerman, Helge Deller, Russell King,
Ingo Molnar, Geert Uytterhoeven, Catalin Marinas, Matt Turner,
Haavard Skinnemoen, Fenghua Yu
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).
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.
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.
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
> >
^ permalink raw reply [flat|nested] 171+ messages in thread
* Re: [PATCH v3 00/32] PCI: fix config and I/O Address space memory mappings
2017-04-11 14:08 ` Lorenzo Pieralisi
(?)
@ 2017-04-11 23:12 ` Benjamin Herrenschmidt
-1 siblings, 0 replies; 171+ messages in thread
From: Benjamin Herrenschmidt @ 2017-04-11 23:12 UTC (permalink / raw)
To: Lorenzo Pieralisi
Cc: Jonas Bonn, Rich Felker, linux-pci, Will Deacon,
James E.J. Bottomley, David Howells, Max Filippov,
Paul Mackerras, Huacai Chen, Guan Xuetao, Thomas Gleixner,
Hans-Christian Egtvedt, linux-arch, Jesper Nilsson,
Yoshinori Sato, Michael Ellerman, Helge Deller, Russell King,
Ingo Molnar, Geert Uytterhoeven, Catalin Marinas, Matt Turner,
Haavard Skinnemoen, Fenghua Yu, James Hogan, Chris Metcalf,
Arnd Bergmann, Heiko Carstens, Stefan Kristiansson,
Mikael Starvik, Ivan Kokshaysky, Bjorn Helgaas, Stafford Horne,
linux-arm-kernel, Richard Henderson, Chris Zankel, Michal Simek,
Tony Luck, Vineet Gupta, linux-kernel, Ralf Baechle, Richard Kuo,
Niklas Cassel, Luis R. Rodriguez, Martin Schwidefsky,
Ley Foon Tan, David S. Miller
T24gVHVlLCAyMDE3LTA0LTExIGF0IDE1OjA4ICswMTAwLCBMb3JlbnpvIFBpZXJhbGlzaSB3cm90
ZToKPiBPbiBUdWUsIEFwciAxMSwgMjAxNyBhdCAxMTozODoyNlBNICsxMDAwLCBCZW5qYW1pbiBI
ZXJyZW5zY2htaWR0IHdyb3RlOgo+ID4gT24gVHVlLCAyMDE3LTA0LTExIGF0IDEzOjI4ICswMTAw
LCBMb3JlbnpvIFBpZXJhbGlzaSB3cm90ZToKPiA+ID4gVGhpcyBwYXRjaCBzZXJpZXNbMV0gaXMg
YSB2MyBvZiBhIHByZXZpb3VzIHZlcnNpb246Cj4gPiA+IAo+ID4gPiB2MjogaHR0cHM6Ly9sa21s
Lm9yZy9sa21sLzIwMTcvMy8yNy8yMjAKPiA+IAo+ID4gSSBhbSBub3QgYSBmYW4gb2YgdGhpcyBh
dCBBbGwuCj4gPiAKPiA+IFRoYXQgd2hvbGUgY29uY2VwdCBvZiAiaW9yZW1hcF9ub3Bvc3QiIGlz
IHNpbXBseSBub3QgYXBwbGljYWJsZSB0byB0aGUKPiA+IG1ham9yaXR5IG9mIGFyY2hpdGVjdHVy
ZXMgYW5kIGNlcnRhaW5seSBub3QgaW4gYSB3YXkgdGhhdCBjYW4gYXBwbHkgdG8KPiA+IGFyYml0
cmFyeSBtYXBwaW5ncy4KPiA+IAo+ID4gSXQncyBhbHNvIHZlcnkgd3JvbmcgdG8gcHJvdmlkZSBh
ICJkZWZhdWx0IiBvcGVyYXRpb24gd2hvc2Ugc2VtYW50aWNzCj4gPiBhcmUgd2Vha2VyIHRoYW4g
d2hhdCBpdCdzIHN1cHBvc2VkIHRvIGltcGxlbWVudC4gVmVyeSB3cm9uZyBhY3R1YWxseS4KPiA+
IFBlb3BsZSB3aWxsIHVzZSBpdCBhc3N1bWluZyB0aGUgbm9uLXBvc3RlZCBiZWhhdmlvdXIgYW5k
IHRoaW5ncyB3aWxsCj4gPiBicmVhayBpbiBzdWJ0bGUgd2F5IHdoZW4gaXQgY2Fubm90IGJlIHBy
b3ZpZGVkLgo+IAo+IFdlbGwsIHdoYXQncyB2ZXJ5IHdyb25nIGZvciB5b3UgaXQgaXMgbm90IHZl
cnkgd3JvbmcgZm9yIG90aGVycwo+IChpdCBpcyBqdXN0IHYzLCB0aGF0J3MgZmluZSwgc2VlIHRo
cmVhZCBiZWxvdykuCgpNYXliZSwgYnV0IEkgZG9uJ3Qgc2VlIGluIHdoYXQgdW5pdmVyc2UgaXQg
aXMgb2sgdG8gaGF2ZSBzb21ldGhpbmcKZGVmaW5lZCBmb3IgdGhlIHN0cm9uZ2VyIG9yZGVyaW5n
IHNlbWFudGljcyBpdCBwcm92aWRlIHNpbGVudGx5CmZhbGxiYWNrIHRvIHdlYWtlciBzZW1hbnRp
Y3MuCgo+IEkgY2FuIGVhc2lseSBtYWtlIGlvcmVtYXBfbm9wb3N0KCkgbWlycm9yIGlvcmVtYXBf
dWMoKSAoaWUgcmV0dXJuCj4gTlVMTCB1bmxlc3Mgb3ZlcnJpZGVuIHNvIHRoYXQgYmFzaWNhbGx5
IHlvdSBjYW4ndCB1c2UgaW4gb24gYW4gYXJjaAo+IHRoYXQgY2FuJ3QgcHJvdmlkZSBpdHMgc2Vt
YW50aWNzKSBidXQgdGhlbiB0aGF0IGJlY29tZXMgdmVyeSB3cm9uZwo+IGZvciBvdGhlciByZXZp
ZXdlcnMuCgpUaG9zZSByZXZpZXdlcnMgYXJlIFdST05HIDotKQoKPiBodHRwczovL2xrbWwub3Jn
L2xrbWwvMjAxNy80LzYvMzk2Cj4gCj4gPiBXaGF0IGV4YWN0bHkgYXJlIHlvdSB0cnlpbmcgdG8g
Zml4IGhlcmUgPwo+IAo+IEkgd3JvdGUgaW4gdGhlIGNvbW1pdCBsb2dzIGFuZCBjb3ZlciBsZXR0
ZXIgd2hhdCBJIGFtIGZpeGluZyBoZXJlLgoKUmlnaHQgcmlnaHQsIHdoYXQgKmFjdHVhbCBidWcg
eW91IGhhdmUgb2JzZXJ2ZWQqIGFyZSB5b3UgdHJ5aW5nIHRvIGZpeAo/CgpJJ20gcHJldHR5IHN1
Y2ggY2xvc2UgdG8gYWxsIG5vbi14ODYgYXJjaHMgaGFkIHRoYXQgInByb2JsZW0iIHNpbmNlIHRo
ZQpkYXduIG9mIHRpbWUgYW5kIGl0IGhhcyBuZXZlciBodXJ0IGFueWJvZHkuCgpUaGF0IHNhaWQs
IEkgZG9uJ3QgdGhpbmsgaXQgbWFrZXMgc2Vuc2UgdG8gInNvbHZlIiBpdCBieSBjcmVhdGluZyBh
CiJnZW5lcmljIiBtYXBwaW5nIHNlbWFudGljIHRoYXQgaXMgYmFzaWNhbGx5IGltcG9zc2libGUg
dG8gaW1wbGVtZW50IG9uCm1vc3QgYXJjaGl0ZWN0dXJlcyBvdXQgdGhlcmUgKGFuZCBjYW5ub3Qg
YmUgZW11bGF0ZWQpLgoKVGhpcyBpcyBhIHByb2JsZW0gdG8gYmUgc29sdmVkIGJ5IHRoZSBicmlk
Z2UgaXRzZWxmLiBJZiBBUk0gaGFzIGEKbWFwcGluZyBhdHRyaWJ1dGUgdG8gbWFrZSBzdG9yZXMg
bm9uLXBvc3RlZCwga2VlcCB0aGlzIGFuIEFSTSBzcGVjaWZpYwphdHRyaWJ1dGUgYXQgdGhpcyBz
dGFnZSBJJ2Qgc2F5LgoKPiBBbnl3YXk6Cj4gCj4gIlRoZSBQQ0kgc3BlY2lmaWNhdGlvbnMgKFJl
diAzLjAsIDMuMi41ICJUcmFuc2FjdGlvbiBPcmRlcmluZyBhbmQKPiBQb3N0aW5nIikgbWFuZGF0
ZSBub24tcG9zdGVkIGNvbmZpZ3VyYXRpb24gdHJhbnNhY3Rpb25zLiBBcyBmdXJ0aGVyCj4gaGln
aGxpZ2h0ZWQgaW4gdGhlIFBDSWUgc3BlY2lmaWNhdGlvbnMgKDQuMCAtIFJldjAuMywgIk9yZGVy
aW5nCj4gQ29uc2lkZXJhdGlvbnMgZm9yIHRoZSBFbmhhbmNlZCBDb25maWd1cmF0aW9uIEFjY2Vz
cyBNZWNoYW5pc20iKSwKPiB0aHJvdWdoIEVDQU0gYW5kIEVDQU0tZGVyaXZhdGl2ZSBjb25maWd1
cmF0aW9uIG1lY2hhbmlzbSwgdGhlIG1lbW9yeQo+IG1hcHBlZCB0cmFuc2FjdGlvbnMgZnJvbSB0
aGUgaG9zdCBDUFUgaW50byBDb25maWd1cmF0aW9uIFJlcXVlc3RzIG9uIHRoZQo+IFBDSSBleHBy
ZXNzIGZhYnJpYyBtYXkgY3JlYXRlIG9yZGVyaW5nIHByb2JsZW1zIGZvciBzb2Z0d2FyZSBiZWNh
dXNlCj4gd3JpdGVzIHRvIG1lbW9yeSBhZGRyZXNzIGFyZSB0eXBpY2FsbHkgcG9zdGVkIHRyYW5z
YWN0aW9ucyAodW5sZXNzIHRoZQo+IGFyY2hpdGVjdHVyZSBjYW4gZW5mb3JjZSB0aHJvdWdoIHZp
cnR1YWwgYWRkcmVzcyBtYXBwaW5nIG5vbi1wb3N0ZWQKPiB3cml0ZSB0cmFuc2FjdGlvbnMgYmVo
YXZpb3VyKSBidXQgd3JpdGVzIHRvIENvbmZpZ3VyYXRpb24gU3BhY2UgYXJlIG5vdAo+IHBvc3Rl
ZCBvbiB0aGUgUENJIGV4cHJlc3MgZmFicmljLiIKPiAKPiBPbiBBUk02NDoKPiAKPiAiVGhpcyBy
dWxlIGlzIHJlaW5mb3JjZWQgYnkgdGhlIEFSTSB2OCBhcmNoaXRlY3R1cmUgcmVmZXJlbmNlIG1h
bnVhbAo+IChpc3N1ZSBBLmssIEVhcmx5IFdyaXRlIEFja25vd2xlZGdtZW50KSB0aGF0IGV4cGxp
Y2l0bHkgcmVjb21tZW5kcwo+IHRoYXQgTm8gRWFybHkgV3JpdGUgQWNrbm93bGVkZ21lbnQgYXR0
cmlidXRlIHNob3VsZCBiZSB1c2VkIHRvIG1hcAo+IFBDSSBjb25maWd1cmF0aW9uICh3cml0ZSkg
dHJhbnNhY3Rpb25zLiIKPiAKPiA+IElmIGEgZ2l2ZW4gUENJZSBob3N0IGJyaWRnZSAoYXJjaGl0
ZWN0dXJlIHNwZWNpZmljKSByZXF1aXJlIGEgc3BlY2lhbAo+ID4gc2F1Y2UgdG8gcHJvdmlkZSB0
aGUgaWxsdXNpb24gb2Ygbm9uLXBvc3RpbmcsIHRoZW4gaW1wbGVtZW50IHRoaXMgaW4KPiA+IHRo
ZSBhY3R1YWwgcm9vdCBjb21wbGV4IGNvZGUuCj4gPiAKPiA+IEJUVy4gSSdtIHByZXR0eSBzdXJl
IHdlICJhY2NpZGVudGFsbHkiIG1hZGUgY29uZmlnIHdyaXRlcyBwb3N0ZWQgYXQKPiA+IGxlYXN0
IHRvIHRoZSBQSEIgb24gYSBudW1iZXIgb2YgcG93ZXJwYyBzeXN0ZW1zIGZvcmV2ZXIgYW5kIHdl
ICpuZXZlcioKPiA+IGhhZCBhIHByb2JsZW0gYmVjYXVzZSBvZiBpdCA7KQo+IAo+IE9rIHNvIHdl
IHNob3VsZCBpZ25vcmUgdGhlIFBDSWUgc3BlY2lmaWNhdGlvbnMgYW5kIEFSTSB2OCByZWZlcmVu
Y2UKPiBtYW51YWwgd2FpdGluZyBmb3IgYSBrZXJuZWwgYnVnIHRvIGFwcGVhciA/IElzIHRoYXQg
d2hhdCB5b3Ugc3VnZ2VzdAo+IGRvaW5nID8KPiAKPiBMb3JlbnpvCj4gCj4gPiA+IHYyIC0+IHYz
Ogo+ID4gPiAJLSBDcmVhdGVkIGEgZGVmYXVsdCBpb3JlbWFwX25vcG9zdCgpIGltcGxlbWVudGF0
aW9uIGluIGEKPiA+ID4gc2VwYXJhdGUKPiA+ID4gCcKgwqBhc20tZ2VuZXJpYyBoZWFkZXIgYW5k
IHBhdGNoZWQgYWxsIGFyY2hlcyB0byBtYWtlIHVzZSBvZiBpdAo+ID4gPiAJLSBSZW1vdmVkIFBD
SSBkcml2ZXJzIHBhdGNoZXMgZnJvbSB0aGUgc2VyaWVzIHRvIHNpbXBsaWZ5IHRoZQo+ID4gPiAJ
wqDCoHJldmlldywgdGhleSB3aWxsIGJlIHBvc3RlZCBzZXBhcmF0ZWx5IG9uY2UgdGhlCj4gPiA+
IGlvcmVtYXBfbm9wb3N0KCkKPiA+ID4gCcKgwqBpbnRlcmZhY2UgaXMgc2V0dGxlZAo+ID4gPiAJ
LSBGaXhlZCBkZXZtX2lvcmVtYXBfKiBCVVMgb2Zmc2V0IGNvbW1lbnRzIGFuZCBpbXBsZW1lbnRl
ZAo+ID4gPiAJwqDCoG5vcG9zdCBpbnRlcmZhY2Ugb24gdG9wIG9mIGl0Cj4gPiA+IAktIEFkZGVk
IGNvbGxlY3RlZCB0YWdzCj4gPiA+IAo+ID4gPiB2MTogaHR0cHM6Ly9sa21sLm9yZy9sa21sLzIw
MTcvMi8yNy8yMjgKPiA+ID4gCj4gPiA+IHYxIC0+IHYyOgo+ID4gPiAJLSBDaGFuZ2VkIHBjaV9y
ZW1hcF9jZmdzcGFjZSgpIHRvIG1vcmUgZ2VuZXJpYyBpb3JlbWFwX25vcG9zdCgpCj4gPiA+IAnC
oMKgaW50ZXJmYWNlCj4gPiA+IAktIEFkZGVkIHBncHJvdF9ub25wb3N0ZWQKPiA+ID4gCS0gRml4
ZWQgYnVpbGQgZXJyb3JzIG9uIGFyY2hlcyBub3QgcmVseWluZyBvbiBhc20tZ2VuZXJpYwo+ID4g
PiBoZWFkZXJzCj4gPiA+IAktIEFkZGVkIFBDSSB2ZXJzYXRpbGUgaG9zdCBjb250cm9sbGVyIGRy
aXZlciBwYXRjaAo+ID4gPiAJLSBBZGRlZCBtaXNzaW5nIGNvbmZpZyBzcGFjZSByZW1hcHBpbmcg
dG8gaGlzaWxpY29uIGhvc3QKPiA+ID4gY29udHJvbGxlcgo+ID4gPiAKPiA+ID4gLS0tLS0tLS0t
LS0tLS0tLS0tLS0tCj4gPiA+IE9yaWdpbmFsIGNvdmVyIGxldHRlcgo+ID4gPiAtLS0tLS0tLS0t
LS0tLS0tLS0tLS0KPiA+ID4gCj4gPiA+IFBDSSBsb2NhbCBidXMgc3BlY2lmaWNhdGlvbnMgKFJl
djMuMCwgMy4yLjUgIlRyYW5zYWN0aW9uIE9yZGVyaW5nCj4gPiA+IGFuZCBQb3N0aW5nIikgc3Ry
aWN0bHkgcmVxdWlyZSBQQ0kgY29uZmlndXJhdGlvbiBhbmQgSS9PIEFkZHJlc3MKPiA+ID4gc3Bh
Y2UKPiA+ID4gd3JpdGUgdHJhbnNhY3Rpb25zIHRvIGJlIG5vbi1wb3N0ZWQuCj4gPiA+IAo+ID4g
PiBDdXJyZW50IGNyb3Agb2YgRFQvQUNQSSBQQ0kgaG9zdCBjb250cm9sbGVycyBkcml2ZXJzIHJl
bGllcyBvbgo+ID4gPiB0aGUgaW9yZW1hcCBpbnRlcmZhY2UgdG8gbWFwIEVDQU0gYW5kIEVDQU0t
ZGVyaXZhdGl2ZSBQQ0kgY29uZmlnCj4gPiA+IHJlZ2lvbnMgYW5kIHBjaV9yZW1hcF9pb3NwYWNl
KCkgdG8gY3JlYXRlIGEgVk1BIGZvciBtYXBwaW5nCj4gPiA+IFBDSSBob3N0IGJyaWRnZSBJL08g
QWRkcmVzcyBzcGFjZSB0cmFuc2FjdGlvbnMgdG8gQ1BVIHZpcnR1YWwgYWRkcmVzcwo+ID4gPiBz
cGFjZS4KPiA+ID4gCj4gPiA+IE9uIHNvbWUgcGxhdGZvcm1zIChpZSBBUk0vQVJNNjQpIGlvcmVt
YXAgZmFpbHMgdG8gY29tcGx5IHdpdGggdGhlIFBDSQo+ID4gPiBjb25maWd1cmF0aW9uIG5vbi1w
b3N0ZWQgd3JpdGUgdHJhbnNhY3Rpb25zIHJlcXVpcmVtZW50LCBiZWNhdXNlIGl0Cj4gPiA+IHBy
b3ZpZGVzIGEgbWVtb3J5IG1hcHBpbmcgdGhhdCBpc3N1ZXMgImJ1ZmZlcmFibGUiIG9yLCBpbiBQ
Q0kgdGVybXMKPiA+ID4gInBvc3RlZCIgd3JpdGUgdHJhbnNhY3Rpb25zLiBMaWtld2lzZSwgdGhl
IGN1cnJlbnQKPiA+ID4gcGNpX3JlbWFwX2lvc3BhY2UoKQo+ID4gPiBpbXBsZW1lbnRhdGlvbiBt
YXBzIHRoZSBwaHlzaWNhbCBhZGRyZXNzIHJhbmdlIHRoYXQgdGhlIFBDSQo+ID4gPiB0cmFuc2xh
dGVzCj4gPiA+IHRvIEkvTyBzcGFjZSBjeWNsZXMgdG8gdmlydHVhbCBhZGRyZXNzIHNwYWNlIHRo
cm91Z2ggcGdwcm90X2RldmljZSgpCj4gPiA+IGF0dHJpYnV0ZXMgdGhhdCBvbiBlZyBBUk02NCBw
cm92aWRlcyBhIG1lbW9yeSBtYXBwaW5nIGlzc3VpbmcKPiA+ID4gcG9zdGVkIHdyaXRlcyB0cmFu
c2FjdGlvbnMsIHdoaWNoIGlzIG5vdCBQQ0kgc3BlY2lmaWNhdGlvbnMKPiA+ID4gY29tcGxpYW50
Lgo+ID4gPiAKPiA+ID4gVGhpcyBwYXRjaCBzZXJpZXNbMV0gYWRkcmVzc2VzIGJvdGggaXNzdWVz
IGluIG9uZSBnbzoKPiA+ID4gCj4gPiA+IC0gSXQgdXBkYXRlcyB0aGUgcGNpX3JlbWFwX2lvc3Bh
Y2UoKSBmdW5jdGlvbiB0byB1c2UgYSBwYWdlIG1hcHBpbmcKPiA+ID4gwqAgdGhhdCBndWFyYW50
ZWVzIG5vbi1wb3N0ZWQgd3JpdGUgdHJhbnNhY3Rpb25zIGZvciBJL08gc3BhY2UKPiA+ID4gYWRk
cmVzc2VzCj4gPiA+IC0gSXQgYWRkcyBhIGtlcm5lbCBBUEkgdG8gcmVtYXAgUENJIGNvbmZpZyBz
cGFjZSByZXNvdXJjZXMsIHNvIHRoYXQKPiA+ID4gwqAgYXJjaGl0ZWN0dXJlIGNhbiBvdmVycmlk
ZSBpdCB3aXRoIGEgbWFwcGluZyBpbXBsZW1lbnRhdGlvbiB0aGF0Cj4gPiA+IMKgIGd1YXJhbnRl
ZXMgUENJIHNwZWNpZmljYXRpb25zIGNvbXBsaWFuY3kgd3J0IG5vbi1wb3N0ZWQgd3JpdGUKPiA+
ID4gwqAgY29uZmlndXJhdGlvbiB0cmFuc2FjdGlvbnMKPiA+ID4gLSBJdCB1cGRhdGVzIGFsbCBQ
Q0kgaG9zdCBjb250cm9sbGVyIGltcGxlbWVudGF0aW9ucyAoYW5kIHRoZSBnZW5lcmljCj4gPiA+
IMKgIEVDQU0gbGF5ZXIpIHRvIHVzZSB0aGUgbmV3bHkgaW50cm9kdWNlZCBtYXBwaW5nIGludGVy
ZmFjZQo+ID4gPiAKPiA+ID4gVGVzdGVkIG9uIEp1bm8gRUNBTSBiYXNlZCBpbnRlcmZhY2UgKERU
L0FDUEkpLgo+ID4gPiAKPiA+ID4gTm9uLUVDQU0gUENJIGhvc3QgY29udHJvbGxlciBkcml2ZXJz
IHBhdGNoZXMgbmVlZCBjaGVja2luZyB0byBtYWtlCj4gPiA+IHN1cmUgdGhhdDoKPiA+ID4gCj4g
PiA+IC0gSSBwYXRjaGVkIHRoZSBjb3JyZWN0IHJlc291cmNlIHJlZ2lvbiBtYXBwaW5nIGZvciBj
b25maWcgc3BhY2UKPiA+ID4gLSBUaGVyZSBhcmUgbm90IGFueSBvdGhlciB3YXlzIHRvIGVuc3Vy
ZSBwb3N0ZWQtd3JpdGUgY29tcGxldGlvbgo+ID4gPiDCoCBpbiB0aGUgcmVzcGVjdGl2ZSBwY2lf
b3BzIHRoYXQgbWFrZSB0aGUgcmVsZXZhbnQgcGF0Y2ggdW5uZWNlc3NhcnkKPiA+ID4gCj4gPiA+
IFsxXQo+ID4gPiBnaXQ6Ly9naXQua2VybmVsLm9yZy9wdWIvc2NtL2xpbnV4L2tlcm5lbC9naXQv
bHBpZXJhbGlzaS9saW51eC5naXQKPiA+ID4gcGNpL2NvbmZpZy1pby1tYXBwaW5ncy1maXgtdjMK
PiA+ID4gCj4gPiA+IExvcmVuem8gUGllcmFsaXNpICgzMik6Cj4gPiA+IMKgIFBDSTogcmVtb3Zl
IF9fd2VhayB0YWcgZnJvbSBwY2lfcmVtYXBfaW9zcGFjZSgpCj4gPiA+IMKgIGFzbS1nZW5lcmlj
L3BndGFibGUuaDogaW50cm9kdWNlIHBncHJvdF9ub25wb3N0ZWQgcmVtYXAgYXR0cmlidXRlCj4g
PiA+IMKgIFBDSTogZml4IHBjaV9yZW1hcF9pb3NwYWNlKCkgcmVtYXAgYXR0cmlidXRlCj4gPiA+
IMKgIGFzbS1nZW5lcmljOiBhZGQgaW9yZW1hcF9ub3Bvc3QoKSByZW1hcCBpbnRlcmZhY2UKPiA+
ID4gwqAgYWxwaGE6IGluY2x1ZGUgZGVmYXVsdCBpb3JlbWFwX25vcG9zdCgpIGltcGxlbWVudGF0
aW9uCj4gPiA+IMKgIGF2cjMyOiBpbmNsdWRlIGRlZmF1bHQgaW9yZW1hcF9ub3Bvc3QoKSBpbXBs
ZW1lbnRhdGlvbgo+ID4gPiDCoCBhcmM6IGluY2x1ZGUgZGVmYXVsdCBpb3JlbWFwX25vcG9zdCgp
IGltcGxlbWVudGF0aW9uCj4gPiA+IMKgIGNyaXM6IGluY2x1ZGUgZGVmYXVsdCBpb3JlbWFwX25v
cG9zdCgpIGltcGxlbWVudGF0aW9uCj4gPiA+IMKgIGZydjogaW5jbHVkZSBkZWZhdWx0IGlvcmVt
YXBfbm9wb3N0KCkgaW1wbGVtZW50YXRpb24KPiA+ID4gwqAgaGV4YWdvbjogaW5jbHVkZSBkZWZh
dWx0IGlvcmVtYXBfbm9wb3N0KCkgaW1wbGVtZW50YXRpb24KPiA+ID4gwqAgaWE2NDogaW5jbHVk
ZSBkZWZhdWx0IGlvcmVtYXBfbm9wb3N0KCkgaW1wbGVtZW50YXRpb24KPiA+ID4gwqAgbTMycjog
aW5jbHVkZSBkZWZhdWx0IGlvcmVtYXBfbm9wb3N0KCkgaW1wbGVtZW50YXRpb24KPiA+ID4gwqAg
bTY4azogaW5jbHVkZSBkZWZhdWx0IGlvcmVtYXBfbm9wb3N0KCkgaW1wbGVtZW50YXRpb24KPiA+
ID4gwqAgbWV0YWc6IGluY2x1ZGUgZGVmYXVsdCBpb3JlbWFwX25vcG9zdCgpIGltcGxlbWVudGF0
aW9uCj4gPiA+IMKgIG1pY3JvYmxhemU6IGluY2x1ZGUgZGVmYXVsdCBpb3JlbWFwX25vcG9zdCgp
IGltcGxlbWVudGF0aW9uCj4gPiA+IMKgIG1pcHM6IGluY2x1ZGUgZGVmYXVsdCBpb3JlbWFwX25v
cG9zdCgpIGltcGxlbWVudGF0aW9uCj4gPiA+IMKgIG1uMTAzMDA6IGluY2x1ZGUgZGVmYXVsdCBp
b3JlbWFwX25vcG9zdCgpIGltcGxlbWVudGF0aW9uCj4gPiA+IMKgIG5pb3MyOiBpbmNsdWRlIGRl
ZmF1bHQgaW9yZW1hcF9ub3Bvc3QoKSBpbXBsZW1lbnRhdGlvbgo+ID4gPiDCoCBvcGVucmlzYzog
aW5jbHVkZSBkZWZhdWx0IGlvcmVtYXBfbm9wb3N0KCkgaW1wbGVtZW50YXRpb24KPiA+ID4gwqAg
cGFyaXNjOiBpbmNsdWRlIGRlZmF1bHQgaW9yZW1hcF9ub3Bvc3QoKSBpbXBsZW1lbnRhdGlvbgo+
ID4gPiDCoCBwb3dlcnBjOiBpbmNsdWRlIGRlZmF1bHQgaW9yZW1hcF9ub3Bvc3QoKSBpbXBsZW1l
bnRhdGlvbgo+ID4gPiDCoCBzMzkwOiBpbmNsdWRlIGRlZmF1bHQgaW9yZW1hcF9ub3Bvc3QoKSBp
bXBsZW1lbnRhdGlvbgo+ID4gPiDCoCBzaDogaW5jbHVkZSBkZWZhdWx0IGlvcmVtYXBfbm9wb3N0
KCkgaW1wbGVtZW50YXRpb24KPiA+ID4gwqAgc3BhcmM6IGluY2x1ZGUgZGVmYXVsdCBpb3JlbWFw
X25vcG9zdCgpIGltcGxlbWVudGF0aW9uCj4gPiA+IMKgIHRpbGU6IGluY2x1ZGUgZGVmYXVsdCBp
b3JlbWFwX25vcG9zdCgpIGltcGxlbWVudGF0aW9uCj4gPiA+IMKgIHVuaWNvcmUzMjogaW5jbHVk
ZSBkZWZhdWx0IGlvcmVtYXBfbm9wb3N0KCkgaW1wbGVtZW50YXRpb24KPiA+ID4gwqAgeDg2OiBp
bmNsdWRlIGRlZmF1bHQgaW9yZW1hcF9ub3Bvc3QoKSBpbXBsZW1lbnRhdGlvbgo+ID4gPiDCoCB4
dGVuc2E6IGluY2x1ZGUgZGVmYXVsdCBpb3JlbWFwX25vcG9zdCgpIGltcGxlbWVudGF0aW9uCj4g
PiA+IMKgIGFybTY0OiBpbXBsZW1lbnQgaW9yZW1hcF9ub3Bvc3QoKSBpbnRlcmZhY2UKPiA+ID4g
wqAgYXJtOiBpbXBsZW1lbnQgaW9yZW1hcF9ub3Bvc3QoKSBpbnRlcmZhY2UKPiA+ID4gwqAgbGli
OiBmaXggRGV2cmVzIGRldm1faW9yZW1hcF8qIG9mZnNldCBwYXJhbWV0ZXIga2VybmVsZG9jCj4g
PiA+IGRlc2NyaXB0aW9uCj4gPiA+IMKgIGxpYjogaW1wbGVtZW50IERldnJlcyBpb3JlbWFwX25v
cG9zdCgpIGludGVyZmFjZQo+ID4gPiAKPiA+ID4gwqBEb2N1bWVudGF0aW9uL2RyaXZlci1tb2Rl
bC9kZXZyZXMudHh0IHzCoMKgMyArKwo+ID4gPiDCoGFyY2gvYWxwaGEvaW5jbHVkZS9hc20vaW8u
aMKgwqDCoMKgwqDCoMKgwqDCoMKgwqB8wqDCoDEgKwo+ID4gPiDCoGFyY2gvYXJjL2luY2x1ZGUv
YXNtL2lvLmjCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoHzCoMKgMSArCj4gPiA+IMKgYXJjaC9h
cm0vaW5jbHVkZS9hc20vaW8uaMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgfMKgwqA5ICsrKysK
PiA+ID4gwqBhcmNoL2FybS9tbS9pb3JlbWFwLmPCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg
wqDCoMKgfMKgwqA3ICsrKwo+ID4gPiDCoGFyY2gvYXJtL21tL25vbW11LmPCoMKgwqDCoMKgwqDC
oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoHzCoMKgOSArKysrCj4gPiA+IMKgYXJjaC9hcm02NC9p
bmNsdWRlL2FzbS9pby5owqDCoMKgwqDCoMKgwqDCoMKgwqDCoHwgMTIgKysrKysKPiA+ID4gwqBh
cmNoL2F2cjMyL2luY2x1ZGUvYXNtL2lvLmjCoMKgwqDCoMKgwqDCoMKgwqDCoMKgfMKgwqAxICsK
PiA+ID4gwqBhcmNoL2NyaXMvaW5jbHVkZS9hc20vaW8uaMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC
oHzCoMKgMSArCj4gPiA+IMKgYXJjaC9mcnYvaW5jbHVkZS9hc20vaW8uaMKgwqDCoMKgwqDCoMKg
wqDCoMKgwqDCoMKgfMKgwqAxICsKPiA+ID4gwqBhcmNoL2hleGFnb24vaW5jbHVkZS9hc20vaW8u
aMKgwqDCoMKgwqDCoMKgwqDCoHzCoMKgMiArCj4gPiA+IMKgYXJjaC9pYTY0L2luY2x1ZGUvYXNt
L2lvLmjCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqB8wqDCoDEgKwo+ID4gPiDCoGFyY2gvbTMyci9p
bmNsdWRlL2FzbS9pby5owqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgfMKgwqAxICsKPiA+ID4gwqBh
cmNoL202OGsvaW5jbHVkZS9hc20vaW8uaMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoHzCoMKgMSAr
Cj4gPiA+IMKgYXJjaC9tZXRhZy9pbmNsdWRlL2FzbS9pby5owqDCoMKgwqDCoMKgwqDCoMKgwqDC
oHzCoMKgMiArCj4gPiA+IMKgYXJjaC9taWNyb2JsYXplL2luY2x1ZGUvYXNtL2lvLmjCoMKgwqDC
oMKgwqB8wqDCoDEgKwo+ID4gPiDCoGFyY2gvbWlwcy9pbmNsdWRlL2FzbS9pby5owqDCoMKgwqDC
oMKgwqDCoMKgwqDCoMKgfMKgwqAxICsKPiA+ID4gwqBhcmNoL21uMTAzMDAvaW5jbHVkZS9hc20v
aW8uaMKgwqDCoMKgwqDCoMKgwqDCoHzCoMKgMSArCj4gPiA+IMKgYXJjaC9uaW9zMi9pbmNsdWRl
L2FzbS9pby5owqDCoMKgwqDCoMKgwqDCoMKgwqDCoHzCoMKgMSArCj4gPiA+IMKgYXJjaC9vcGVu
cmlzYy9pbmNsdWRlL2FzbS9pby5owqDCoMKgwqDCoMKgwqDCoHzCoMKgMiArCj4gPiA+IMKgYXJj
aC9wYXJpc2MvaW5jbHVkZS9hc20vaW8uaMKgwqDCoMKgwqDCoMKgwqDCoMKgfMKgwqAxICsKPiA+
ID4gwqBhcmNoL3Bvd2VycGMvaW5jbHVkZS9hc20vaW8uaMKgwqDCoMKgwqDCoMKgwqDCoHzCoMKg
MSArCj4gPiA+IMKgYXJjaC9zMzkwL2luY2x1ZGUvYXNtL2lvLmjCoMKgwqDCoMKgwqDCoMKgwqDC
oMKgwqB8wqDCoDEgKwo+ID4gPiDCoGFyY2gvc2gvaW5jbHVkZS9hc20vaW8uaMKgwqDCoMKgwqDC
oMKgwqDCoMKgwqDCoMKgwqB8wqDCoDEgKwo+ID4gPiDCoGFyY2gvc3BhcmMvaW5jbHVkZS9hc20v
aW8uaMKgwqDCoMKgwqDCoMKgwqDCoMKgwqB8wqDCoDEgKwo+ID4gPiDCoGFyY2gvdGlsZS9pbmNs
dWRlL2FzbS9pby5owqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgfMKgwqAxICsKPiA+ID4gwqBhcmNo
L3VuaWNvcmUzMi9pbmNsdWRlL2FzbS9pby5owqDCoMKgwqDCoMKgwqB8wqDCoDEgKwo+ID4gPiDC
oGFyY2gveDg2L2luY2x1ZGUvYXNtL2lvLmjCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoHzCoMKg
MSArCj4gPiA+IMKgYXJjaC94dGVuc2EvaW5jbHVkZS9hc20vaW8uaMKgwqDCoMKgwqDCoMKgwqDC
oMKgfMKgwqAxICsKPiA+ID4gwqBkcml2ZXJzL3BjaS9wY2kuY8KgwqDCoMKgwqDCoMKgwqDCoMKg
wqDCoMKgwqDCoMKgwqDCoMKgwqDCoHzCoMKgNCArLQo+ID4gPiDCoGluY2x1ZGUvYXNtLWdlbmVy
aWMvaW9yZW1hcC1ub3Bvc3QuaMKgwqB8wqDCoDkgKysrKwo+ID4gPiDCoGluY2x1ZGUvYXNtLWdl
bmVyaWMvcGd0YWJsZS5owqDCoMKgwqDCoMKgwqDCoMKgfMKgwqA0ICsrCj4gPiA+IMKgaW5jbHVk
ZS9saW51eC9kZXZpY2UuaMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgfMKgwqAyICsK
PiA+ID4gwqBpbmNsdWRlL2xpbnV4L2lvLmjCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC
oMKgwqDCoMKgfMKgwqAyICsKPiA+ID4gwqBsaWIvZGV2cmVzLmPCoMKgwqDCoMKgwqDCoMKgwqDC
oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgfCA4NAo+ID4gPiArKysrKysrKysrKysr
KysrKysrKysrKysrKysrKysrKystLQo+ID4gPiDCoDM1IGZpbGVzIGNoYW5nZWQsIDE2NyBpbnNl
cnRpb25zKCspLCA1IGRlbGV0aW9ucygtKQo+ID4gPiDCoGNyZWF0ZSBtb2RlIDEwMDY0NCBpbmNs
dWRlL2FzbS1nZW5lcmljL2lvcmVtYXAtbm9wb3N0LmgKPiA+ID4gCgpfX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpsaW51eC1hcm0ta2VybmVsIG1haWxpbmcg
bGlzdApsaW51eC1hcm0ta2VybmVsQGxpc3RzLmluZnJhZGVhZC5vcmcKaHR0cDovL2xpc3RzLmlu
ZnJhZGVhZC5vcmcvbWFpbG1hbi9saXN0aW5mby9saW51eC1hcm0ta2VybmVsCg==
^ permalink raw reply [flat|nested] 171+ messages in thread
* [PATCH v3 00/32] PCI: fix config and I/O Address space memory mappings
@ 2017-04-11 23:12 ` Benjamin Herrenschmidt
0 siblings, 0 replies; 171+ messages in thread
From: Benjamin Herrenschmidt @ 2017-04-11 23:12 UTC (permalink / raw)
To: linux-arm-kernel
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 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'm pretty such close to all non-x86 archs had that "problem" since the
dawn of time and it has never hurt anybody.
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.
> 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
> > >
^ permalink raw reply [flat|nested] 171+ messages in thread
* Re: [PATCH v3 00/32] PCI: fix config and I/O Address space memory mappings
@ 2017-04-11 23:12 ` Benjamin Herrenschmidt
0 siblings, 0 replies; 171+ messages in thread
From: Benjamin Herrenschmidt @ 2017-04-11 23:12 UTC (permalink / raw)
To: Lorenzo Pieralisi
Cc: Jonas Bonn, Rich Felker, linux-pci, Will Deacon,
James E.J. Bottomley, David Howells, Max Filippov,
Paul Mackerras, Huacai Chen, Guan Xuetao, Thomas Gleixner,
Hans-Christian Egtvedt, linux-arch, Jesper Nilsson,
Yoshinori Sato, Michael Ellerman, Helge Deller, Russell King,
Ingo Molnar, Geert Uytterhoeven, Catalin Marinas, Matt Turner,
Haavard Skinnemoen, Fenghua Yu
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 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'm pretty such close to all non-x86 archs had that "problem" since the
dawn of time and it has never hurt anybody.
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.
> 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
> > >
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 171+ messages in thread
* Re: [PATCH v3 00/32] PCI: fix config and I/O Address space memory mappings
2017-04-11 23:12 ` Benjamin Herrenschmidt
(?)
@ 2017-04-12 9:44 ` Lorenzo Pieralisi
-1 siblings, 0 replies; 171+ messages in thread
From: Lorenzo Pieralisi @ 2017-04-12 9:44 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Jonas Bonn, Rich Felker, linux-pci, Will Deacon,
James E.J. Bottomley, David Howells, Max Filippov,
Paul Mackerras, Huacai Chen, Guan Xuetao, Thomas Gleixner,
Hans-Christian Egtvedt, linux-arch, Jesper Nilsson,
Yoshinori Sato, Michael Ellerman, Helge Deller, Russell King,
Ingo Molnar, Geert Uytterhoeven, Catalin Marinas, Matt Turner,
Haavard Skinnemoen, Fenghua Yu, James Hogan, Chris Metcalf,
Arnd Bergmann, Heiko Carstens, Stefan Kristiansson,
Mikael Starvik, Ivan Kokshaysky, Bjorn Helgaas, Stafford Horne,
linux-arm-kernel, Richard Henderson, Chris Zankel, Michal Simek,
Tony Luck, Vineet Gupta, linux-kernel, Ralf Baechle, Richard Kuo,
Niklas Cassel, Luis R. Rodriguez, Martin Schwidefsky,
Ley Foon Tan, David S. Miller
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
^ permalink raw reply [flat|nested] 171+ messages in thread
* [PATCH v3 00/32] PCI: fix config and I/O Address space memory mappings
@ 2017-04-12 9:44 ` Lorenzo Pieralisi
0 siblings, 0 replies; 171+ messages in thread
From: Lorenzo Pieralisi @ 2017-04-12 9:44 UTC (permalink / raw)
To: linux-arm-kernel
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
> > > >
^ permalink raw reply [flat|nested] 171+ messages in thread
* Re: [PATCH v3 00/32] PCI: fix config and I/O Address space memory mappings
@ 2017-04-12 9:44 ` Lorenzo Pieralisi
0 siblings, 0 replies; 171+ messages in thread
From: Lorenzo Pieralisi @ 2017-04-12 9:44 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Jonas Bonn, Rich Felker, linux-pci, Will Deacon,
James E.J. Bottomley, David Howells, Max Filippov,
Paul Mackerras, Huacai Chen, Guan Xuetao, Thomas Gleixner,
Hans-Christian Egtvedt, linux-arch, Jesper Nilsson,
Yoshinori Sato, Michael Ellerman, Helge Deller, Russell King,
Ingo Molnar, Geert Uytterhoeven, Catalin Marinas, Matt Turner,
Haavard Skinnemoen, Fenghua Yu
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
> > > >
^ permalink raw reply [flat|nested] 171+ messages in thread
* Re: [PATCH v3 00/32] PCI: fix config and I/O Address space memory mappings
2017-04-12 9:44 ` Lorenzo Pieralisi
(?)
@ 2017-04-12 13:48 ` Benjamin Herrenschmidt
-1 siblings, 0 replies; 171+ messages in thread
From: Benjamin Herrenschmidt @ 2017-04-12 13:48 UTC (permalink / raw)
To: Lorenzo Pieralisi
Cc: Jonas Bonn, Rich Felker, linux-pci, Will Deacon,
James E.J. Bottomley, David Howells, Max Filippov,
Paul Mackerras, Huacai Chen, Guan Xuetao, Thomas Gleixner,
Hans-Christian Egtvedt, linux-arch, Jesper Nilsson,
Yoshinori Sato, Michael Ellerman, Helge Deller, Russell King,
Ingo Molnar, Geert Uytterhoeven, Catalin Marinas, Matt Turner,
Haavard Skinnemoen, Fenghua Yu, James Hogan, Chris Metcalf,
Arnd Bergmann, Heiko Carstens, Stefan Kristiansson,
Mikael Starvik, Ivan Kokshaysky, Bjorn Helgaas, Stafford Horne,
linux-arm-kernel, Richard Henderson, Chris Zankel, Michal Simek,
Tony Luck, Vineet Gupta, linux-kernel, Ralf Baechle, Richard Kuo,
Niklas Cassel, Luis R. Rodriguez, Martin Schwidefsky,
Ley Foon Tan, David S. Miller
On Wed, 2017-04-12 at 10:44 +0100, Lorenzo Pieralisi wrote:
> > 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).
Then provide some kind of HAVE_* or config option indicating that this
mapping attribute exist so the bridge code at least has the option of
implementing an "alternative" mechanism when it doesn't rather than
silently being wrong :-)
(Or just return NULL, that works too)
Cheers,
Ben.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 171+ messages in thread
* [PATCH v3 00/32] PCI: fix config and I/O Address space memory mappings
@ 2017-04-12 13:48 ` Benjamin Herrenschmidt
0 siblings, 0 replies; 171+ messages in thread
From: Benjamin Herrenschmidt @ 2017-04-12 13:48 UTC (permalink / raw)
To: linux-arm-kernel
On Wed, 2017-04-12 at 10:44 +0100, Lorenzo Pieralisi wrote:
> > 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).
Then provide some kind of HAVE_* or config option indicating that this
mapping attribute exist so the bridge code at least has the option of
implementing an "alternative" mechanism when it doesn't rather than
silently being wrong :-)
(Or just return NULL, that works too)
Cheers,
Ben.
^ permalink raw reply [flat|nested] 171+ messages in thread
* Re: [PATCH v3 00/32] PCI: fix config and I/O Address space memory mappings
@ 2017-04-12 13:48 ` Benjamin Herrenschmidt
0 siblings, 0 replies; 171+ messages in thread
From: Benjamin Herrenschmidt @ 2017-04-12 13:48 UTC (permalink / raw)
To: Lorenzo Pieralisi
Cc: Jonas Bonn, Rich Felker, linux-pci, Will Deacon,
James E.J. Bottomley, David Howells, Max Filippov,
Paul Mackerras, Huacai Chen, Guan Xuetao, Thomas Gleixner,
Hans-Christian Egtvedt, linux-arch, Jesper Nilsson,
Yoshinori Sato, Michael Ellerman, Helge Deller, Russell King,
Ingo Molnar, Geert Uytterhoeven, Catalin Marinas, Matt Turner,
Haavard Skinnemoen, Fenghua Yu
On Wed, 2017-04-12 at 10:44 +0100, Lorenzo Pieralisi wrote:
> > 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).
Then provide some kind of HAVE_* or config option indicating that this
mapping attribute exist so the bridge code at least has the option of
implementing an "alternative" mechanism when it doesn't rather than
silently being wrong :-)
(Or just return NULL, that works too)
Cheers,
Ben.
^ permalink raw reply [flat|nested] 171+ messages in thread
* Re: [PATCH v3 00/32] PCI: fix config and I/O Address space memory mappings
2017-04-11 23:12 ` Benjamin Herrenschmidt
(?)
@ 2017-04-12 11:31 ` Russell King - ARM Linux
-1 siblings, 0 replies; 171+ messages in thread
From: Russell King - ARM Linux @ 2017-04-12 11:31 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Jonas Bonn, Rich Felker, linux-pci, Will Deacon, David Howells,
Max Filippov, Paul Mackerras, Huacai Chen, Guan Xuetao,
Thomas Gleixner, Hans-Christian Egtvedt, linux-arch,
Jesper Nilsson, Lorenzo Pieralisi, Yoshinori Sato,
Michael Ellerman, Helge Deller, James E.J. Bottomley,
Ingo Molnar, Geert Uytterhoeven, Catalin Marinas, Matt Turner,
Haavard Skinnemoen, Fenghua Yu, James Hogan, Chris Metcalf,
Arnd Bergmann, Heiko Carstens, Stefan Kristiansson,
Mikael Starvik, Ivan Kokshaysky, Bjorn Helgaas, Stafford Horne,
linux-arm-kernel, Richard Henderson, Chris Zankel, Michal Simek,
Tony Luck, Vineet Gupta, linux-kernel, Ralf Baechle, Richard Kuo,
Niklas Cassel, Luis R. Rodriguez, Martin Schwidefsky,
Ley Foon Tan, David S. Miller
On Wed, Apr 12, 2017 at 09:12:51AM +1000, Benjamin Herrenschmidt wrote:
> 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.
So what you seem to be saying is to place drivers not in drivers/pci/host
but in arch/arm, and a duplicate copy in arch/arm64.
No. We're way past that by popular concensus. We're not going back to
doing what we did in the 2000s. Drivers go in the drivers subtree,
period. That means we require architecture interfaces that provide
access to architecture specific details that may not be suitable for
all architectures to support.
In the case of something brand new, then I agree with you that the
default implementation should fail if it's not supportable on all
architectures. However, when we have existing drivers using an
interface that doesn't provide the semantics they already require,
then it makes no sense to effectively break these drivers on a range
of existing architectures.
The question really is - what's the best way to solve the problem with
existing drivers without breaking them. I suspect that, sadly, the
only realistic way forward here is via the litter-drivers-with-ifdefs
approach since you don't like providing a default implementation that
is compatible with what these drivers are already doing.
Drivers, such as:
drivers/pci/host/pci-mvebu.c
drivers/pci/host/pci-versatile.c
drivers/pci/host/pci-xgene.c
to name a few.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 171+ messages in thread
* [PATCH v3 00/32] PCI: fix config and I/O Address space memory mappings
@ 2017-04-12 11:31 ` Russell King - ARM Linux
0 siblings, 0 replies; 171+ messages in thread
From: Russell King - ARM Linux @ 2017-04-12 11:31 UTC (permalink / raw)
To: linux-arm-kernel
On Wed, Apr 12, 2017 at 09:12:51AM +1000, Benjamin Herrenschmidt wrote:
> 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.
So what you seem to be saying is to place drivers not in drivers/pci/host
but in arch/arm, and a duplicate copy in arch/arm64.
No. We're way past that by popular concensus. We're not going back to
doing what we did in the 2000s. Drivers go in the drivers subtree,
period. That means we require architecture interfaces that provide
access to architecture specific details that may not be suitable for
all architectures to support.
In the case of something brand new, then I agree with you that the
default implementation should fail if it's not supportable on all
architectures. However, when we have existing drivers using an
interface that doesn't provide the semantics they already require,
then it makes no sense to effectively break these drivers on a range
of existing architectures.
The question really is - what's the best way to solve the problem with
existing drivers without breaking them. I suspect that, sadly, the
only realistic way forward here is via the litter-drivers-with-ifdefs
approach since you don't like providing a default implementation that
is compatible with what these drivers are already doing.
Drivers, such as:
drivers/pci/host/pci-mvebu.c
drivers/pci/host/pci-versatile.c
drivers/pci/host/pci-xgene.c
to name a few.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply [flat|nested] 171+ messages in thread
* Re: [PATCH v3 00/32] PCI: fix config and I/O Address space memory mappings
@ 2017-04-12 11:31 ` Russell King - ARM Linux
0 siblings, 0 replies; 171+ messages in thread
From: Russell King - ARM Linux @ 2017-04-12 11:31 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Jonas Bonn, Rich Felker, linux-pci, Will Deacon, David Howells,
Max Filippov, Paul Mackerras, Huacai Chen, Guan Xuetao,
Thomas Gleixner, Hans-Christian Egtvedt, linux-arch,
Jesper Nilsson, Lorenzo Pieralisi, Yoshinori Sato,
Michael Ellerman, Helge Deller, James E.J. Bottomley,
Ingo Molnar, Geert Uytterhoeven, Catalin Marinas, Matt Turner,
Haavard Skinnemoen, Fenghua Yu
On Wed, Apr 12, 2017 at 09:12:51AM +1000, Benjamin Herrenschmidt wrote:
> 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.
So what you seem to be saying is to place drivers not in drivers/pci/host
but in arch/arm, and a duplicate copy in arch/arm64.
No. We're way past that by popular concensus. We're not going back to
doing what we did in the 2000s. Drivers go in the drivers subtree,
period. That means we require architecture interfaces that provide
access to architecture specific details that may not be suitable for
all architectures to support.
In the case of something brand new, then I agree with you that the
default implementation should fail if it's not supportable on all
architectures. However, when we have existing drivers using an
interface that doesn't provide the semantics they already require,
then it makes no sense to effectively break these drivers on a range
of existing architectures.
The question really is - what's the best way to solve the problem with
existing drivers without breaking them. I suspect that, sadly, the
only realistic way forward here is via the litter-drivers-with-ifdefs
approach since you don't like providing a default implementation that
is compatible with what these drivers are already doing.
Drivers, such as:
drivers/pci/host/pci-mvebu.c
drivers/pci/host/pci-versatile.c
drivers/pci/host/pci-xgene.c
to name a few.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply [flat|nested] 171+ messages in thread
* Re: [PATCH v3 00/32] PCI: fix config and I/O Address space memory mappings
2017-04-12 11:31 ` Russell King - ARM Linux
(?)
@ 2017-04-12 13:51 ` Benjamin Herrenschmidt
-1 siblings, 0 replies; 171+ messages in thread
From: Benjamin Herrenschmidt @ 2017-04-12 13:51 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: Jonas Bonn, Rich Felker, linux-pci, Will Deacon, David Howells,
Max Filippov, Paul Mackerras, Huacai Chen, Guan Xuetao,
Thomas Gleixner, Hans-Christian Egtvedt, linux-arch,
Jesper Nilsson, Lorenzo Pieralisi, Yoshinori Sato,
Michael Ellerman, Helge Deller, James E.J. Bottomley,
Ingo Molnar, Geert Uytterhoeven, Catalin Marinas, Matt Turner,
Haavard Skinnemoen, Fenghua Yu, James Hogan, Chris Metcalf,
Arnd Bergmann, Heiko Carstens, Stefan Kristiansson,
Mikael Starvik, Ivan Kokshaysky, Bjorn Helgaas, Stafford Horne,
linux-arm-kernel, Richard Henderson, Chris Zankel, Michal Simek,
Tony Luck, Vineet Gupta, linux-kernel, Ralf Baechle, Richard Kuo,
Niklas Cassel, Luis R. Rodriguez, Martin Schwidefsky,
Ley Foon Tan, David S. Miller
T24gV2VkLCAyMDE3LTA0LTEyIGF0IDEyOjMxICswMTAwLCBSdXNzZWxsIEtpbmcgLSBBUk0gTGlu
dXggd3JvdGU6Cj4gZGVmYXVsdCBpbXBsZW1lbnRhdGlvbiBzaG91bGQgZmFpbCBpZiBpdCdzIG5v
dCBzdXBwb3J0YWJsZSBvbiBhbGwKPiBhcmNoaXRlY3R1cmVzLsKgIEhvd2V2ZXIsIHdoZW4gd2Ug
aGF2ZSBleGlzdGluZyBkcml2ZXJzIHVzaW5nIGFuCj4gaW50ZXJmYWNlIHRoYXQgZG9lc24ndCBw
cm92aWRlIHRoZSBzZW1hbnRpY3MgdGhleSBhbHJlYWR5IHJlcXVpcmUsCj4gdGhlbiBpdCBtYWtl
cyBubyBzZW5zZSB0byBlZmZlY3RpdmVseSBicmVhayB0aGVzZSBkcml2ZXJzIG9uIGEgcmFuZ2UK
PiBvZiBleGlzdGluZyBhcmNoaXRlY3R1cmVzLgo+IAo+IFRoZSBxdWVzdGlvbiByZWFsbHkgaXMg
LSB3aGF0J3MgdGhlIGJlc3Qgd2F5IHRvIHNvbHZlIHRoZSBwcm9ibGVtCj4gd2l0aAo+IGV4aXN0
aW5nIGRyaXZlcnMgd2l0aG91dCBicmVha2luZyB0aGVtLsKgIEkgc3VzcGVjdCB0aGF0LCBzYWRs
eSwgdGhlCj4gb25seSByZWFsaXN0aWMgd2F5IGZvcndhcmQgaGVyZSBpcyB2aWEgdGhlIGxpdHRl
ci1kcml2ZXJzLXdpdGgtaWZkZWZzCj4gYXBwcm9hY2ggc2luY2UgeW91IGRvbid0IGxpa2UgcHJv
dmlkaW5nIGEgZGVmYXVsdCBpbXBsZW1lbnRhdGlvbiB0aGF0Cj4gaXMgY29tcGF0aWJsZSB3aXRo
IHdoYXQgdGhlc2UgZHJpdmVycyBhcmUgYWxyZWFkeSBkb2luZy4KClRoZW4gbWFrZSBpb3JlbWFw
X25vcG9zdCByZXR1cm4gTlVMTCB3aGVuIHRoZSBhcmNoIGRvZXNuJ3QgaGF2ZSAKdGhlIHJpZ2h0
IHNlbWFudGljLgoKVGhlIGRyaXZlciB0aGFuIGNhbiAqY2hvc2UqIHRvIGVpdGhlciBzaWxlbnRs
eSBmYWxsYmFjayB0byBpb3JlbWFwLAp3aGljaCBoYXMgc2VydmVkIHVzIHdlbGwgZm9yIGEgbG9u
ZyB0aW1lIGRlc3BpdGUgYmVpbmcgdGhlb3JpY2FsbHkgaW4KdmlvbGF0aW9uIG9mIHRoZSBzcGVj
LCBvciBkbyBmdW5ueSB0aGluZ3MgbGlrZSByZWFkIGJhY2sgc29tZSByZWdpc3RlcgphZnRlciBl
dmVyeSBjb25maWcgd3JpdGUgdG8gZW5zdXJlIG9yZGVyaW5nIGV0Yy4uLgoKSSBtdWNoIHByZWZl
ciB0aGF0IGFwcHJvYWNoIHRoYW4gaGF2aW5nIHNvbWUgZ2VuZXJpYyBpb3JlbWFwIGZ1bmN0aW9u
CnRoYXQgZXhwb3NlcyBhIHNlbWFudGljIHRoYXQgc2lsZW50bHkgcHJvdmlkZXMgYSB3ZWFrZXIg
b25lIG9uIHNvbWUKYXJjaGl0ZWN0dXJlLgoKQXQgbGVhc3Qgd2UgbWFrZSB0aGUgZmFpbHVyZSBl
eHBsaWNpdCwgYW5kIHRoZSBkcml2ZXIgY2FuIHRha2UKYWx0ZXJuYXRlIChwb3NzaWJseSBzdWIt
b3B0aW1hbCkgYWN0aW9uIGlmIGl0IGNob29zZXMgdG8gZG8gc28uCgpDaGVlcnMsCkJlbi4KCgpf
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpsaW51eC1hcm0t
a2VybmVsIG1haWxpbmcgbGlzdApsaW51eC1hcm0ta2VybmVsQGxpc3RzLmluZnJhZGVhZC5vcmcK
aHR0cDovL2xpc3RzLmluZnJhZGVhZC5vcmcvbWFpbG1hbi9saXN0aW5mby9saW51eC1hcm0ta2Vy
bmVsCg==
^ permalink raw reply [flat|nested] 171+ messages in thread
* [PATCH v3 00/32] PCI: fix config and I/O Address space memory mappings
@ 2017-04-12 13:51 ` Benjamin Herrenschmidt
0 siblings, 0 replies; 171+ messages in thread
From: Benjamin Herrenschmidt @ 2017-04-12 13:51 UTC (permalink / raw)
To: linux-arm-kernel
On Wed, 2017-04-12 at 12:31 +0100, Russell King - ARM Linux wrote:
> default implementation should fail if it's not supportable on all
> architectures.? However, when we have existing drivers using an
> interface that doesn't provide the semantics they already require,
> then it makes no sense to effectively break these drivers on a range
> of existing architectures.
>
> The question really is - what's the best way to solve the problem
> with
> existing drivers without breaking them.? I suspect that, sadly, the
> only realistic way forward here is via the litter-drivers-with-ifdefs
> approach since you don't like providing a default implementation that
> is compatible with what these drivers are already doing.
Then make ioremap_nopost return NULL when the arch doesn't have
the right semantic.
The driver than can *chose* to either silently fallback to ioremap,
which has served us well for a long time despite being theorically in
violation of the spec, or do funny things like read back some register
after every config write to ensure ordering etc...
I much prefer that approach than having some generic ioremap function
that exposes a semantic that silently provides a weaker one on some
architecture.
At least we make the failure explicit, and the driver can take
alternate (possibly sub-optimal) action if it chooses to do so.
Cheers,
Ben.
^ permalink raw reply [flat|nested] 171+ messages in thread
* Re: [PATCH v3 00/32] PCI: fix config and I/O Address space memory mappings
@ 2017-04-12 13:51 ` Benjamin Herrenschmidt
0 siblings, 0 replies; 171+ messages in thread
From: Benjamin Herrenschmidt @ 2017-04-12 13:51 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: Jonas Bonn, Rich Felker, linux-pci, Will Deacon, David Howells,
Max Filippov, Paul Mackerras, Huacai Chen, Guan Xuetao,
Thomas Gleixner, Hans-Christian Egtvedt, linux-arch,
Jesper Nilsson, Lorenzo Pieralisi, Yoshinori Sato,
Michael Ellerman, Helge Deller, James E.J. Bottomley,
Ingo Molnar, Geert Uytterhoeven, Catalin Marinas, Matt Turner,
Haavard Skinnemoen, Fenghua Yu
On Wed, 2017-04-12 at 12:31 +0100, Russell King - ARM Linux wrote:
> default implementation should fail if it's not supportable on all
> architectures. However, when we have existing drivers using an
> interface that doesn't provide the semantics they already require,
> then it makes no sense to effectively break these drivers on a range
> of existing architectures.
>
> The question really is - what's the best way to solve the problem
> with
> existing drivers without breaking them. I suspect that, sadly, the
> only realistic way forward here is via the litter-drivers-with-ifdefs
> approach since you don't like providing a default implementation that
> is compatible with what these drivers are already doing.
Then make ioremap_nopost return NULL when the arch doesn't have
the right semantic.
The driver than can *chose* to either silently fallback to ioremap,
which has served us well for a long time despite being theorically in
violation of the spec, or do funny things like read back some register
after every config write to ensure ordering etc...
I much prefer that approach than having some generic ioremap function
that exposes a semantic that silently provides a weaker one on some
architecture.
At least we make the failure explicit, and the driver can take
alternate (possibly sub-optimal) action if it chooses to do so.
Cheers,
Ben.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 171+ messages in thread
* Re: [PATCH v3 00/32] PCI: fix config and I/O Address space memory mappings
2017-04-12 13:51 ` Benjamin Herrenschmidt
(?)
@ 2017-04-12 14:16 ` Russell King - ARM Linux
-1 siblings, 0 replies; 171+ messages in thread
From: Russell King - ARM Linux @ 2017-04-12 14:16 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Jonas Bonn, Rich Felker, linux-pci, Will Deacon, David Howells,
Max Filippov, Paul Mackerras, Huacai Chen, Guan Xuetao,
Thomas Gleixner, Hans-Christian Egtvedt, linux-arch,
Jesper Nilsson, Lorenzo Pieralisi, Yoshinori Sato,
Michael Ellerman, Helge Deller, James E.J. Bottomley,
Ingo Molnar, Geert Uytterhoeven, Catalin Marinas, Matt Turner,
Haavard Skinnemoen, Fenghua Yu, James Hogan, Chris Metcalf,
Arnd Bergmann, Heiko Carstens, Stefan Kristiansson,
Mikael Starvik, Ivan Kokshaysky, Bjorn Helgaas, Stafford Horne,
linux-arm-kernel, Richard Henderson, Chris Zankel, Michal Simek,
Tony Luck, Vineet Gupta, linux-kernel, Ralf Baechle, Richard Kuo,
Niklas Cassel, Luis R. Rodriguez, Martin Schwidefsky,
Ley Foon Tan, David S. Miller
On Wed, Apr 12, 2017 at 11:51:59PM +1000, Benjamin Herrenschmidt wrote:
> On Wed, 2017-04-12 at 12:31 +0100, Russell King - ARM Linux wrote:
> > default implementation should fail if it's not supportable on all
> > architectures.=A0 However, when we have existing drivers using an
> > interface that doesn't provide the semantics they already require,
> > then it makes no sense to effectively break these drivers on a range
> > of existing architectures.
> > =
> > The question really is - what's the best way to solve the problem
> > with
> > existing drivers without breaking them.=A0 I suspect that, sadly, the
> > only realistic way forward here is via the litter-drivers-with-ifdefs
> > approach since you don't like providing a default implementation that
> > is compatible with what these drivers are already doing.
> =
> Then make ioremap_nopost return NULL when the arch doesn't have =
> the right semantic.
> =
> The driver than can *chose* to either silently fallback to ioremap,
> which has served us well for a long time despite being theorically in
> violation of the spec, or do funny things like read back some register
> after every config write to ensure ordering etc...
> =
> I much prefer that approach than having some generic ioremap function
> that exposes a semantic that silently provides a weaker one on some
> architecture.
> =
> At least we make the failure explicit, and the driver can take
> alternate (possibly sub-optimal) action if it chooses to do so.
The same points apply to things like pgprot_writecombine(),
pgprot_noncached(), pgprot_device(). Then there's also pgprot_nonposted()
that this series also introduces.
If ioremap_nopost() is not possible on an architecture, then
pgprot_nonposted() won't be possible either - but you've made no
mention of that so far.
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?
-- =
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 171+ messages in thread
* [PATCH v3 00/32] PCI: fix config and I/O Address space memory mappings
@ 2017-04-12 14:16 ` Russell King - ARM Linux
0 siblings, 0 replies; 171+ messages in thread
From: Russell King - ARM Linux @ 2017-04-12 14:16 UTC (permalink / raw)
To: linux-arm-kernel
On Wed, Apr 12, 2017 at 11:51:59PM +1000, Benjamin Herrenschmidt wrote:
> On Wed, 2017-04-12 at 12:31 +0100, Russell King - ARM Linux wrote:
> > default implementation should fail if it's not supportable on all
> > architectures.? However, when we have existing drivers using an
> > interface that doesn't provide the semantics they already require,
> > then it makes no sense to effectively break these drivers on a range
> > of existing architectures.
> >
> > The question really is - what's the best way to solve the problem
> > with
> > existing drivers without breaking them.? I suspect that, sadly, the
> > only realistic way forward here is via the litter-drivers-with-ifdefs
> > approach since you don't like providing a default implementation that
> > is compatible with what these drivers are already doing.
>
> Then make ioremap_nopost return NULL when the arch doesn't have
> the right semantic.
>
> The driver than can *chose* to either silently fallback to ioremap,
> which has served us well for a long time despite being theorically in
> violation of the spec, or do funny things like read back some register
> after every config write to ensure ordering etc...
>
> I much prefer that approach than having some generic ioremap function
> that exposes a semantic that silently provides a weaker one on some
> architecture.
>
> At least we make the failure explicit, and the driver can take
> alternate (possibly sub-optimal) action if it chooses to do so.
The same points apply to things like pgprot_writecombine(),
pgprot_noncached(), pgprot_device(). Then there's also pgprot_nonposted()
that this series also introduces.
If ioremap_nopost() is not possible on an architecture, then
pgprot_nonposted() won't be possible either - but you've made no
mention of that so far.
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?
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply [flat|nested] 171+ messages in thread
* Re: [PATCH v3 00/32] PCI: fix config and I/O Address space memory mappings
@ 2017-04-12 14:16 ` Russell King - ARM Linux
0 siblings, 0 replies; 171+ messages in thread
From: Russell King - ARM Linux @ 2017-04-12 14:16 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Jonas Bonn, Rich Felker, linux-pci, Will Deacon, David Howells,
Max Filippov, Paul Mackerras, Huacai Chen, Guan Xuetao,
Thomas Gleixner, Hans-Christian Egtvedt, linux-arch,
Jesper Nilsson, Lorenzo Pieralisi, Yoshinori Sato,
Michael Ellerman, Helge Deller, James E.J. Bottomley,
Ingo Molnar, Geert Uytterhoeven, Catalin Marinas, Matt Turner,
Haavard Skinnemoen, Fenghua Yu
On Wed, Apr 12, 2017 at 11:51:59PM +1000, Benjamin Herrenschmidt wrote:
> On Wed, 2017-04-12 at 12:31 +0100, Russell King - ARM Linux wrote:
> > default implementation should fail if it's not supportable on all
> > architectures. However, when we have existing drivers using an
> > interface that doesn't provide the semantics they already require,
> > then it makes no sense to effectively break these drivers on a range
> > of existing architectures.
> >
> > The question really is - what's the best way to solve the problem
> > with
> > existing drivers without breaking them. I suspect that, sadly, the
> > only realistic way forward here is via the litter-drivers-with-ifdefs
> > approach since you don't like providing a default implementation that
> > is compatible with what these drivers are already doing.
>
> Then make ioremap_nopost return NULL when the arch doesn't have
> the right semantic.
>
> The driver than can *chose* to either silently fallback to ioremap,
> which has served us well for a long time despite being theorically in
> violation of the spec, or do funny things like read back some register
> after every config write to ensure ordering etc...
>
> I much prefer that approach than having some generic ioremap function
> that exposes a semantic that silently provides a weaker one on some
> architecture.
>
> At least we make the failure explicit, and the driver can take
> alternate (possibly sub-optimal) action if it chooses to do so.
The same points apply to things like pgprot_writecombine(),
pgprot_noncached(), pgprot_device(). Then there's also pgprot_nonposted()
that this series also introduces.
If ioremap_nopost() is not possible on an architecture, then
pgprot_nonposted() won't be possible either - but you've made no
mention of that so far.
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?
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply [flat|nested] 171+ messages in thread
* Re: [PATCH v3 00/32] PCI: fix config and I/O Address space memory mappings
2017-04-12 14:16 ` Russell King - ARM Linux
(?)
@ 2017-04-12 14:41 ` Lorenzo Pieralisi
-1 siblings, 0 replies; 171+ messages in thread
From: Lorenzo Pieralisi @ 2017-04-12 14:41 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: Jonas Bonn, Rich Felker, Catalin Marinas, Will Deacon,
David Howells, Max Filippov, Paul Mackerras, Huacai Chen,
Guan Xuetao, Thomas Gleixner, Hans-Christian Egtvedt, linux-arch,
Jesper Nilsson, Yoshinori Sato, Michael Ellerman, Helge Deller,
James E.J. Bottomley, Ingo Molnar, Geert Uytterhoeven,
Benjamin Herrenschmidt, Matt Turner, Haavard Skinnemoen,
Fenghua Yu, James Hogan, Chris Metcalf, Arnd Bergmann,
Heiko Carstens, Stefan Kristiansson, Mikael Starvik,
Ivan Kokshaysky, Bjorn Helgaas, Stafford Horne, linux-arm-kernel,
Richard Henderson, Chris Zankel, Michal Simek, Tony Luck,
linux-pci, Vineet Gupta, linux-kernel, Ralf Baechle, Richard Kuo,
Niklas Cassel, Luis R. Rodriguez, Martin Schwidefsky,
Ley Foon Tan, David S. Miller
On Wed, Apr 12, 2017 at 03:16:55PM +0100, Russell King - ARM Linux wrote:
> On Wed, Apr 12, 2017 at 11:51:59PM +1000, Benjamin Herrenschmidt wrote:
> > On Wed, 2017-04-12 at 12:31 +0100, Russell King - ARM Linux wrote:
> > > default implementation should fail if it's not supportable on all
> > > architectures.=A0 However, when we have existing drivers using an
> > > interface that doesn't provide the semantics they already require,
> > > then it makes no sense to effectively break these drivers on a range
> > > of existing architectures.
> > > =
> > > The question really is - what's the best way to solve the problem
> > > with
> > > existing drivers without breaking them.=A0 I suspect that, sadly, the
> > > only realistic way forward here is via the litter-drivers-with-ifdefs
> > > approach since you don't like providing a default implementation that
> > > is compatible with what these drivers are already doing.
> > =
> > Then make ioremap_nopost return NULL when the arch doesn't have =
> > the right semantic.
> > =
> > The driver than can *chose* to either silently fallback to ioremap,
> > which has served us well for a long time despite being theorically in
> > violation of the spec, or do funny things like read back some register
> > after every config write to ensure ordering etc...
> > =
> > I much prefer that approach than having some generic ioremap function
> > that exposes a semantic that silently provides a weaker one on some
> > architecture.
> > =
> > At least we make the failure explicit, and the driver can take
> > alternate (possibly sub-optimal) action if it chooses to do so.
> =
> The same points apply to things like pgprot_writecombine(),
> pgprot_noncached(), pgprot_device(). Then there's also pgprot_nonposted()
> that this series also introduces.
> =
> If ioremap_nopost() is not possible on an architecture, then
> pgprot_nonposted() won't be possible either - but you've made no
> mention of that so far.
> =
> 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?
Yes, I was about to mention that and you are right, I should deal with
that too unfortunately. BTW, I have not posted the drivers to make the
review easier (ie it would add 20 more patches to an already massive
patch series - that will be trimmed when the asm-generic include is
removed from arches according to this discussion).
Thanks,
Lorenzo
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 171+ messages in thread
* [PATCH v3 00/32] PCI: fix config and I/O Address space memory mappings
@ 2017-04-12 14:41 ` Lorenzo Pieralisi
0 siblings, 0 replies; 171+ messages in thread
From: Lorenzo Pieralisi @ 2017-04-12 14:41 UTC (permalink / raw)
To: linux-arm-kernel
On Wed, Apr 12, 2017 at 03:16:55PM +0100, Russell King - ARM Linux wrote:
> On Wed, Apr 12, 2017 at 11:51:59PM +1000, Benjamin Herrenschmidt wrote:
> > On Wed, 2017-04-12 at 12:31 +0100, Russell King - ARM Linux wrote:
> > > default implementation should fail if it's not supportable on all
> > > architectures.? However, when we have existing drivers using an
> > > interface that doesn't provide the semantics they already require,
> > > then it makes no sense to effectively break these drivers on a range
> > > of existing architectures.
> > >
> > > The question really is - what's the best way to solve the problem
> > > with
> > > existing drivers without breaking them.? I suspect that, sadly, the
> > > only realistic way forward here is via the litter-drivers-with-ifdefs
> > > approach since you don't like providing a default implementation that
> > > is compatible with what these drivers are already doing.
> >
> > Then make ioremap_nopost return NULL when the arch doesn't have
> > the right semantic.
> >
> > The driver than can *chose* to either silently fallback to ioremap,
> > which has served us well for a long time despite being theorically in
> > violation of the spec, or do funny things like read back some register
> > after every config write to ensure ordering etc...
> >
> > I much prefer that approach than having some generic ioremap function
> > that exposes a semantic that silently provides a weaker one on some
> > architecture.
> >
> > At least we make the failure explicit, and the driver can take
> > alternate (possibly sub-optimal) action if it chooses to do so.
>
> The same points apply to things like pgprot_writecombine(),
> pgprot_noncached(), pgprot_device(). Then there's also pgprot_nonposted()
> that this series also introduces.
>
> If ioremap_nopost() is not possible on an architecture, then
> pgprot_nonposted() won't be possible either - but you've made no
> mention of that so far.
>
> 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?
Yes, I was about to mention that and you are right, I should deal with
that too unfortunately. BTW, I have not posted the drivers to make the
review easier (ie it would add 20 more patches to an already massive
patch series - that will be trimmed when the asm-generic include is
removed from arches according to this discussion).
Thanks,
Lorenzo
^ permalink raw reply [flat|nested] 171+ messages in thread
* Re: [PATCH v3 00/32] PCI: fix config and I/O Address space memory mappings
@ 2017-04-12 14:41 ` Lorenzo Pieralisi
0 siblings, 0 replies; 171+ messages in thread
From: Lorenzo Pieralisi @ 2017-04-12 14:41 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: Jonas Bonn, Rich Felker, Catalin Marinas, Will Deacon,
David Howells, Max Filippov, Paul Mackerras, Huacai Chen,
Guan Xuetao, Thomas Gleixner, Hans-Christian Egtvedt, linux-arch,
Jesper Nilsson, Yoshinori Sato, Michael Ellerman, Helge Deller,
James E.J. Bottomley, Ingo Molnar, Geert Uytterhoeven,
Benjamin Herrenschmidt, Matt Turner, Haavard Skinnemoen,
Fenghua Yu
On Wed, Apr 12, 2017 at 03:16:55PM +0100, Russell King - ARM Linux wrote:
> On Wed, Apr 12, 2017 at 11:51:59PM +1000, Benjamin Herrenschmidt wrote:
> > On Wed, 2017-04-12 at 12:31 +0100, Russell King - ARM Linux wrote:
> > > default implementation should fail if it's not supportable on all
> > > architectures. However, when we have existing drivers using an
> > > interface that doesn't provide the semantics they already require,
> > > then it makes no sense to effectively break these drivers on a range
> > > of existing architectures.
> > >
> > > The question really is - what's the best way to solve the problem
> > > with
> > > existing drivers without breaking them. I suspect that, sadly, the
> > > only realistic way forward here is via the litter-drivers-with-ifdefs
> > > approach since you don't like providing a default implementation that
> > > is compatible with what these drivers are already doing.
> >
> > Then make ioremap_nopost return NULL when the arch doesn't have
> > the right semantic.
> >
> > The driver than can *chose* to either silently fallback to ioremap,
> > which has served us well for a long time despite being theorically in
> > violation of the spec, or do funny things like read back some register
> > after every config write to ensure ordering etc...
> >
> > I much prefer that approach than having some generic ioremap function
> > that exposes a semantic that silently provides a weaker one on some
> > architecture.
> >
> > At least we make the failure explicit, and the driver can take
> > alternate (possibly sub-optimal) action if it chooses to do so.
>
> The same points apply to things like pgprot_writecombine(),
> pgprot_noncached(), pgprot_device(). Then there's also pgprot_nonposted()
> that this series also introduces.
>
> If ioremap_nopost() is not possible on an architecture, then
> pgprot_nonposted() won't be possible either - but you've made no
> mention of that so far.
>
> 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?
Yes, I was about to mention that and you are right, I should deal with
that too unfortunately. BTW, I have not posted the drivers to make the
review easier (ie it would add 20 more patches to an already massive
patch series - that will be trimmed when the asm-generic include is
removed from arches according to this discussion).
Thanks,
Lorenzo
^ permalink raw reply [flat|nested] 171+ messages in thread
* Re: [PATCH v3 00/32] PCI: fix config and I/O Address space memory mappings
2017-04-12 14:41 ` Lorenzo Pieralisi
(?)
@ 2017-04-12 22:30 ` Benjamin Herrenschmidt
-1 siblings, 0 replies; 171+ messages in thread
From: Benjamin Herrenschmidt @ 2017-04-12 22:30 UTC (permalink / raw)
To: Lorenzo Pieralisi, Russell King - ARM Linux
Cc: Jonas Bonn, Rich Felker, linux-pci, Will Deacon, David Howells,
Max Filippov, Paul Mackerras, Huacai Chen, Guan Xuetao,
Thomas Gleixner, Hans-Christian Egtvedt, linux-arch,
Jesper Nilsson, Yoshinori Sato, Michael Ellerman, Helge Deller,
James E.J. Bottomley, Ingo Molnar, Geert Uytterhoeven,
Catalin Marinas, Matt Turner, Haavard Skinnemoen, Fenghua Yu,
James Hogan, Chris Metcalf, Arnd Bergmann, Heiko Carstens,
Stefan Kristiansson, Mikael Starvik, Ivan Kokshaysky,
Bjorn Helgaas, Stafford Horne, linux-arm-kernel,
Richard Henderson, Chris Zankel, Michal Simek, Tony Luck,
Vineet Gupta, linux-kernel, Ralf Baechle, Richard Kuo,
Niklas Cassel, Luis R. Rodriguez, Martin Schwidefsky,
Ley Foon Tan, David S. Miller
T24gV2VkLCAyMDE3LTA0LTEyIGF0IDE1OjQxICswMTAwLCBMb3JlbnpvIFBpZXJhbGlzaSB3cm90
ZToKPiA+ID4gQXQgbGVhc3Qgd2UgbWFrZSB0aGUgZmFpbHVyZSBleHBsaWNpdCwgYW5kIHRoZSBk
cml2ZXIgY2FuIHRha2UKPiA+ID4gYWx0ZXJuYXRlIChwb3NzaWJseSBzdWItb3B0aW1hbCkgYWN0
aW9uIGlmIGl0IGNob29zZXMgdG8gZG8gc28uCj4gPiAKPiA+IFRoZSBzYW1lIHBvaW50cyBhcHBs
eSB0byB0aGluZ3MgbGlrZSBwZ3Byb3Rfd3JpdGVjb21iaW5lKCksCj4gPiBwZ3Byb3Rfbm9uY2Fj
aGVkKCksIHBncHJvdF9kZXZpY2UoKS7CoCBUaGVuIHRoZXJlJ3MgYWxzbyBwZ3Byb3Rfbm9ucG9z
dGVkKCkKPiA+IHRoYXQgdGhpcyBzZXJpZXMgYWxzbyBpbnRyb2R1Y2VzLgoKTm8uIHBncHJvdF93
cml0ZWNvbWJpbmUoKSBzaWxlbnRseSBmYWxsaW5nIGJhY2sgdG8gc2ltcGx5IG5vbi1jYWNoZWQg
aXMKb2sgYXMgd2UgYXJlbid0ICJ3ZWFrZW5pbmciIHRoZSBvcmRlcmluZyBydWxlcyBzaWxlbnRs
eSBoZXJlLiBTb21ldGhpbmcKdGhhdCBpcyBjb3JyZWN0IHdpdGggd3JpdGVjb21iaW5lIHdpbGwg
YWxzbyB3b3JrIHdpdGhvdXQuIEl0J3MganVzdCBhbgpvcHRpbWlzYXRpb24uIE5vdCBjb3JyZWN0
bmVzcy4KClRoaW5ncyBsaWtlIG5vbmNhY2hlZCgpIG11c3Qgb2YgY291cnNlIGJlIGhvbm9yZWQs
IGFuZCBJIGRvbid0IHRoaW5rCndlIGhhdmUgYSBjYXNlIGFueXdoZXJlIHdoZXJlIGl0IGlzbid0
LgoKTXkgcG9pbnQgd2l0aCBub3Bvc3QoKSBpcyB0aGF0IGl0J3MgbmV2ZXIgb2sgdG8gc2lsZW50
bHkgZG93bmdyYWRlIGl0LgpDb2RlIHdyaXR0ZW4gd2l0aCB0aGUgYXNzdW1wdGlvbiB0aGF0IHRo
ZXJlIGlzIG5vIHBvc3Rpbmcgd2lsbCBiZQoqaW5jb3JyZWN0KiBpZiBwb3N0aW5nIGhhcHBlbnMu
IFdlIGRvIGxpdmUgd2l0aCB0aGF0ICJidWciIHRvZGF5IGluZGVlZApidXQgb25jZSB3ZSBoYXZl
IHRoYXQgYWNjZXNzb3JzIHdlIG1pZ2h0IHN0YXJ0IGdyb3dpbmcgbW9yZSBjb2RlIHRoYXQKcmVs
aWVzIG9uIHRoZSBzcGVjaWZpYyBhdHRyaWJ1dGUgdGhhdCB0aGluZ3MgYXJlbid0IHBvc3RlZCBh
bmQgd2lsbCBiZQp3cm9uZyBvbiBhbGwgdGhlIGFyY2hzIHByb3ZpZGluZyB0aGUgZGVmYXVsdCBp
bXBsZW1lbnRhdGlvbi4KClRoaXMgaXMgd2h5IEkgaW5zaXN0IHRoYXQgcGdwcm90X25vcG9zdCgp
IGlmIGl0IGV4aXN0cyBnbG9iYWxseSwgc2hvdWxkCnJldHVybiBOVUxMIHdoZW4gdGhlIHNlbWFu
dGljIGNhbm5vdCBiZSBwcm92aWRlZC4gVGhhdCB3YXkgdGhlcmUgaXMgYQpjbGVhciBsaW5lIGlu
IHRoZSBzYW5kLiBJZiB0aGUgZHJpdmVyIGNob3NlcyB0byBvcGVyYXRlIHdpdGggcG9zdGVkCm5v
bi1jYWNoZWQgYW55d2F5LCB0aGVuIG1ha2UgaXQgYW4gZXhwbGljaXQgZHJpdmVyIGNob2ljZS4K
Cj4gPiBJZiBpb3JlbWFwX25vcG9zdCgpIGlzIG5vdCBwb3NzaWJsZSBvbiBhbiBhcmNoaXRlY3R1
cmUsIHRoZW4KPiA+IHBncHJvdF9ub25wb3N0ZWQoKSB3b24ndCBiZSBwb3NzaWJsZSBlaXRoZXIg
LSBidXQgeW91J3ZlIG1hZGUgbm8KPiA+IG1lbnRpb24gb2YgdGhhdCBzbyBmYXIuCgpSaWdodC4g
SXQncyBub3Qgb24gbW9zdCBpbiBmYWN0LgoKPiA+IEp1c3QgbGlrZSB0aGUgcHJvcG9zZWQgaW9y
ZW1hcF9ub3Bvc3QoKSwgcGdwcm90X25vbnBvc3RlZCgpIGlzIGdpdmVuIGEKPiA+IGRlZmF1bHQg
aW1wbGVtZW50YXRpb24gdGhhdCB1c2VzIHBncHJvdF9ub25jYWNoZWQoKS7CoCBNYXliZSB3ZSBz
aG91bGQKPiA+IGFsc28gbWFrZSBwY2lfcmVtYXBfaW9zcGFjZSgpIGZhaWwgaWYgcGdwcm90X25v
bnBvc3RlZCgpIGlzIG5vdCBkZWZpbmVkCj4gPiBieSB0aGUgYXJjaGl0ZWN0dXJlPwoKT3Igd2Ug
KmRvY3VtZW50KiB0aGF0IG1tYXAgb2YgSU8gc3BhY2UgY2FuIHJlc3VsdCBpbiBzb21ldGhpbmcg
dGhhdCBpcwpwYXJ0aWFsbHkgbm9uLXBvc3RlZC4KCj4gWWVzLCBJIHdhcyBhYm91dCB0byBtZW50
aW9uIHRoYXQgYW5kIHlvdSBhcmUgcmlnaHQsIEkgc2hvdWxkIGRlYWwgd2l0aAo+IHRoYXQgdG9v
IHVuZm9ydHVuYXRlbHkuIEJUVywgSSBoYXZlIG5vdCBwb3N0ZWQgdGhlIGRyaXZlcnMgdG8gbWFr
ZSB0aGUKPiByZXZpZXcgZWFzaWVyIChpZSBpdCB3b3VsZCBhZGQgMjAgbW9yZSBwYXRjaGVzIHRv
IGFuIGFscmVhZHkgbWFzc2l2ZQo+IHBhdGNoIHNlcmllcyAtIHRoYXQgd2lsbCBiZSB0cmltbWVk
IHdoZW4gdGhlIGFzbS1nZW5lcmljIGluY2x1ZGUgaXMKPiByZW1vdmVkIGZyb20gYXJjaGVzIGFj
Y29yZGluZyB0byB0aGlzIGRpc2N1c3Npb24pLgo+IAo+IFRoYW5rcywKPiBMb3JlbnpvCgpfX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpsaW51eC1hcm0ta2Vy
bmVsIG1haWxpbmcgbGlzdApsaW51eC1hcm0ta2VybmVsQGxpc3RzLmluZnJhZGVhZC5vcmcKaHR0
cDovL2xpc3RzLmluZnJhZGVhZC5vcmcvbWFpbG1hbi9saXN0aW5mby9saW51eC1hcm0ta2VybmVs
Cg==
^ permalink raw reply [flat|nested] 171+ messages in thread
* [PATCH v3 00/32] PCI: fix config and I/O Address space memory mappings
@ 2017-04-12 22:30 ` Benjamin Herrenschmidt
0 siblings, 0 replies; 171+ messages in thread
From: Benjamin Herrenschmidt @ 2017-04-12 22:30 UTC (permalink / raw)
To: linux-arm-kernel
On Wed, 2017-04-12 at 15:41 +0100, Lorenzo Pieralisi wrote:
> > > At least we make the failure explicit, and the driver can take
> > > alternate (possibly sub-optimal) action if it chooses to do so.
> >
> > The same points apply to things like pgprot_writecombine(),
> > pgprot_noncached(), pgprot_device().? Then there's also pgprot_nonposted()
> > that this series also introduces.
No. pgprot_writecombine() silently falling back to simply non-cached is
ok as we aren't "weakening" the ordering rules silently here. Something
that is correct with writecombine will also work without. It's just an
optimisation. Not correctness.
Things like noncached() must of course be honored, and I don't think
we have a case anywhere where it isn't.
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. That way there is a
clear line in the sand. If the driver choses to operate with posted
non-cached anyway, then make it an explicit driver choice.
> > If ioremap_nopost() is not possible on an architecture, then
> > pgprot_nonposted() won't be possible either - but you've made no
> > mention of that so far.
Right. It's not on most in fact.
> > 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.
> Yes, I was about to mention that and you are right, I should deal with
> that too unfortunately. BTW, I have not posted the drivers to make the
> review easier (ie it would add 20 more patches to an already massive
> patch series - that will be trimmed when the asm-generic include is
> removed from arches according to this discussion).
>
> Thanks,
> Lorenzo
^ permalink raw reply [flat|nested] 171+ messages in thread
* Re: [PATCH v3 00/32] PCI: fix config and I/O Address space memory mappings
@ 2017-04-12 22:30 ` Benjamin Herrenschmidt
0 siblings, 0 replies; 171+ messages in thread
From: Benjamin Herrenschmidt @ 2017-04-12 22:30 UTC (permalink / raw)
To: Lorenzo Pieralisi, Russell King - ARM Linux
Cc: Jonas Bonn, Rich Felker, linux-pci, Will Deacon, David Howells,
Max Filippov, Paul Mackerras, Huacai Chen, Guan Xuetao,
Thomas Gleixner, Hans-Christian Egtvedt, linux-arch,
Jesper Nilsson, Yoshinori Sato, Michael Ellerman, Helge Deller,
James E.J. Bottomley, Ingo Molnar, Geert Uytterhoeven,
Catalin Marinas, Matt Turner, Haavard Skinnemoen, Fenghua Yu,
James Hogan
On Wed, 2017-04-12 at 15:41 +0100, Lorenzo Pieralisi wrote:
> > > At least we make the failure explicit, and the driver can take
> > > alternate (possibly sub-optimal) action if it chooses to do so.
> >
> > The same points apply to things like pgprot_writecombine(),
> > pgprot_noncached(), pgprot_device(). Then there's also pgprot_nonposted()
> > that this series also introduces.
No. pgprot_writecombine() silently falling back to simply non-cached is
ok as we aren't "weakening" the ordering rules silently here. Something
that is correct with writecombine will also work without. It's just an
optimisation. Not correctness.
Things like noncached() must of course be honored, and I don't think
we have a case anywhere where it isn't.
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. That way there is a
clear line in the sand. If the driver choses to operate with posted
non-cached anyway, then make it an explicit driver choice.
> > If ioremap_nopost() is not possible on an architecture, then
> > pgprot_nonposted() won't be possible either - but you've made no
> > mention of that so far.
Right. It's not on most in fact.
> > 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.
> Yes, I was about to mention that and you are right, I should deal with
> that too unfortunately. BTW, I have not posted the drivers to make the
> review easier (ie it would add 20 more patches to an already massive
> patch series - that will be trimmed when the asm-generic include is
> removed from arches according to this discussion).
>
> Thanks,
> Lorenzo
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 171+ messages in thread
* Re: [PATCH v3 00/32] PCI: fix config and I/O Address space memory mappings
2017-04-12 22:30 ` Benjamin Herrenschmidt
(?)
@ 2017-04-12 22:45 ` Russell King - ARM Linux
-1 siblings, 0 replies; 171+ messages in thread
From: Russell King - ARM Linux @ 2017-04-12 22:45 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Jonas Bonn, Rich Felker, linux-pci, Will Deacon, David Howells,
Max Filippov, Paul Mackerras, Huacai Chen, Guan Xuetao,
Thomas Gleixner, Hans-Christian Egtvedt, linux-arch,
Jesper Nilsson, Lorenzo Pieralisi, Yoshinori Sato,
Michael Ellerman, Helge Deller, James E.J. Bottomley,
Ingo Molnar, Geert Uytterhoeven, Catalin Marinas, Matt Turner,
Haavard Skinnemoen, Fenghua Yu, James Hogan, Chris Metcalf,
Arnd Bergmann, Heiko Carstens, Stefan Kristiansson,
Mikael Starvik, Ivan Kokshaysky, Bjorn Helgaas, Stafford Horne,
linux-arm-kernel, Richard Henderson, Chris Zankel, Michal Simek,
Tony Luck, Vineet Gupta, linux-kernel, Ralf Baechle, Richard Kuo,
Niklas Cassel, Luis R. Rodriguez, Martin Schwidefsky,
Ley Foon Tan, David S. Miller
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.
> > > Just like the proposed ioremap_nopost(), pgprot_nonposted() is given a
> > > default implementation that uses pgprot_noncached().=A0 Maybe we shou=
ld
> > > also make pci_remap_iospace() fail if pgprot_nonposted() is not defin=
ed
> > > 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.
Especially as userspace can't know what semantics its going to end up
with, this seems to be a very strange stance to take.
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.
-- =
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 171+ messages in thread
* [PATCH v3 00/32] PCI: fix config and I/O Address space memory mappings
@ 2017-04-12 22:45 ` Russell King - ARM Linux
0 siblings, 0 replies; 171+ messages in thread
From: Russell King - ARM Linux @ 2017-04-12 22:45 UTC (permalink / raw)
To: linux-arm-kernel
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.
> > > 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.
Especially as userspace can't know what semantics its going to end up
with, this seems to be a very strange stance to take.
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.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply [flat|nested] 171+ messages in thread
* Re: [PATCH v3 00/32] PCI: fix config and I/O Address space memory mappings
@ 2017-04-12 22:45 ` Russell King - ARM Linux
0 siblings, 0 replies; 171+ messages in thread
From: Russell King - ARM Linux @ 2017-04-12 22:45 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Jonas Bonn, Rich Felker, linux-pci, Will Deacon, David Howells,
Max Filippov, Paul Mackerras, Huacai Chen, Guan Xuetao,
Thomas Gleixner, Hans-Christian Egtvedt, linux-arch,
Jesper Nilsson, Lorenzo Pieralisi, Yoshinori Sato,
Michael Ellerman, Helge Deller, James E.J. Bottomley,
Ingo Molnar, Geert Uytterhoeven, Catalin Marinas, Matt Turner,
Haavard Skinnemoen, Fenghua Yu
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.
> > > 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.
Especially as userspace can't know what semantics its going to end up
with, this seems to be a very strange stance to take.
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.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply [flat|nested] 171+ messages in thread
* Re: [PATCH v3 00/32] PCI: fix config and I/O Address space memory mappings
2017-04-12 22:45 ` Russell King - ARM Linux
(?)
@ 2017-04-13 0:53 ` Benjamin Herrenschmidt
-1 siblings, 0 replies; 171+ messages in thread
From: Benjamin Herrenschmidt @ 2017-04-13 0:53 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: Jonas Bonn, Rich Felker, linux-pci, Will Deacon, David Howells,
Max Filippov, Paul Mackerras, Huacai Chen, Guan Xuetao,
Thomas Gleixner, Hans-Christian Egtvedt, linux-arch,
Jesper Nilsson, Lorenzo Pieralisi, Yoshinori Sato,
Michael Ellerman, Helge Deller, James E.J. Bottomley,
Ingo Molnar, Geert Uytterhoeven, Catalin Marinas, Matt Turner,
Haavard Skinnemoen, Fenghua Yu, James Hogan, Chris Metcalf,
Arnd Bergmann, Heiko Carstens, Stefan Kristiansson,
Mikael Starvik, Ivan Kokshaysky, Bjorn Helgaas, Stafford Horne,
linux-arm-kernel, Richard Henderson, Chris Zankel, Michal Simek,
Tony Luck, Vineet Gupta, linux-kernel, Ralf Baechle, Richard Kuo,
Niklas Cassel, Luis R. Rodriguez, Martin Schwidefsky,
Ley Foon Tan, David S. Miller
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=
^ permalink raw reply [flat|nested] 171+ messages in thread
* [PATCH v3 00/32] PCI: fix config and I/O Address space memory mappings
@ 2017-04-13 0:53 ` Benjamin Herrenschmidt
0 siblings, 0 replies; 171+ messages in thread
From: Benjamin Herrenschmidt @ 2017-04-13 0:53 UTC (permalink / raw)
To: linux-arm-kernel
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.
^ permalink raw reply [flat|nested] 171+ messages in thread
* Re: [PATCH v3 00/32] PCI: fix config and I/O Address space memory mappings
@ 2017-04-13 0:53 ` Benjamin Herrenschmidt
0 siblings, 0 replies; 171+ messages in thread
From: Benjamin Herrenschmidt @ 2017-04-13 0:53 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: Jonas Bonn, Rich Felker, linux-pci, Will Deacon, David Howells,
Max Filippov, Paul Mackerras, Huacai Chen, Guan Xuetao,
Thomas Gleixner, Hans-Christian Egtvedt, linux-arch,
Jesper Nilsson, Lorenzo Pieralisi, Yoshinori Sato,
Michael Ellerman, Helge Deller, James E.J. Bottomley,
Ingo Molnar, Geert Uytterhoeven, Catalin Marinas, Matt Turner,
Haavard Skinnemoen, Fenghua Yu
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
^ permalink raw reply [flat|nested] 171+ messages in thread
* Re: [PATCH v3 00/32] PCI: fix config and I/O Address space memory mappings
2017-04-13 0:53 ` Benjamin Herrenschmidt
(?)
@ 2017-04-18 8:57 ` Lorenzo Pieralisi
-1 siblings, 0 replies; 171+ messages in thread
From: Lorenzo Pieralisi @ 2017-04-18 8:57 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Jonas Bonn, Rich Felker, linux-pci, Will Deacon,
James E.J. Bottomley, David Howells, Max Filippov,
Paul Mackerras, Huacai Chen, Guan Xuetao, Thomas Gleixner,
Hans-Christian Egtvedt, linux-arch, Jesper Nilsson,
Yoshinori Sato, Michael Ellerman, Helge Deller,
Russell King - ARM Linux, Ingo Molnar, Geert Uytterhoeven,
Catalin Marinas, Matt Turner, Haavard Skinnemoen, Fenghua Yu,
James Hogan, Chris Metcalf, Arnd Bergmann, Heiko Carstens,
Stefan Kristiansson, Mikael Starvik, Ivan Kokshaysky,
Bjorn Helgaas, Stafford Horne, linux-arm-kernel,
Richard Henderson, Chris Zankel, Michal Simek, Tony Luck,
Vineet Gupta, linux-kernel, Ralf Baechle, Richard Kuo,
Niklas Cassel, Luis R. Rodriguez, Martin Schwidefsky,
Ley Foon Tan, David S. Miller
On Thu, Apr 13, 2017 at 10:53:00AM +1000, Benjamin Herrenschmidt wrote:
> 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 inde=
ed
> > > 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, shou=
ld
> > > return NULL when the semantic cannot be provided.
> > =
> > Now you're not talking sense.=A0=A0pgprot_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 gi=
ven a
> > > > > default implementation that uses pgprot_noncached().=A0 Maybe we =
should
> > > > > also make pci_remap_iospace() fail if pgprot_nonposted() is not d=
efined
> > > > > 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).
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 =3D (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
}
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 171+ messages in thread* [PATCH v3 00/32] PCI: fix config and I/O Address space memory mappings
@ 2017-04-18 8:57 ` Lorenzo Pieralisi
0 siblings, 0 replies; 171+ messages in thread
From: Lorenzo Pieralisi @ 2017-04-18 8:57 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, Apr 13, 2017 at 10:53:00AM +1000, Benjamin Herrenschmidt wrote:
> 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).
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
}
^ permalink raw reply [flat|nested] 171+ messages in thread* Re: [PATCH v3 00/32] PCI: fix config and I/O Address space memory mappings
@ 2017-04-18 8:57 ` Lorenzo Pieralisi
0 siblings, 0 replies; 171+ messages in thread
From: Lorenzo Pieralisi @ 2017-04-18 8:57 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Jonas Bonn, Rich Felker, linux-pci, Will Deacon,
James E.J. Bottomley, David Howells, Max Filippov,
Paul Mackerras, Huacai Chen, Guan Xuetao, Thomas Gleixner,
Hans-Christian Egtvedt, linux-arch, Jesper Nilsson,
Yoshinori Sato, Michael Ellerman, Helge Deller,
Russell King - ARM Linux, Ingo Molnar, Geert Uytterhoeven,
Catalin Marinas, Matt Turner, Haavard Skinnemoen, Fenghua Yu
On Thu, Apr 13, 2017 at 10:53:00AM +1000, Benjamin Herrenschmidt wrote:
> 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).
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
}
^ permalink raw reply [flat|nested] 171+ messages in thread* Re: [PATCH v3 00/32] PCI: fix config and I/O Address space memory mappings
2017-04-18 8:57 ` Lorenzo Pieralisi
(?)
@ 2017-04-18 10:36 ` Benjamin Herrenschmidt
-1 siblings, 0 replies; 171+ messages in thread
From: Benjamin Herrenschmidt @ 2017-04-18 10:36 UTC (permalink / raw)
To: Lorenzo Pieralisi
Cc: Jonas Bonn, Rich Felker, linux-pci, Will Deacon,
James E.J. Bottomley, David Howells, Max Filippov,
Paul Mackerras, Huacai Chen, Guan Xuetao, Thomas Gleixner,
Hans-Christian Egtvedt, linux-arch, Jesper Nilsson,
Yoshinori Sato, Michael Ellerman, Helge Deller,
Russell King - ARM Linux, Ingo Molnar, Geert Uytterhoeven,
Catalin Marinas, Matt Turner, Haavard Skinnemoen, Fenghua Yu,
James Hogan, Chris Metcalf, Arnd Bergmann, Heiko Carstens,
Stefan Kristiansson, Mikael Starvik, Ivan Kokshaysky,
Bjorn Helgaas, Stafford Horne, linux-arm-kernel,
Richard Henderson, Chris Zankel, Michal Simek, Tony Luck,
Vineet Gupta, linux-kernel, Ralf Baechle, Richard Kuo,
Niklas Cassel, Luis R. Rodriguez, Martin Schwidefsky,
Ley Foon Tan, David S. Miller
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=
^ permalink raw reply [flat|nested] 171+ messages in thread
* [PATCH v3 00/32] PCI: fix config and I/O Address space memory mappings
@ 2017-04-18 10:36 ` Benjamin Herrenschmidt
0 siblings, 0 replies; 171+ messages in thread
From: Benjamin Herrenschmidt @ 2017-04-18 10:36 UTC (permalink / raw)
To: linux-arm-kernel
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.
^ permalink raw reply [flat|nested] 171+ messages in thread* Re: [PATCH v3 00/32] PCI: fix config and I/O Address space memory mappings
@ 2017-04-18 10:36 ` Benjamin Herrenschmidt
0 siblings, 0 replies; 171+ messages in thread
From: Benjamin Herrenschmidt @ 2017-04-18 10:36 UTC (permalink / raw)
To: Lorenzo Pieralisi
Cc: Jonas Bonn, Rich Felker, linux-pci, Will Deacon,
James E.J. Bottomley, David Howells, Max Filippov,
Paul Mackerras, Huacai Chen, Guan Xuetao, Thomas Gleixner,
Hans-Christian Egtvedt, linux-arch, Jesper Nilsson,
Yoshinori Sato, Michael Ellerman, Helge Deller,
Russell King - ARM Linux, Ingo Molnar, Geert Uytterhoeven,
Catalin Marinas, Matt Turner, Haavard Skinnemoen, Fenghua Yu
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
^ permalink raw reply [flat|nested] 171+ messages in thread* Re: [PATCH v3 00/32] PCI: fix config and I/O Address space memory mappings
2017-04-18 10:36 ` Benjamin Herrenschmidt
(?)
@ 2017-04-18 11:03 ` Lorenzo Pieralisi
-1 siblings, 0 replies; 171+ messages in thread
From: Lorenzo Pieralisi @ 2017-04-18 11:03 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Jonas Bonn, Rich Felker, linux-pci, Will Deacon,
James E.J. Bottomley, David Howells, Max Filippov,
Paul Mackerras, Huacai Chen, Guan Xuetao, Thomas Gleixner,
Hans-Christian Egtvedt, linux-arch, Jesper Nilsson,
Yoshinori Sato, Michael Ellerman, Helge Deller,
Russell King - ARM Linux, Ingo Molnar, Geert Uytterhoeven,
Catalin Marinas, Matt Turner, Haavard Skinnemoen, Fenghua Yu,
James Hogan, Chris Metcalf, Arnd Bergmann, Heiko Carstens,
Stefan Kristiansson, Mikael Starvik, Ivan Kokshaysky,
Bjorn Helgaas, Stafford Horne, linux-arm-kernel,
Richard Henderson, Chris Zankel, Michal Simek, Tony Luck,
Vineet Gupta, linux-kernel, Ralf Baechle, Richard Kuo,
Niklas Cassel, Luis R. Rodriguez, Martin Schwidefsky,
Ley Foon Tan, David S. Miller
On Tue, Apr 18, 2017 at 08:36:48PM +1000, Benjamin Herrenschmidt wrote:
> 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_nonpos=
ted)
> > =A0=A0=A0=A0=A0=A0=A0=A0unsigned long vaddr =3D (unsigned long)PCI_IOBA=
SE + res->start;
> > =
> > =A0=A0=A0=A0=A0=A0=A0=A0if (!(res->flags & IORESOURCE_IO))
> > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0return -EINVAL;
> > =
> > =A0=A0=A0=A0=A0=A0=A0=A0if (res->end > IO_SPACE_LIMIT)
> > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0return -EINVAL
> > =A0=A0=A0=A0=A0=A0=A0=A0return ioremap_page_range(vaddr, vaddr + resour=
ce_size(res), phys_addr,
> > =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=A0=A0=A0=A0=A0=A0=A0 pgprot_nonposted(PAGE_KERNEL));
> > #else
> > =A0=A0=A0=A0=A0=A0=A0=A0/* this architecture does not have memory mappe=
d I/O space,
> > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 so this function should never be called =
*/
> > =A0=A0=A0=A0=A0=A0=A0=A0WARN_ONCE(1, "This architecture does not suppor=
t memory mapped I/O\n");
> > =A0=A0=A0=A0=A0=A0=A0=A0return -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.
pci_remap_iospace() is used on ARM/ARM64 only AFAICT I do not understand
what I would actually break (and I am not sure at all how well PCI IO
space is tested on ARM/ARM64 machines anyway).
> 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.
Again, the change above should not break anything.
> respect the "non-posted" semantics of IO and be done with it.
I can do that too (or leave IO space alone, I do not care either).
> 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...
I started by adding a pci_remap_cfgspace() interface. Bjorn did not
like it to be PCI specific so I made it a generic one. I am not aware
of any other non-posted writes ioremap requirements apart from config
space.
Thanks,
Lorenzo
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 171+ messages in thread* [PATCH v3 00/32] PCI: fix config and I/O Address space memory mappings
@ 2017-04-18 11:03 ` Lorenzo Pieralisi
0 siblings, 0 replies; 171+ messages in thread
From: Lorenzo Pieralisi @ 2017-04-18 11:03 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, Apr 18, 2017 at 08:36:48PM +1000, Benjamin Herrenschmidt wrote:
> 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.
pci_remap_iospace() is used on ARM/ARM64 only AFAICT I do not understand
what I would actually break (and I am not sure at all how well PCI IO
space is tested on ARM/ARM64 machines anyway).
> 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.
Again, the change above should not break anything.
> respect the "non-posted" semantics of IO and be done with it.
I can do that too (or leave IO space alone, I do not care either).
> 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...
I started by adding a pci_remap_cfgspace() interface. Bjorn did not
like it to be PCI specific so I made it a generic one. I am not aware
of any other non-posted writes ioremap requirements apart from config
space.
Thanks,
Lorenzo
^ permalink raw reply [flat|nested] 171+ messages in thread* Re: [PATCH v3 00/32] PCI: fix config and I/O Address space memory mappings
@ 2017-04-18 11:03 ` Lorenzo Pieralisi
0 siblings, 0 replies; 171+ messages in thread
From: Lorenzo Pieralisi @ 2017-04-18 11:03 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Jonas Bonn, Rich Felker, linux-pci, Will Deacon,
James E.J. Bottomley, David Howells, Max Filippov,
Paul Mackerras, Huacai Chen, Guan Xuetao, Thomas Gleixner,
Hans-Christian Egtvedt, linux-arch, Jesper Nilsson,
Yoshinori Sato, Michael Ellerman, Helge Deller,
Russell King - ARM Linux, Ingo Molnar, Geert Uytterhoeven,
Catalin Marinas, Matt Turner, Haavard Skinnemoen, Fenghua Yu
On Tue, Apr 18, 2017 at 08:36:48PM +1000, Benjamin Herrenschmidt wrote:
> 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.
pci_remap_iospace() is used on ARM/ARM64 only AFAICT I do not understand
what I would actually break (and I am not sure at all how well PCI IO
space is tested on ARM/ARM64 machines anyway).
> 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.
Again, the change above should not break anything.
> respect the "non-posted" semantics of IO and be done with it.
I can do that too (or leave IO space alone, I do not care either).
> 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...
I started by adding a pci_remap_cfgspace() interface. Bjorn did not
like it to be PCI specific so I made it a generic one. I am not aware
of any other non-posted writes ioremap requirements apart from config
space.
Thanks,
Lorenzo
^ permalink raw reply [flat|nested] 171+ messages in thread* Re: [PATCH v3 00/32] PCI: fix config and I/O Address space memory mappings
2017-04-18 11:03 ` Lorenzo Pieralisi
(?)
@ 2017-04-18 22:38 ` Benjamin Herrenschmidt
-1 siblings, 0 replies; 171+ messages in thread
From: Benjamin Herrenschmidt @ 2017-04-18 22:38 UTC (permalink / raw)
To: Lorenzo Pieralisi
Cc: Jonas Bonn, Rich Felker, linux-pci, Will Deacon,
James E.J. Bottomley, David Howells, Max Filippov,
Paul Mackerras, Huacai Chen, Guan Xuetao, Thomas Gleixner,
Hans-Christian Egtvedt, linux-arch, Jesper Nilsson,
Yoshinori Sato, Michael Ellerman, Helge Deller,
Russell King - ARM Linux, Ingo Molnar, Geert Uytterhoeven,
Catalin Marinas, Matt Turner, Haavard Skinnemoen, Fenghua Yu,
James Hogan, Chris Metcalf, Arnd Bergmann, Heiko Carstens,
Stefan Kristiansson, Mikael Starvik, Ivan Kokshaysky,
Bjorn Helgaas, Stafford Horne, linux-arm-kernel,
Richard Henderson, Chris Zankel, Michal Simek, Tony Luck,
Vineet Gupta, linux-kernel, Ralf Baechle, Richard Kuo,
Niklas Cassel, Luis R. Rodriguez, Martin Schwidefsky,
Ley Foon Tan, David S. Miller
On Tue, 2017-04-18 at 12:03 +0100, Lorenzo Pieralisi wrote:
> > 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.
>
> pci_remap_iospace() is used on ARM/ARM64 only AFAICT I do not
> understand
> what I would actually break (and I am not sure at all how well PCI IO
> space is tested on ARM/ARM64 machines anyway).
My bad, I incorrectly assumed you were hacking the generic sysfs PCI
mapping.
Cheers,
Ben.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 171+ messages in thread
* [PATCH v3 00/32] PCI: fix config and I/O Address space memory mappings
@ 2017-04-18 22:38 ` Benjamin Herrenschmidt
0 siblings, 0 replies; 171+ messages in thread
From: Benjamin Herrenschmidt @ 2017-04-18 22:38 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, 2017-04-18 at 12:03 +0100, Lorenzo Pieralisi wrote:
> > 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.
>
> pci_remap_iospace() is used on ARM/ARM64 only AFAICT I do not
> understand
> what I would actually break (and I am not sure at all how well PCI IO
> space is tested on ARM/ARM64 machines anyway).
My bad, I incorrectly assumed you were hacking the generic sysfs PCI
mapping.
Cheers,
Ben.
^ permalink raw reply [flat|nested] 171+ messages in thread
* Re: [PATCH v3 00/32] PCI: fix config and I/O Address space memory mappings
@ 2017-04-18 22:38 ` Benjamin Herrenschmidt
0 siblings, 0 replies; 171+ messages in thread
From: Benjamin Herrenschmidt @ 2017-04-18 22:38 UTC (permalink / raw)
To: Lorenzo Pieralisi
Cc: Jonas Bonn, Rich Felker, linux-pci, Will Deacon,
James E.J. Bottomley, David Howells, Max Filippov,
Paul Mackerras, Huacai Chen, Guan Xuetao, Thomas Gleixner,
Hans-Christian Egtvedt, linux-arch, Jesper Nilsson,
Yoshinori Sato, Michael Ellerman, Helge Deller,
Russell King - ARM Linux, Ingo Molnar, Geert Uytterhoeven,
Catalin Marinas, Matt Turner, Haavard Skinnemoen, Fenghua Yu
On Tue, 2017-04-18 at 12:03 +0100, Lorenzo Pieralisi wrote:
> > 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.
>
> pci_remap_iospace() is used on ARM/ARM64 only AFAICT I do not
> understand
> what I would actually break (and I am not sure at all how well PCI IO
> space is tested on ARM/ARM64 machines anyway).
My bad, I incorrectly assumed you were hacking the generic sysfs PCI
mapping.
Cheers,
Ben.
^ permalink raw reply [flat|nested] 171+ messages in thread