From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755647AbbE3VAk (ORCPT ); Sat, 30 May 2015 17:00:40 -0400 Received: from mout.kundenserver.de ([212.227.126.131]:55914 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750965AbbE3VAc (ORCPT ); Sat, 30 May 2015 17:00:32 -0400 From: Arnd Bergmann To: Dan Williams Subject: Re: [PATCH v2 3/4] arch: introduce memremap() Date: Sat, 30 May 2015 23:00:10 +0200 User-Agent: KMail/1.12.2 (Linux/3.19.0-13-generic; KDE/4.3.2; x86_64; ; ) Cc: mingo@redhat.com, bp@alien8.de, hpa@zytor.com, tglx@linutronix.de, ross.zwisler@linux.intel.com, akpm@linux-foundation.org, jgross@suse.com, x86@kernel.org, toshi.kani@hp.com, linux-nvdimm@ml01.01.org, mcgrof@suse.com, konrad.wilk@oracle.com, linux-kernel@vger.kernel.org, stefan.bader@canonical.com, luto@amacapital.net, linux-mm@kvack.org, geert@linux-m68k.org, hmh@hmh.eng.br, tj@kernel.org, hch@lst.de References: <20150530185425.32590.3190.stgit@dwillia2-desk3.amr.corp.intel.com> <20150530185935.32590.95416.stgit@dwillia2-desk3.amr.corp.intel.com> In-Reply-To: <20150530185935.32590.95416.stgit@dwillia2-desk3.amr.corp.intel.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201505302300.10950.arnd@arndb.de> X-Provags-ID: V03:K0:jgpT2hG5bCoLZHPWOYXq4hSBQYf+lQ+LOyD7tdlK+BdA1cm8KqC J8S9Xxmj8n88jiXlLb2d+VVRbtk6bNsw5swtu//7YiZCOV/8zvV3z9BhBQKcFU42ruF3SwE HFzsp7RCM3ziBAp5OuMlt+c8EQxhCGCu55PR4cCRkGmUS7gA3gmr2NnbNzEPwRKNavhDwcp wQrrGqTGQ2am6zCD4WUPA== X-UI-Out-Filterresults: notjunk:1;V01:K0:PtTsdB75gRI=:UwHRA5W143Il72OsJSQvks A4ePxNWKmd/Gi8L1FI8TnyP2IxVokCnoJJq/SawNKebOoRDzn82sgcwzQdoJkSNdFwaIY1/Zf lSbcezT3/gALwqGUMmJtSQ13HAC5eJb1Igqy09x0wWM4vsXbziCbx+6hHo7VYCFH+zVJ/C1ra nluq1kXvpNkvvajzRNMfRR59rKJw4jnZI+ZMcDSMULYTo4jwNJFKevyELrMSAKtvZhcaxG96I fvI1oIgjKb5JsXWkzu1AXhXYG1J5djAnBGnmFZF7gdbZN7GegArNNDT9973Ti5WWa8jXIInUT SHCWuIEVIyWNOuHl+7F3bUMhcTkvbujCwZe1DucPc4eoD+/vgAj7rXu2Dv0P/fHxZKyn/cF10 TI4bTcZTIZfm/EeEo+QrKIY/ISwg3OqXHMzJIMqMIImdPjrA9sGDTGGhV3eBuai/z5EpscyXG WRyb3G5DGs4dFFa9y9QNjQzn9QsmPq6B/wh01krQmns6Cn6zKOA0UMTaOT0tY8FVK8WNVJ1uW njFZsgi5x5yOkaOGen/aKhluOqO7U287YIk+wSlQu7zBCgljG1Hx5oCskni//LTg7OaJQaU3+ Ueq9GnOYDFPdY07ywJmYRRXRz9QxfMrRGCHjWapEU0jFVz1BckTiRRstEvCiNQ6HvXFQgQnJA mMQ+F2ZOty+FPyszbq+WC4OPVtgZvuVsukWVPfljQfiS2LA== Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Saturday 30 May 2015, Dan Williams wrote: > > +/* > + * memremap() is "ioremap" for cases where it is known that the resource > + * being mapped does not have i/o side effects and the __iomem > + * annotation is not applicable. > + */ > + > +static inline void *memremap(resource_size_t offset, size_t size) > +{ > + return (void __force *) ioremap(offset, size); > +} > + > +static inline void *memremap_nocache(resource_size_t offset, size_t size) > +{ > + return (void __force *) ioremap_nocache(offset, size); > +} > + > +static inline void *memremap_cache(resource_size_t offset, size_t size) > +{ > + return (void __force *) ioremap_cache(offset, size); > +} > + There are architectures on which the result of ioremap is not necessarily a pointer, but instead indicates that the access is to be done through some other indirect access, or require special instructions. I think implementing the memremap() interfaces is generally helpful, but don't rely on the ioremap implementation. Adding both cached an uncached versions is also dangerous, because you typically get either undefined behavior or a system checkstop when a single page is mapped both cached and uncached at the same time. This means that doing memremap() or memremap_nocache() on something that may be part of the linear kernel mapping is a bug, and we should probably check for that here. We can probably avoid having both memremap() and memremap_nocache(), as all architectures define ioremap() and ioremap_nocache() to be the same thing. Arnd