From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933243AbcAYWr1 (ORCPT ); Mon, 25 Jan 2016 17:47:27 -0500 Received: from mezzanine.sirena.org.uk ([106.187.55.193]:46496 "EHLO mezzanine.sirena.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932251AbcAYWr0 (ORCPT ); Mon, 25 Jan 2016 17:47:26 -0500 Date: Mon, 25 Jan 2016 22:47:10 +0000 From: Mark Brown To: Arnd Bergmann Cc: Johannes Berg , Simon Arlott , linux-kernel@vger.kernel.org Message-ID: <20160125224710.GX6588@sirena.org.uk> Mail-Followup-To: Arnd Bergmann , Johannes Berg , Simon Arlott , linux-kernel@vger.kernel.org References: <1453759675-28461-1-git-send-email-johannes@sipsolutions.net> <6166456.VMAx8CBNIX@wuerfel> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="DwjXkk/QM8x7+Qsw" Content-Disposition: inline In-Reply-To: <6166456.VMAx8CBNIX@wuerfel> X-Cookie: APL hackers do it in the quad. User-Agent: Mutt/1.5.24 (2015-08-30) X-SA-Exim-Connect-IP: 2a01:348:6:8808:fab::3 X-SA-Exim-Mail-From: broonie@sirena.org.uk Subject: Re: [PATCH] Revert "regmap-mmio: Use native endianness for read/write" X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on mezzanine.sirena.org.uk) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --DwjXkk/QM8x7+Qsw Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jan 25, 2016 at 11:24:44PM +0100, Arnd Bergmann wrote: > On Monday 25 January 2016 23:07:55 Johannes Berg wrote: > > This reverts commit 29bb45f25ff3051354ed330c0d0f10418a2b8c7c. > >=20 > > Clearly, using "native" endianness is a terrible idea when > > devices are involved, since those devices are different hw Please send patches to maintainers and please use subject lines reflecting the style for the subsystem. > > Consequently, this commit broke my HummingBoard i.MX6 in big > > endian mode since it would now try to talk to the little > > endian hardware with a big endian CPU without conversion. What I'd expect to be happening here is that either the driver or the DT should be specifying the endianness of the hardware. If the device is always a given endianness then I'd expect that to turn up in the driver rather than the DT. > > What the patch really would have to do is introduce some kind > > of "device-endian" readl/writel, that takes the endianness of > > the device as an argument. That seems a bit overkill though, > > and would likely not generate any better code than the double > > byte-swaps that MIPS is getting now. The problem here is that regmap already has that functionality (it needs it for non-MMIO buses anyway) and so it knows what's going on really wants the I/O accessors to get out of the way. > This means that the devices are in fact CPU-endian, and we need > some way for Linux to represent this. The patch to > drivers/base/regmap/regmap-mmio.c is clearly wrong, as we > must never use __raw_*() accessors in an architecture independent > driver (for a number of reasons), but we still need a fix for > MIPS so it can specify a way to do the double-swap without > faking the endianess of the registers. I can't identify *anything* which says we shouldn't use the __raw accessors in architecture neutral code with the possible exception of the __. Seriously, how is anyone supposed to use this stuff if we have hidden assumptions like this? > Also, defaulting syscon to "native-endian" when nothing else is > specified sounds like a bad idea, but we may already be stuck there > with the precedent in existing bindings after 6a55244e897d > ("regmap: mmio: request native endian formatting"), we'll have > to think about that some more. Yeah, the native endian formatting is causing a lot of trouble. The MIPS folks really should also have come and talked to me rather than writing such obvious nonsense in the DT in the first place. --DwjXkk/QM8x7+Qsw Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJWpqXtAAoJECTWi3JdVIfQTTwH/jZMsKIEZ4dm59Fg0zAAhwz+ akTFMNMRdlM84fDLxbJwv/CxPH8EBTV/1ik0jEIia6GCi1Hql2+avwmd6MHX15jZ CA8ZNHY4DbsUSKV65sIDgc0rtMmQ5C9QfcQLZ+zkZho/MggJ9mQH6dNXgcpEaWZi ZODuCKkYOuW+Ysu/5A7wogC/yS3UeB9Q2y248BDZTax+/k0p9OUFQhWDWvCXPjVq pMYruuGPrYyceDSj7Eb/jGG/IjWYanDFPMP0BeZuwpywGGrp7eM6B+/K6n0n2Rc3 ljn2z7oS563JQLNQ3V8EYuVE3KxW75c2V3LHgP3q0YJh6+Tpf4c4jvuFYZInbkA= =rIGw -----END PGP SIGNATURE----- --DwjXkk/QM8x7+Qsw--