From: Mark Brown <broonie@kernel.org>
To: Arnd Bergmann <arnd@arndb.de>
Cc: Johannes Berg <johannes@sipsolutions.net>,
Simon Arlott <simon@fire.lp0.eu>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] Revert "regmap-mmio: Use native endianness for read/write"
Date: Mon, 25 Jan 2016 22:47:10 +0000 [thread overview]
Message-ID: <20160125224710.GX6588@sirena.org.uk> (raw)
In-Reply-To: <6166456.VMAx8CBNIX@wuerfel>
[-- Attachment #1: Type: text/plain, Size: 2543 bytes --]
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.
> >
> > 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.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]
next prev parent reply other threads:[~2016-01-25 22:47 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
2016-01-26 11:31 ` Mark Brown
2016-01-25 22:47 ` Mark Brown [this message]
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=20160125224710.GX6588@sirena.org.uk \
--to=broonie@kernel.org \
--cc=arnd@arndb.de \
--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®