From: Janne Grunau <j@jannau.net>
To: "Rob Herring (Arm)" <robh@kernel.org>,
Herve Codina <herve.codina@bootlin.com>
Cc: Lee Jones <lee@kernel.org>, Arnd Bergmann <arnd@arndb.de>,
Pankaj Dubey <pankaj.dubey@samsung.com>,
Heiko Stuebner <heiko@sntech.de>,
Liviu Dudau <liviu.dudau@arm.com>,
Sudeep Holla <sudeep.holla@arm.com>,
Lorenzo Pieralisi <lpieralisi@kernel.org>,
Peter Griffin <peter.griffin@linaro.org>,
Will McVicker <willmcvicker@google.com>,
John Madieu <john.madieu.xa@bp.renesas.com>,
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, asahi@lists.linux.dev
Subject: Re: [PATCH v2 2/3] mfd: syscon: Remove the platform driver support
Date: Sun, 12 Oct 2025 15:33:37 +0200 [thread overview]
Message-ID: <20251012133337.GA897177@robin.jannau.net> (raw)
In-Reply-To: <20241217-syscon-fixes-v2-2-4f56d750541d@kernel.org>
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@23b700000 {
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@23d280000 {
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/
next prev parent reply other threads:[~2025-10-12 13:33 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-12-17 18:11 [PATCH v2 0/3] mfd: syscon: Cleanup, fix race condition and remove platform driver Rob Herring (Arm)
2024-12-17 18:11 ` [PATCH v2 1/3] mfd: syscon: Fix race in device_node_get_regmap() Rob Herring (Arm)
2024-12-17 19:35 ` William McVicker
2024-12-23 2:11 ` Pankaj Dubey
2024-12-23 2:14 ` Pankaj Dubey
2024-12-17 18:11 ` [PATCH v2 2/3] mfd: syscon: Remove the platform driver support Rob Herring (Arm)
2024-12-17 19:36 ` William McVicker
2024-12-18 10:10 ` Liviu Dudau
2024-12-23 2:13 ` Pankaj Dubey
2024-12-23 14:59 ` Krzysztof Kozlowski
2025-10-12 13:33 ` Janne Grunau [this message]
2024-12-17 18:11 ` [PATCH v2 3/3] mfd: syscon: Allow syscon nodes without a "syscon" compatible Rob Herring (Arm)
2024-12-17 19:37 ` William McVicker
2024-12-23 2:16 ` Pankaj Dubey
2024-12-23 15:02 ` Krzysztof Kozlowski
2025-01-22 9:43 ` Vaishnav Achath
2025-01-24 20:03 ` Rob Herring
2025-01-09 11:12 ` [PATCH v2 0/3] mfd: syscon: Cleanup, fix race condition and remove platform driver Lee Jones
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20251012133337.GA897177@robin.jannau.net \
--to=j@jannau.net \
--cc=arnd@arndb.de \
--cc=asahi@lists.linux.dev \
--cc=heiko@sntech.de \
--cc=herve.codina@bootlin.com \
--cc=john.madieu.xa@bp.renesas.com \
--cc=krzysztof.kozlowski@linaro.org \
--cc=lee@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=liviu.dudau@arm.com \
--cc=lpieralisi@kernel.org \
--cc=pankaj.dubey@samsung.com \
--cc=peter.griffin@linaro.org \
--cc=robh@kernel.org \
--cc=sudeep.holla@arm.com \
--cc=willmcvicker@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®