linux-kernel - Re: [PATCH] Revert "regmap-mmio: Use native endianness for read/write"

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1453796736.2759.2.camel@sipsolutions.net>
Date:	Tue, 26 Jan 2016 09:25:36 +0100
From:	Johannes Berg <johannes@...solutions.net>
To:	Mark Brown <broonie@...nel.org>
Cc:	Arnd Bergmann <arnd@...db.de>, Simon Arlott <simon@...e.lp0.eu>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] Revert "regmap-mmio: Use native endianness for
 read/write"

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