linux-kernel - Re: [PATCH] Revert "mfd: syscon: Remove repetition of the regmap_get_val

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: <CAHk-=wiqN9EJ6zKXh21EQ2CV-B7_oDJKy73+yhRwtbNMWCzfVA@mail.gmail.com>
Date:   Sat, 8 Oct 2022 09:45:16 -0700
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     "Jason A. Donenfeld" <Jason@...c4.com>
Cc:     arnd@...db.de, lee@...nel.org, linux-kernel@...r.kernel.org,
        andriy.shevchenko@...ux.intel.com
Subject: Re: [PATCH] Revert "mfd: syscon: Remove repetition of the regmap_get_val_endian()"

On Sat, Oct 8, 2022 at 8:47 AM Jason A. Donenfeld <Jason@...c4.com> wrote:
>
> This reverts commit 72a95859728a7866522e6633818bebc1c2519b17. It broke
> reboots on big-endian MIPS and MIPS64 malta QEMU instances, which use
> the syscon driver. Little-endian is not effected, which means likely
> it's important to handle regmap_get_val_endian() in this function after
> all.

Hmm. The revert may indeed be the right thing to do, but we're still
early in the release process, so let's go through the channels.

I do note that commit 72a95859728a points to commit 0dbdb76c0ca8
("regmap: mmio: Parse endianness definitions from DT") as the reason
why it's not necessary any more, but that commit

 (a) doesn't seem to set config->val_format_endian (which somebody may
care about). It does set the operation pointers etc, but doesn't set
that field.

 (b) it uses regmap_get_val_endian(), which doesn't actually even look
at the OF properties unless config->val_format_endian is
REGMAP_ENDIAN_DEFAULT

so the code that commit 72a95859728a removed was actually quite a bit
different from the code in commit 0dbdb76c0ca8.

Maybe the problem is related to those semantic differences, and is
easy to fix for somebody who knows what the heck that stuff is doing.

And if not, please just send me the revert through the normal channels. Ok?

                    Linus