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.

Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
---
 Documentation/devicetree/bindings/mfd/syscon.yaml | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/Documentation/devicetree/bindings/mfd/syscon.yaml b/Documentation/devicetree/bindings/mfd/syscon.yaml
index 657c38175fba..a0ad12ae0bee 100644
--- a/Documentation/devicetree/bindings/mfd/syscon.yaml
+++ b/Documentation/devicetree/bindings/mfd/syscon.yaml
@@ -245,6 +245,10 @@ properties:
   resets:
     maxItems: 1
 
+  no-auto-mmio:
+    type: boolean
+    description: Prevents the syscon from being created automatically
+
 required:
   - compatible
   - reg
-- 
2.51.0

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.
> 
> Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
> ---
>  Documentation/devicetree/bindings/mfd/syscon.yaml | 4 ++++
>  1 file changed, 4 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/mfd/syscon.yaml b/Documentation/devicetree/bindings/mfd/syscon.yaml
> index 657c38175fba..a0ad12ae0bee 100644
> --- a/Documentation/devicetree/bindings/mfd/syscon.yaml
> +++ b/Documentation/devicetree/bindings/mfd/syscon.yaml
> @@ -245,6 +245,10 @@ properties:
>    resets:
>      maxItems: 1
>  
> +  no-auto-mmio:
> +    type: boolean
> +    description: Prevents the syscon from being created automatically

"syscon" literally means "have Linux create a regmap for me". If you 
don't want that, don't use the "syscon" compatible. Really, I wish we'd 
never added it in the first place.

Rob

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?

Cheers,
Conor.

> Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
> ---
>  Documentation/devicetree/bindings/mfd/syscon.yaml | 4 ++++
>  1 file changed, 4 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/mfd/syscon.yaml b/Documentation/devicetree/bindings/mfd/syscon.yaml
> index 657c38175fba..a0ad12ae0bee 100644
> --- a/Documentation/devicetree/bindings/mfd/syscon.yaml
> +++ b/Documentation/devicetree/bindings/mfd/syscon.yaml
> @@ -245,6 +245,10 @@ properties:
>    resets:
>      maxItems: 1
>  
> +  no-auto-mmio:
> +    type: boolean
> +    description: Prevents the syscon from being created automatically
> +
>  required:
>    - compatible
>    - reg
> -- 
> 2.51.0
> 

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

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?

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.
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.

regards,
dan carpenter

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

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.