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

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

[Dan Carpenter]

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.

Dan Carpenter (2):
  dt-bindings: mfd: syscon: introduce no-auto-mmio property for syscons
  mfd: syscon: Don't auto create "no-auto-mmio" syscons

 Documentation/devicetree/bindings/mfd/syscon.yaml |  4 ++++
 drivers/mfd/syscon.c                              | 10 ++++++++--
 2 files changed, 12 insertions(+), 2 deletions(-)

-- 
2.51.0

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

[Dan Carpenter]

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

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

[Conor Dooley]

[-- Attachment #1: Type: text/plain, Size: 1407 bytes --]

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
> 

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

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

[Dan Carpenter]

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

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

[Conor Dooley]

[-- Attachment #1: Type: text/plain, Size: 1198 bytes --]

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?


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

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

[Dan Carpenter]

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

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

[Conor Dooley]

[-- Attachment #1: Type: text/plain, Size: 3631 bytes --]

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.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

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

[Krzysztof Kozlowski]

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

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

[Rob Herring]

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

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

[Arnd Bergmann]

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

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

[Dan Carpenter]

On Wed, Oct 29, 2025 at 08:43:33PM +0100, Arnd Bergmann wrote:
> 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?

Exynos solves this because they only have one phandle so when they parse
it, that's when then they create the syscon.  If you had multiple drivers
accessing the same syscon then that doesn't work.

If we left out the "regs" property it wouldn't be created automatically
but syscon_regmap_lookup_by_phandle() will return -EINVAL and probe would
fail.  It needs to be -EPROBE_DEFER so the probe tries again after the
regmap is registered.  We'd need to add a check like this (untested):

I can test this probably later today when the test system is back.

regards,
dan carpenter

diff --git a/drivers/mfd/syscon.c b/drivers/mfd/syscon.c
index ae71a2710bed..41da49a0c767 100644
--- a/drivers/mfd/syscon.c
+++ b/drivers/mfd/syscon.c
@@ -51,6 +51,9 @@ static struct syscon *of_syscon_register(struct device_node *np, bool check_res)
 
 	WARN_ON(!mutex_is_locked(&syscon_list_lock));
 
+	if (!of_find_property(np, "regs", NULL))
+		return ERR_PTR(-EPROBE_DEFER);
+
 	struct syscon *syscon __free(kfree) = kzalloc(sizeof(*syscon), GFP_KERNEL);
 	if (!syscon)
 		return ERR_PTR(-ENOMEM);

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

[Arnd Bergmann]

On Thu, Oct 30, 2025, at 08:33, Dan Carpenter wrote:
> On Wed, Oct 29, 2025 at 08:43:33PM +0100, Arnd Bergmann wrote:
>> 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?
>
> Exynos solves this because they only have one phandle so when they parse
> it, that's when then they create the syscon.  If you had multiple drivers
> accessing the same syscon then that doesn't work.

I'm not following the logic here.  Do you mean that they avoid the
issue today by ensuring that the regmap is always probed before
its only user, or do you mean something else?

> If we left out the "regs" property it wouldn't be created automatically
> but syscon_regmap_lookup_by_phandle() will return -EINVAL and probe would
> fail.  It needs to be -EPROBE_DEFER so the probe tries again after the
> regmap is registered.  We'd need to add a check like this (untested):

Right, this is exactly what I had in mind. With a new kernel and old
dtb, this would not change anything, while an old kernel but new dtb
would run into a different bug and fail to probe instead of using the
wrong device. I think both cases are fine.

     Arnd

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

[Dan Carpenter]

On Thu, Oct 30, 2025 at 09:33:39AM +0100, Arnd Bergmann wrote:
> On Thu, Oct 30, 2025, at 08:33, Dan Carpenter wrote:
> > On Wed, Oct 29, 2025 at 08:43:33PM +0100, Arnd Bergmann wrote:
> >> 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?
> >
> > Exynos solves this because they only have one phandle so when they parse
> > it, that's when then they create the syscon.  If you had multiple drivers
> > accessing the same syscon then that doesn't work.
> 
> I'm not following the logic here.  Do you mean that they avoid the
> issue today by ensuring that the regmap is always probed before
> its only user, or do you mean something else?

Yes.  That's what I mean.

regards,
dan carpenter

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

[Dan Carpenter]

On Thu, Oct 30, 2025 at 09:33:39AM +0100, Arnd Bergmann wrote:
> On Thu, Oct 30, 2025, at 08:33, Dan Carpenter wrote:
> > On Wed, Oct 29, 2025 at 08:43:33PM +0100, Arnd Bergmann wrote:
> >> 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?
> >
> > Exynos solves this because they only have one phandle so when they parse
> > it, that's when then they create the syscon.  If you had multiple drivers
> > accessing the same syscon then that doesn't work.
> 
> I'm not following the logic here.  Do you mean that they avoid the
> issue today by ensuring that the regmap is always probed before
> its only user, or do you mean something else?
> 
> > If we left out the "regs" property it wouldn't be created automatically
> > but syscon_regmap_lookup_by_phandle() will return -EINVAL and probe would
> > fail.  It needs to be -EPROBE_DEFER so the probe tries again after the
> > regmap is registered.  We'd need to add a check like this (untested):
> 
> Right, this is exactly what I had in mind. With a new kernel and old
> dtb, this would not change anything, while an old kernel but new dtb
> would run into a different bug and fail to probe instead of using the
> wrong device. I think both cases are fine.
> 
>      Arnd

Actually, probably the right thing to do is to leave out the "syscon"
compatible.  That's what the drivers/soc/sunxi/sunxi_sram.c driver does.
There is still an ordering issue where the sunxi_sram SoC driver needs
to be probed first or the stmmac driver probe will fail.  There is probably
some kind of way that SoC drivers are always probed earlier?

Beside the exynos driver the only other place that calls
of_syscon_register_regmap() is drivers/soc/renesas/rz-sysc.c but I don't
think that syscon has any users yet.

regards,
dan carpenter

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

[Chen-Yu Tsai]

On Thu, Oct 30, 2025 at 8:39 PM Dan Carpenter <dan.carpenter@linaro.org> wrote:
>
> On Thu, Oct 30, 2025 at 09:33:39AM +0100, Arnd Bergmann wrote:
> > On Thu, Oct 30, 2025, at 08:33, Dan Carpenter wrote:
> > > On Wed, Oct 29, 2025 at 08:43:33PM +0100, Arnd Bergmann wrote:
> > >> 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?
> > >
> > > Exynos solves this because they only have one phandle so when they parse
> > > it, that's when then they create the syscon.  If you had multiple drivers
> > > accessing the same syscon then that doesn't work.
> >
> > I'm not following the logic here.  Do you mean that they avoid the
> > issue today by ensuring that the regmap is always probed before
> > its only user, or do you mean something else?
> >
> > > If we left out the "regs" property it wouldn't be created automatically
> > > but syscon_regmap_lookup_by_phandle() will return -EINVAL and probe would
> > > fail.  It needs to be -EPROBE_DEFER so the probe tries again after the
> > > regmap is registered.  We'd need to add a check like this (untested):
> >
> > Right, this is exactly what I had in mind. With a new kernel and old
> > dtb, this would not change anything, while an old kernel but new dtb
> > would run into a different bug and fail to probe instead of using the
> > wrong device. I think both cases are fine.
> >
> >      Arnd
>
> Actually, probably the right thing to do is to leave out the "syscon"
> compatible.  That's what the drivers/soc/sunxi/sunxi_sram.c driver does.
> There is still an ordering issue where the sunxi_sram SoC driver needs
> to be probed first or the stmmac driver probe will fail.  There is probably
> some kind of way that SoC drivers are always probed earlier?

Yeah. The syscon API still needs to be modified to return -EPROBE_DEFER
to be complete. In our case the failure is unlikely to happen.

On sunxi, the SRAM controller block just happens to be at the beginning
of the MMIO address space, and being at the top of the device tree, lets
it be the first driver to be probed. Unless someone made it a module and
the rootfs wasn't available yet.

Also, in the past, on most devices we were actually using dev_get_regmap()
to retrieve the regmap tied to the device. I think it _may_ be an abuse
of the API? We did have one platform that had no driver for the block
that had the registers the stmmac driver needed, so that one was indeed
a syscon, which is why the dwmac-sun8i driver tries both methods.


ChenYu

> Beside the exynos driver the only other place that calls
> of_syscon_register_regmap() is drivers/soc/renesas/rz-sysc.c but I don't
> think that syscon has any users yet.
>
> regards,
> dan carpenter

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

[Dan Carpenter]

Yeah.  Let me send this tommorrow if no one objects.  Pretty simple
solution in retrospect.

[PATCH] mfd: syscon: Return -EPROBE_DEFER in device_node_get_regmap()

These days we can register syscons with of_syscon_register_regmap() so
if we can't find the syscon that probably means it hasn't been registered
yet.  Return -EPROBE_DEFER so the driver will try probing again.

Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
---
 drivers/mfd/syscon.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/mfd/syscon.c b/drivers/mfd/syscon.c
index ae71a2710bed..e5d5def594f6 100644
--- a/drivers/mfd/syscon.c
+++ b/drivers/mfd/syscon.c
@@ -183,7 +183,7 @@ static struct regmap *device_node_get_regmap(struct device_node *np,
 		if (create_regmap)
 			syscon = of_syscon_register(np, check_res);
 		else
-			syscon = ERR_PTR(-EINVAL);
+			syscon = ERR_PTR(-EPROBE_DEFER);
 	}
 	mutex_unlock(&syscon_list_lock);
 
-- 
2.51.0

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

[Arnd Bergmann]

On Thu, Oct 30, 2025, at 14:09, Dan Carpenter wrote:
> Yeah.  Let me send this tommorrow if no one objects.  Pretty simple
> solution in retrospect.
>
> [PATCH] mfd: syscon: Return -EPROBE_DEFER in device_node_get_regmap()
>
> These days we can register syscons with of_syscon_register_regmap() so
> if we can't find the syscon that probably means it hasn't been registered
> yet.  Return -EPROBE_DEFER so the driver will try probing again.
>
> Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>

This clearly needs some testing, but I like it!

Reviewed-by: Arnd Bergmann <arnd@arndb.de>

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

[Chen-Yu Tsai]

On Thu, Oct 30, 2025 at 9:10 PM Dan Carpenter <dan.carpenter@linaro.org> wrote:
>
> Yeah.  Let me send this tommorrow if no one objects.  Pretty simple
> solution in retrospect.
>
> [PATCH] mfd: syscon: Return -EPROBE_DEFER in device_node_get_regmap()
>
> These days we can register syscons with of_syscon_register_regmap() so
> if we can't find the syscon that probably means it hasn't been registered
> yet.  Return -EPROBE_DEFER so the driver will try probing again.
>
> Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>

Reviewed-by: Chen-Yu Tsai <wens@kernel.org>

I'd also like to say I tested it since I have the same change in my local
branch, but as I said before the case doesn't really happen on sunxi.

ChenYu

> ---
>  drivers/mfd/syscon.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/mfd/syscon.c b/drivers/mfd/syscon.c
> index ae71a2710bed..e5d5def594f6 100644
> --- a/drivers/mfd/syscon.c
> +++ b/drivers/mfd/syscon.c
> @@ -183,7 +183,7 @@ static struct regmap *device_node_get_regmap(struct device_node *np,
>                 if (create_regmap)
>                         syscon = of_syscon_register(np, check_res);
>                 else
> -                       syscon = ERR_PTR(-EINVAL);
> +                       syscon = ERR_PTR(-EPROBE_DEFER);
>         }
>         mutex_unlock(&syscon_list_lock);
>
> --
> 2.51.0
>

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

[Rob Herring]

On Thu, Oct 30, 2025 at 04:09:52PM +0300, Dan Carpenter wrote:
> Yeah.  Let me send this tommorrow if no one objects.  Pretty simple
> solution in retrospect.
> 
> [PATCH] mfd: syscon: Return -EPROBE_DEFER in device_node_get_regmap()
> 
> These days we can register syscons with of_syscon_register_regmap() so
> if we can't find the syscon that probably means it hasn't been registered
> yet.  Return -EPROBE_DEFER so the driver will try probing again.
> 
> Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
> ---
>  drivers/mfd/syscon.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 

Acked-by: Rob Herring (Arm) <robh@kernel.org>

> diff --git a/drivers/mfd/syscon.c b/drivers/mfd/syscon.c
> index ae71a2710bed..e5d5def594f6 100644
> --- a/drivers/mfd/syscon.c
> +++ b/drivers/mfd/syscon.c
> @@ -183,7 +183,7 @@ static struct regmap *device_node_get_regmap(struct device_node *np,
>  		if (create_regmap)
>  			syscon = of_syscon_register(np, check_res);
>  		else
> -			syscon = ERR_PTR(-EINVAL);
> +			syscon = ERR_PTR(-EPROBE_DEFER);
>  	}
>  	mutex_unlock(&syscon_list_lock);
>  
> -- 
> 2.51.0
> 

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

[Peter Griffin]

Hi Dan / Arnd,

Thanks for taking a look at this issue Dan!

On Thu, 30 Oct 2025 at 12:39, Dan Carpenter <dan.carpenter@linaro.org> wrote:
>
> On Thu, Oct 30, 2025 at 09:33:39AM +0100, Arnd Bergmann wrote:
> > On Thu, Oct 30, 2025, at 08:33, Dan Carpenter wrote:
> > > On Wed, Oct 29, 2025 at 08:43:33PM +0100, Arnd Bergmann wrote:
> > >> 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?
> > >
> > > Exynos solves this because they only have one phandle so when they parse
> > > it, that's when then they create the syscon.  If you had multiple drivers
> > > accessing the same syscon then that doesn't work.

It's slightly more nuanced than that. Exynos has multiple users of the
PMU syscon (Watchdog/various Phys drivers etc). But the ordering there
is enforced there by initcall levels. The "only user" of the
exynos_get_pmu_regmap() is pinctrl driver which is the same initcall
level as exynos-pmu.

> >
> > I'm not following the logic here.  Do you mean that they avoid the
> > issue today by ensuring that the regmap is always probed before
> > its only user, or do you mean something else?
> >
> > > If we left out the "regs" property it wouldn't be created automatically
> > > but syscon_regmap_lookup_by_phandle() will return -EINVAL and probe would
> > > fail.  It needs to be -EPROBE_DEFER so the probe tries again after the
> > > regmap is registered.  We'd need to add a check like this (untested):

Leaving out the "regs" property and adding the -EPROBE_DEFER check
seems like a neat solution to me. I would like to see -EPROBE_DEFER
for custom syscon regmap well supported, so we can modularize all the
drivers that are currently builtin when ARCH_EXYNOS is selected.

> >
> > Right, this is exactly what I had in mind. With a new kernel and old
> > dtb, this would not change anything, while an old kernel but new dtb
> > would run into a different bug and fail to probe instead of using the
> > wrong device. I think both cases are fine.
> >
> >      Arnd
>
> Actually, probably the right thing to do is to leave out the "syscon"
> compatible.  That's what the drivers/soc/sunxi/sunxi_sram.c driver does.
> There is still an ordering issue where the sunxi_sram SoC driver needs
> to be probed first or the stmmac driver probe will fail.  There is probably
> some kind of way that SoC drivers are always probed earlier?

IIUC that would avoid creating a MMIO syscon, but wouldn't solve the
-EPROBE_DEFER part of it?

regards,

Peter