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: <1453800262.2759.9.camel@sipsolutions.net>
Date:	Tue, 26 Jan 2016 10:24:22 +0100
From:	Johannes Berg <johannes@...solutions.net>
To:	Arnd Bergmann <arnd@...db.de>
Cc:	Mark Brown <broonie@...nel.org>, Simon Arlott <simon@...e.lp0.eu>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] Revert "regmap-mmio: Use native endianness for
 read/write"

On Tue, 2016-01-26 at 10:09 +0100, Arnd Bergmann wrote:

> Again, it's complicated: 
> 
> * We should probably add ioread64be()/iowrite64be() on *64bit*
> architectures
>   for consistency with readq/writeq

Right.

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

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

> However, we have some freedom at the regmap-mmio level, which we can
> sanitize in 4.6 if we want to make it more consistent with the rest
> of regmap. We have around 50 callers of {devm_,}regmap_init_mmio()
> and almost all of them do not specify endianess but expect little-
> endian behavior. We can change all existing instances to set
> REGMAP_ENDIAN_NATIVE explicitly and change regmap_init_mmio() to
> return an error if the caller does not specify a particular endianess
> (big, little, native). 

I'm not sure that we can, since regmap also takes the value from the DT
directly, and it seems that a driver passing it would mean the DT value
is no longer honoured?


johannes