mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Arnd Bergmann <arnd@arndb.de>
To: Johannes Berg <johannes@sipsolutions.net>
Cc: Mark Brown <broonie@kernel.org>, 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 14:07:58 +0100	[thread overview]
Message-ID: <1892074.6qgPEBOL6R@wuerfel> (raw)
In-Reply-To: <1453800262.2759.9.camel@sipsolutions.net>

On Tuesday 26 January 2016 10:24:22 Johannes Berg wrote:
> On Tue, 2016-01-26 at 10:09 +0100, Arnd Bergmann wrote:
> > * 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.

Ok, good.

> > 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.

I see, that's something I completely missed, and it's logical that
the reg number must be native endian for MMIO but not for everything.

	Arnd

  parent reply	other threads:[~2016-01-26 13:08 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-01-25 22:07 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
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 [this message]
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=1892074.6qgPEBOL6R@wuerfel \
    --to=arnd@arndb.de \
    --cc=broonie@kernel.org \
    --cc=johannes@sipsolutions.net \
    --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

all inboxes | Powered by JetHome®