[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <aQJR36s0cY34cLrr@stanley.mountain>
Date: Wed, 29 Oct 2025 20:41:51 +0300
From: Dan Carpenter <dan.carpenter@...aro.org>
To: Conor Dooley <conor@...nel.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 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.
regards,
dan carpenter
Powered by blists - more mailing lists
 
