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

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <CADrjBPoZM3rP3nNWvw9ca0CDBz1KOUYpGVamXYyV3o1-XQ02Bg@mail.gmail.com>
Date: Thu, 30 Oct 2025 12:59:06 +0000
From: Peter Griffin <peter.griffin@...aro.org>
To: Dan Carpenter <dan.carpenter@...aro.org>
Cc: Arnd Bergmann <arnd@...db.de>, John Madieu <john.madieu.xa@...renesas.com>, 
	Chen-Yu Tsai <wens@...nel.org>, Lee Jones <lee@...nel.org>, Conor Dooley <conor+dt@...nel.org>, 
	devicetree@...r.kernel.org, Krzysztof Kozlowski <krzk+dt@...nel.org>, 
	linux-kernel@...r.kernel.org, Rob Herring <robh@...nel.org>, 
	André Draszik <andre.draszik@...aro.org>
Subject: Re: [PATCH 0/2] mfd: syscon: introduce no-auto-mmio DT property

Hi Dan / Arnd,

Thanks for taking a look at this issue Dan!

On Thu, 30 Oct 2025 at 12:39, Dan Carpenter <dan.carpenter@...aro.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