From: Mark Brown <broonie@kernel.org>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: linux-kernel@vger.kernel.org
Subject: [GIT PULL] regmap fix for v4.5
Date: Mon, 8 Feb 2016 13:41:51 +0000 [thread overview]
Message-ID: <20160208134151.GB7265@sirena.org.uk> (raw)
[-- Attachment #1: Type: text/plain, Size: 2457 bytes --]
The following changes since commit 92e963f50fc74041b5e9e744c330dca48e04f08d:
Linux 4.5-rc1 (2016-01-24 13:06:47 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap.git tags/regmap-fix-v4.5-big-endian
for you to fetch changes up to 320549a22484952d88d4e0320218765b16cd2174:
regmap: mmio: Revert to v4.4 endianness handling (2016-02-05 11:22:04 +0000)
----------------------------------------------------------------
regmap: mmio: Revert to v4.4 endianness handling
Commit 29bb45f25ff3 (regmap-mmio: Use native endianness for read/write)
attempted to fix some long standing bugs in the MMIO implementation for
big endian systems caused by duplicate byte swapping in both regmap and
readl()/writel() which affected MIPS systems as when they are in big
endian mode they flip the endianness of all registers in the system, not
just the CPU. MIPS systems had worked around this by declaring regmap
using IPs as little endian which is inaccurate, unfortunately the issue
had not been reported.
Sadly the fix makes things worse rather than better. By changing the
behaviour to match the documentation it caused behaviour changes for
other IPs which broke them and by using the __raw I/O accessors to avoid
the endianness swapping in readl()/writel() it removed some memory
ordering guarantees and could potentially generate unvirtualisable
instructions on some architectures.
Unfortunately sorting out all this mess in any half way sensible fashion
was far too invasive to go in during an -rc cycle so instead let's go
back to the old broken behaviour for v4.5, the better fixes are already
queued for v4.6. This does mean that we keep the broken MIPS DTs for
another release but that seems the least bad way of handling the
situation.
----------------------------------------------------------------
Mark Brown (1):
regmap: mmio: Revert to v4.4 endianness handling
arch/mips/boot/dts/brcm/bcm6328.dtsi | 1 +
arch/mips/boot/dts/brcm/bcm7125.dtsi | 1 +
arch/mips/boot/dts/brcm/bcm7346.dtsi | 1 +
arch/mips/boot/dts/brcm/bcm7358.dtsi | 1 +
arch/mips/boot/dts/brcm/bcm7360.dtsi | 1 +
arch/mips/boot/dts/brcm/bcm7362.dtsi | 1 +
arch/mips/boot/dts/brcm/bcm7420.dtsi | 1 +
arch/mips/boot/dts/brcm/bcm7425.dtsi | 1 +
arch/mips/boot/dts/brcm/bcm7435.dtsi | 1 +
drivers/base/regmap/regmap-mmio.c | 16 ++++++++--------
10 files changed, 17 insertions(+), 8 deletions(-)
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]
reply other threads:[~2016-02-08 13:42 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=20160208134151.GB7265@sirena.org.uk \
--to=broonie@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=torvalds@linux-foundation.org \
/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