Re: [RFT PATCH v3 08/27] asm-generic/io.h: Add a non-posted variant of ioremap()
From: Will Deacon <will@kernel.org>
Date: 2021-03-24 18:13:28
Also in:
linux-arch, linux-arm-kernel, linux-doc, linux-samsung-soc, linux-serial, lkml
On Fri, Mar 05, 2021 at 06:38:43AM +0900, Hector Martin wrote:
quoted hunk ↗ jump to hunk
ARM64 currently defaults to posted MMIO (nGnRnE), but some devices require the use of non-posted MMIO (nGnRE). Introduce a new ioremap() variant to handle this case. ioremap_np() is aliased to ioremap() by default on arches that do not implement this variant. sparc64 is the only architecture that needs to be touched directly, because it includes neither of the generic io.h or iomap.h headers. This adds the IORESOURCE_MEM_NONPOSTED flag, which maps to this variant and marks a given resource as requiring non-posted mappings. This is implemented in the resource system because it is a SoC-level requirement, so existing drivers do not need special-case code to pick this ioremap variant. Then this is implemented in devres by introducing devm_ioremap_np(), and making devm_ioremap_resource() automatically select this variant when the resource has the IORESOURCE_MEM_NONPOSTED flag set. Signed-off-by: Hector Martin <redacted> --- .../driver-api/driver-model/devres.rst | 1 + arch/sparc/include/asm/io_64.h | 4 ++++ include/asm-generic/io.h | 22 ++++++++++++++++++- include/asm-generic/iomap.h | 9 ++++++++ include/linux/io.h | 2 ++ include/linux/ioport.h | 1 + lib/devres.c | 22 +++++++++++++++++++ 7 files changed, 60 insertions(+), 1 deletion(-)diff --git a/Documentation/driver-api/driver-model/devres.rst b/Documentation/driver-api/driver-model/devres.rst index cd8b6e657b94..2f45877a539d 100644 --- a/Documentation/driver-api/driver-model/devres.rst +++ b/Documentation/driver-api/driver-model/devres.rst@@ -309,6 +309,7 @@ IOMAP devm_ioremap() devm_ioremap_uc() devm_ioremap_wc() + devm_ioremap_np() devm_ioremap_resource() : checks resource, requests memory region, ioremaps devm_ioremap_resource_wc() devm_platform_ioremap_resource() : calls devm_ioremap_resource() for platform devicediff --git a/arch/sparc/include/asm/io_64.h b/arch/sparc/include/asm/io_64.h index 9bb27e5c22f1..9fbfc9574432 100644 --- a/arch/sparc/include/asm/io_64.h +++ b/arch/sparc/include/asm/io_64.h@@ -409,6 +409,10 @@ static inline void __iomem *ioremap(unsigned long offset, unsigned long size) #define ioremap_uc(X,Y) ioremap((X),(Y)) #define ioremap_wc(X,Y) ioremap((X),(Y)) #define ioremap_wt(X,Y) ioremap((X),(Y)) +static inline void __iomem *ioremap_np(unsigned long offset, unsigned long size) +{ + return NULL; +} static inline void iounmap(volatile void __iomem *addr) {diff --git a/include/asm-generic/io.h b/include/asm-generic/io.h index c6af40ce03be..082e0c96db6e 100644 --- a/include/asm-generic/io.h +++ b/include/asm-generic/io.h@@ -942,7 +942,9 @@ static inline void *phys_to_virt(unsigned long address) * * ioremap_wc() and ioremap_wt() can provide more relaxed caching attributes * for specific drivers if the architecture choses to implement them. If they - * are not implemented we fall back to plain ioremap. + * are not implemented we fall back to plain ioremap. Conversely, ioremap_np() + * can provide stricter non-posted write semantics if the architecture + * implements them. */ #ifndef CONFIG_MMU #ifndef ioremap@@ -993,6 +995,24 @@ static inline void __iomem *ioremap_uc(phys_addr_t offset, size_t size) { return NULL; } + +/* + * ioremap_np needs an explicit architecture implementation, as it + * requests stronger semantics than regular ioremap(). Portable drivers + * should instead use one of the higher-level abstractions, like + * devm_ioremap_resource(), to choose the correct variant for any given + * device and bus. Portable drivers with a good reason to want non-posted + * write semantics should always provide an ioremap() fallback in case + * ioremap_np() is not available. + */ +#ifndef ioremap_np +#define ioremap_np ioremap_np +static inline void __iomem *ioremap_np(phys_addr_t offset, size_t size) +{ + return NULL; +} +#endif
Can we implement the generic pci_remap_cfgspace() in terms of ioremap_np() if it is supported by the architecture? That way, we could avoid defining both on arm64. Will