From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756498AbcAZJYf (ORCPT ); Tue, 26 Jan 2016 04:24:35 -0500 Received: from s3.sipsolutions.net ([5.9.151.49]:38263 "EHLO sipsolutions.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751007AbcAZJYa (ORCPT ); Tue, 26 Jan 2016 04:24:30 -0500 Message-ID: <1453800262.2759.9.camel@sipsolutions.net> Subject: Re: [PATCH] Revert "regmap-mmio: Use native endianness for read/write" From: Johannes Berg To: Arnd Bergmann Cc: Mark Brown , Simon Arlott , linux-kernel@vger.kernel.org Date: Tue, 26 Jan 2016 10:24:22 +0100 In-Reply-To: <6962431.EnoXCqILtZ@wuerfel> References: <1453759675-28461-1-git-send-email-johannes@sipsolutions.net> <20160125235254.GZ6588@sirena.org.uk> <1453796736.2759.2.camel@sipsolutions.net> <6962431.EnoXCqILtZ@wuerfel> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.18.1-1 Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 2016-01-26 at 10:09 +0100, Arnd Bergmann wrote: > Again, it's complicated: > > * We should probably add ioread64be()/iowrite64be() on *64bit* > architectures >   for consistency with readq/writeq Right. > * On 32-bit architectures, you generally cannot do 64-bit atomic I/O >   operations, and we have two implementations that do it > nonatomically, >   depending on how a device is wired to the bus, see >   include/linux/io-64-nonatomic-{hi-lo,lo-hi}.h. >   I think we should just not go there for regmap unless we absolutely >   have to. regmap-mmio doesn't define the 8-bit accesses for 32-bit platforms, so this is a non-issue, I think. > There is still one open question about the defaults: I think we all > agree that there is no way we can change the default for > compatible="syscon" devices on ARM to from little-endian to cpu- > endian, as that would break everything. Annotating the MIPS dts files > as "cpu-endian" and leaving the rest to default to "little" is > probably best here. Since regmap-mmio in practice was always little endian, we should definitely make that consistent and explicit. Annotating those that need special CPU-endian handling (MIPS with the byteswap engine) would be best, I agree. Note that I made a mistake here yesterday - the *reg* for MMIO is still NATIVE, while the *value* is LITTLE_ENDIAN. Looks like regmap-core can byteswap both, which makes sense for I2C and similar busses. > However, we have some freedom at the regmap-mmio level, which we can > sanitize in 4.6 if we want to make it more consistent with the rest > of regmap. We have around 50 callers of {devm_,}regmap_init_mmio() > and almost all of them do not specify endianess but expect little- > endian behavior. We can change all existing instances to set > REGMAP_ENDIAN_NATIVE explicitly and change regmap_init_mmio() to > return an error if the caller does not specify a particular endianess > (big, little, native). I'm not sure that we can, since regmap also takes the value from the DT directly, and it seems that a driver passing it would mean the DT value is no longer honoured? johannes