Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752935AbbGAIKo (ORCPT ); Wed, 1 Jul 2015 04:10:44 -0400 Received: from pandora.arm.linux.org.uk ([78.32.30.218]:40238 "EHLO pandora.arm.linux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751614AbbGAIKU (ORCPT ); Wed, 1 Jul 2015 04:10:20 -0400 Date: Wed, 1 Jul 2015 09:09:15 +0100 From: Russell King - ARM Linux To: Geert Uytterhoeven Cc: Christoph Hellwig , Dan Williams , 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" Subject: Re: [PATCH v5 2/6] arch: unify ioremap prototypes and macro aliases Message-ID: <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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2770 Lines: 55 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. 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. -- FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up according to speedtest.net. -- 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/