From: Johannes Berg <johannes@sipsolutions.net>
To: Mark Brown <broonie@kernel.org>
Cc: Arnd Bergmann <arnd@arndb.de>, Simon Arlott <simon@fire.lp0.eu>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] Revert "regmap-mmio: Use native endianness for read/write"
Date: Tue, 26 Jan 2016 09:25:36 +0100 [thread overview]
Message-ID: <1453796736.2759.2.camel@sipsolutions.net> (raw)
In-Reply-To: <20160125235254.GZ6588@sirena.org.uk>
On Mon, 2016-01-25 at 23:52 +0000, Mark Brown wrote:
> - Make the default for MMIO regmaps be explicitly little endian with
> either an ifdef for MIPS to keep it working or an explict native
> endianness tag in the DT instead of the straight revert to LE (the
> latter seems better).
This makes sense, and I agree that the latter is better.
> - Convert the MMIO regmap to use reg_read() and reg_write() with
> implementations using either readX() or ioread_*be() and
> equivalents for write. This means the core does no endianness
> swapping and it's all in the bus.
I don't think there's ioread64be/iowrite64be, and I'm also not entirely
sure how that works since it uses __raw_* internally in lib/iomap.c?
> Unfortunately that all sounds a bit too big for v4.5... perhaps a
> combination of a revert of the implementation and the addition of the
> native tag to the DT for v4.5 followed by the reworking of the bus
> for v4.6, I really would rather keep the DT change in v4.5 since
> specifying LE is just bad and we don't want that to propagate any
> more than it has to.
Yes, that makes sense.
> From this I also conclude that we need to improve our testing of big
> endian ARM systems since nobody managed to notice this all the time
> this was cooking in -next.
To my knowledge before I did a couple of days ago nobody ever ran i.MX6
in big endian mode :)
johannes
next prev parent reply other threads:[~2016-01-26 8:25 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-01-25 22:07 [PATCH] Revert "regmap-mmio: Use native endianness for read/write" Johannes Berg
2016-01-25 22:24 ` Arnd Bergmann
2016-01-25 22:34 ` Johannes Berg
2016-01-25 23:52 ` Mark Brown
2016-01-26 8:25 ` Johannes Berg [this message]
2016-01-26 9:09 ` Arnd Bergmann
2016-01-26 9:24 ` Johannes Berg
2016-01-26 11:36 ` Mark Brown
2016-01-26 13:16 ` Arnd Bergmann
2016-01-26 13:20 ` Johannes Berg
2016-01-26 15:23 ` Mark Brown
2016-01-26 21:29 ` Mark Brown
2016-01-26 20:05 ` Mark Brown
2016-01-26 13:07 ` Arnd Bergmann
2016-01-26 11:31 ` Mark Brown
2016-01-25 22:47 ` Mark Brown
2016-01-25 23:01 ` Arnd Bergmann
2016-01-26 11:31 ` Mark Brown
2016-01-25 22:56 ` Mark Brown
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1453796736.2759.2.camel@sipsolutions.net \
--to=johannes@sipsolutions.net \
--cc=arnd@arndb.de \
--cc=broonie@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=simon@fire.lp0.eu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox