linux-kernel - Re: [PATCH v2 2/3] mfd: syscon: Remove the platform driver support

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] [day] [month] [year] [list]

Message-ID: <20251012133337.GA897177@robin.jannau.net>
Date: Sun, 12 Oct 2025 15:33:37 +0200
From: Janne Grunau <j@...nau.net>
To: "Rob Herring (Arm)" <robh@...nel.org>,
	Herve Codina <herve.codina@...tlin.com>
Cc: Lee Jones <lee@...nel.org>, Arnd Bergmann <arnd@...db.de>,
	Pankaj Dubey <pankaj.dubey@...sung.com>,
	Heiko Stuebner <heiko@...ech.de>, Liviu Dudau <liviu.dudau@....com>,
	Sudeep Holla <sudeep.holla@....com>,
	Lorenzo Pieralisi <lpieralisi@...nel.org>,
	Peter Griffin <peter.griffin@...aro.org>,
	Will McVicker <willmcvicker@...gle.com>,
	John Madieu <john.madieu.xa@...renesas.com>,
	Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>,
	linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
	asahi@...ts.linux.dev
Subject: Re: [PATCH v2 2/3] mfd: syscon: Remove the platform driver support

On Tue, Dec 17, 2024 at 12:11:41PM -0600, Rob Herring (Arm) wrote:
> The platform driver is dead code. It is not used by DT platforms since
> commit bdb0066df96e ("mfd: syscon: Decouple syscon interface from
> platform devices") which said:
> 
>     For non-DT based platforms, this patch keeps syscon platform driver
>     structure so that syscon can be probed and such non-DT based drivers
>     can use syscon_regmap_lookup_by_pdev API and access regmap handles.
>     Once all users of "syscon_regmap_lookup_by_pdev" migrated to DT based,
>     we can completely remove platform driver of syscon, and keep only helper
>     functions to get regmap handles.
> 
> The last user of syscon_regmap_lookup_by_pdevname() was removed in 2018.
> syscon_regmap_lookup_by_pdevname() was then removed in 2019, but that
> commit failed to remove the rest of the platform driver.

This removed the only driver claiming pmgr nodes on Apple silicon
platforms. The nodes use compatible strings of the form

compatible = "apple,t8103-pmgr", "apple,pmgr", "syscon", "simple-mfd";

The description still holds as the removal of the driver did not result
in functional changes and went unnoticed. The missing driver became 
apparent with pmdomain's sync_state() support in 6.17 which prints
following messages on a M1 mac mini

| [   11.789419] apple-pmgr-pwrstate 23b700000.power-management:power-controller@420: sync_state() pending due to 23d280000.power-management
| [   11.792414] apple-pmgr-pwrstate 23b700000.power-management:power-controller@448: sync_state() pending due to 23d280000.power-management

None of the other compatible are claimed by any driver. There is no
driver for "apple,t8103-pmgr" or "apple,pmgr" and simple-pm-bus.c binds
"simple-mfd" only if it is the first compatible string.

The easiest solution would be to probe via simple-pm-bus.c if the device
is compatible with "apple,pmgr". The generic compatible is justified by
not having any device specific code. The other option would by to add
the growing list of SoC specific "apple,*-pmgr" compatibles to the match
table.
The alternative of writing an Apple pmgr driver which does nothing
except successfully probing devices does not look appealing.

There is second problem though. The device link between
23b700000.power-management:power-controller@420 and
23d280000.power-management should not exist in the first place. See
following excerpt from arch/arm64/boot/dts/apple/{t8103,t8103-pmgr}.dtsi
omitting only unrelated child nodes.

/ {
	pmgr: power-management@...700000 {
		compatible = "apple,t8103-pmgr", "apple,pmgr", "syscon", "simple-mfd";
		#address-cells = <1>;
		#size-cells = <1>;
		reg = <0x2 0x3b700000 0 0x14000>;

		ps_atc0_common: power-controller@420 {
			compatible = "apple,t8103-pmgr-pwrstate", "apple,pmgr-pwrstate";
			reg = <0x420 4>;
			#power-domain-cells = <0>;
			#reset-cells = <0>;
			label = "atc0_common";
		};
	};

	pmgr_mini: power-management@...280000 {
		compatible = "apple,t8103-pmgr", "apple,pmgr", "syscon", "simple-mfd";
		#address-cells = <1>;
		#size-cells = <1>;
		reg = <0x2 0x3d280000 0 0x4000>;

		ps_atc0_usb: power-controller@98 {
			compatible = "apple,t8103-pmgr-pwrstate", "apple,pmgr-pwrstate";
			reg = <0x98 4>;
			#power-domain-cells = <0>;
			#reset-cells = <0>;
			label = "atc0_usb";
			power-domains = <&ps_atc0_usb_aon>, <&ps_atc0_common>;
		};
	};
}

To my understanding the fw_devlinks should only exists between
&ps_atc0_common and &ps_atc0_usb. Herve Codina reports and posts a patch
for what sounds to be the same issue in [1] for simple-pm-bus. I can't
reproduce the report though. As soon as simple-pm-bus successfully
probes the pmgr devices the spurious devlinks are gone.

So I think this needs to be fixed in either of/platform.c for all
devices handled in of_platform_default_populate() or in
driver-core/devlink considering the issue appears without driver for the
bus device.

Janne

[1]: https://lore.kernel.org/lkml/20250613134817.681832-6-herve.codina@bootlin.com/