Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752876AbbGAQrk (ORCPT ); Wed, 1 Jul 2015 12:47:40 -0400 Received: from mail-wi0-f173.google.com ([209.85.212.173]:33801 "EHLO mail-wi0-f173.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751042AbbGAQrd (ORCPT ); Wed, 1 Jul 2015 12:47:33 -0400 MIME-Version: 1.0 In-Reply-To: <20150701080915.GJ7557@n2100.arm.linux.org.uk> References: <20150622081028.35954.89885.stgit@dwillia2-desk3.jf.intel.com> <20150622082427.35954.73529.stgit@dwillia2-desk3.jf.intel.com> <20150622161002.GB8240@lst.de> <20150701062352.GA3739@lst.de> <20150701080915.GJ7557@n2100.arm.linux.org.uk> Date: Wed, 1 Jul 2015 09:47:31 -0700 Message-ID: Subject: Re: [PATCH v5 2/6] arch: unify ioremap prototypes and macro aliases From: Dan Williams To: Russell King - ARM Linux Cc: Geert Uytterhoeven , Christoph Hellwig , Arnd Bergmann , Ingo Molnar , Borislav Petkov , "H. Peter Anvin" , Thomas Gleixner , Ross Zwisler , Andrew Morton , Juergen Gross , X86 ML , "Kani, Toshimitsu" , "linux-nvdimm@lists.01.org" , Benjamin Herrenschmidt , Luis Rodriguez , Konrad Rzeszutek Wilk , "linux-kernel@vger.kernel.org" , Stefan Bader , Andy Lutomirski , Linux MM , Ralf Baechle , Henrique de Moraes Holschuh , Michael Ellerman , Tejun Heo , Paul Mackerras , "linux-arm-kernel@lists.infradead.org" Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3110 Lines: 61 On Wed, Jul 1, 2015 at 1:09 AM, Russell King - ARM Linux wrote: > On Wed, Jul 01, 2015 at 08:55:57AM +0200, Geert Uytterhoeven wrote: >> On Wed, Jul 1, 2015 at 8:23 AM, Christoph Hellwig wrote: >> >> One useful feature of the ifdef mess as implemented in the patch is >> >> that you could test for whether ioremap_cache() is actually >> >> implemented or falls back to default ioremap(). I think for >> >> completeness archs should publish an ioremap type capabilities mask >> >> for drivers that care... (I can imagine pmem caring), or default to >> >> being permissive if something like IOREMAP_STRICT is not set. There's >> >> also the wrinkle of archs that can only support certain types of >> >> mappings at a given alignment. >> > >> > I think doing this at runtime might be a better idea. E.g. a >> > ioremap_flags with the CACHED argument will return -EOPNOTSUP unless >> > actually implemented. On various architectures different CPUs or >> > boards will have different capabilities in this area. >> >> So it would be the responsibility of the caller to fall back from >> ioremap(..., CACHED) to ioremap(..., UNCACHED)? >> I.e. all drivers using it should be changed... > > Another important point here is to define what the properties of the > mappings are. It's no good just saying "uncached". > > We've recently been around this over the PMEM driver and the broken > addition of ioremap_wt() on ARM... > > By "properties" I mean stuff like whether unaligned accesses permitted, > any kind of atomic access (eg, xchg, cmpxchg, etc). > > This matters: on ARM, a mapping suitable for a device does not support > unaligned accesses or atomic accesses - only "memory-like" mappings > support those. However, memory-like mappings are not required to > preserve access size, number of accesses, etc which makes them unsuitable > for device registers. I'm proposing that we explicitly switch "memory-like" use cases over to a separate set of "memremap()" apis, as these are no longer "__iomem" [1]. > The problem with ioremap_uncached() in particular is that we have LDD > and other documentation telling people to use it to map device registers, > so we can't define ioremap_uncached() on ARM to have memory-like > properties, and it doesn't support unaligned accesses. > > I have a series of patches which fix up 32-bit ARM for the broken > ioremap_wt() stuff that was merged during this merge window, which I > intend to push out into linux-next at some point (possibly during the > merge window, if not after -rc1) which also move ioremap*() out of line > on ARM but more importantly, adds a load of documentation about the > properties of the resulting mapping on ARM. Sounds good, I'll look for that before proceeding on this clean up. [1]: https://lists.01.org/pipermail/linux-nvdimm/2015-June/001331.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/