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 for Android: free password hash cracker in your pocket

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

Message-ID: <20251030-terrier-of-improbable-destiny-32ccb2@kuoka>
Date: Thu, 30 Oct 2025 09:20:36 +0100
From: Krzysztof Kozlowski <krzk@...nel.org>
To: Dan Carpenter <dan.carpenter@...aro.org>
Cc: Conor Dooley <conor@...nel.org>, 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:
> > > > "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.
> 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.

And how would it work with old DTB without that property... Sorry, but
DTS, just like hardware, is supposed to be fixed meaning it is static,
unchangeable, except bugs.

Existing DTS does not have bug in this part. You cannot change it and
keep adding properties just because you decided to do something
differently in the software.

Best regards,
Krzysztof