linux-kernel - Re: [PATCH 1/2] dt-bindings: mfd: syscon: introduce no-auto-mmio property for syscons

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: <20251029-bleep-decipher-33b22f06b588@spud>
Date: Wed, 29 Oct 2025 22:00:42 +0000
From: Conor Dooley <conor@...nel.org>
To: Dan Carpenter <dan.carpenter@...aro.org>
Cc: Lee Jones <lee@...nel.org>, Rob Herring <robh@...nel.org>,
	Krzysztof Kozlowski <krzk+dt@...nel.org>,
	Conor Dooley <conor+dt@...nel.org>, devicetree@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/2] dt-bindings: mfd: syscon: introduce no-auto-mmio
 property for syscons

On Wed, Oct 29, 2025 at 09:47:41PM +0300, Dan Carpenter wrote:
> On Wed, Oct 29, 2025 at 06:37:26PM +0000, Conor Dooley wrote:
> > On Wed, Oct 29, 2025 at 08:41:51PM +0300, Dan Carpenter wrote:
> > > On Wed, Oct 29, 2025 at 05:33:48PM +0000, Conor Dooley wrote:
> > > > On Wed, Oct 29, 2025 at 08:27:05PM +0300, Dan Carpenter wrote:
> > > > > Generally, syscons are created automatically and accessed direclty via
> > > > > MMIO however sometimes syscons might only be accessible from the secure
> > > > > partition or through SCMI etc.  Introduce the no-auto-mmio property to
> > > > > tell the operating system that the syscon needs to be handled manually.
> > > > 
> > > > "System controller node represents a register region containing a set
> > > > of miscellaneous registers."
> > > > 
> > > > If this isn't actually a register region, but is instead an interface
> > > > provided by SCMI or whatever "secure partition" is (optee?), why is the
> > > > syscon compatible being used for the device in the first place?
> > > 
> > > In the case that I'm looking at, it really is a syscon.  So right now
> > > we're upstreaming it and it's an MMIO syscon.  Very straight forward.
> > > But later, I guess, they want to have a new firmware which will only let
> > > you access the same registers through SCMI.
> > 
> > When the programming model changes, the compatible should too, no?
> > 
> 
> I wasn't planning on it.  I haven't been asked to upstream the SCMI
> module but once my thinking was the transition would work like this.
> 
> Step 1: It would work as is with an MMIO syscon.
> Step 2: We would upstream the SCMI driver which would provide an
>         MMIO syscon as a fallback.  At that stage you would still get an
>         MMIO yscon regardless of whether the phandle was parsed before
>         or after the driver loaded.

I don't understand what step 2 even buys you here. It just seems like a
pain where you are going to have to serialise access to the register
region between two mechanisms, which is ultimately pointless if MMIO
access is permitted and you can just use that still without making a
driver change at all. Alternatively, if you're presenting the device
as a custom regmap like the samsung pmu, and can just redirect every
access into SCMI and not use MMIO at all?
The only way your stage 2 makes sense to me is, if, when you talk
about upstreaming an SCMI driver, you mean upstreaming a driver to
?an/the? SCMI project and linux wouldn't actually change during the
step at all.

> Step 3: We would set the no-auto-mmio property so you have to use the
>         driver and update the firmware so only the SCMI interface can
>         be used.

If you're going to have to change the devicetree to add this property
when the special firmware comes around and the old programming model
becomes invalid, why not just change the compatible while you're at
it? I just don't understand the reluctance to use different compatibles
for different programming models.

If the device is no longer MMIO, the reg property is not going to be
accurate anymore either, and then you have to remove the node from the
soc@foo bus to avoid warnings due to having no reg property. With both
of those changes you're looking at a pretty different device node, even
without changing the compatible.

Additionally, I don't think the property name actually reflects what it
means. "no-auto-mmio" is a direct reference to linux driver registration
implementation detail, but actually no MMIO access is even going to be
permitted at all!

Cheers,
Conor.

Download attachment "signature.asc" of type "application/pgp-signature" (229 bytes)