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

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

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);

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

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

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

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

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

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
>

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
>

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>

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