linux-kernel - Re: [PATCH 0/2] mfd: syscon: introduce no-auto-mmio DT property

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: <3fd4beba-0d0b-4a20-b6ed-4e00df109b66@app.fastmail.com>
Date: Wed, 29 Oct 2025 20:43:33 +0100
From: "Arnd Bergmann" <arnd@...db.de>
To: "Dan Carpenter" <dan.carpenter@...aro.org>, "Lee Jones" <lee@...nel.org>
Cc: "Conor Dooley" <conor+dt@...nel.org>, devicetree@...r.kernel.org,
 "Krzysztof Kozlowski" <krzk+dt@...nel.org>, linux-kernel@...r.kernel.org,
 "Rob Herring" <robh@...nel.org>,
 André Draszik <andre.draszik@...aro.org>,
 "Peter Griffin" <peter.griffin@...aro.org>
Subject: Re: [PATCH 0/2] mfd: syscon: introduce no-auto-mmio DT property

On Wed, Oct 29, 2025, at 18:27, Dan Carpenter wrote:
> Most syscons are accessed via MMMIO and created automatically.  But one
> example of a syscon that isn't is in drivers/soc/samsung/exynos-pmu.c
> where the syscon can only be accessed via the secure partition.  We are
> looking at upstreaming a different driver where the syscon will be
> accessed via SCMI.
>
> Normally, syscons are accessed by doing something like
> syscon_regmap_lookup_by_phandle_args() but that function will
> automatically create an MMIO syscon if one hasn't been registered.  So
> the ordering becomes a problem.  The exynos-pmu.c driver solves this
> but it's a bit awkward and it would be even trickier if there were
> several drivers accessing the same syscon.

What would happen on the current exynos platform if we just take away
the 'regs' property? I would hope that we can avoid encoding what
is essentially operating system policy in that driver and instead
just describe it as a device that expects to be implemented by
firmware and doesn't need registers?

In new syscon devices that need both cases, we can then start
doing it that way at the beginning.

    Arnd