From: Lukasz Luba <lukasz.luba@arm.com>
To: Daniel Lezcano <daniel.lezcano@oss.qualcomm.com>
Cc: Daniel Lezcano <daniel.lezcano@kernel.org>,
rafael@kernel.org, Heiko Stuebner <heiko@sntech.de>,
Shuah Khan <shuah@kernel.org>,
Manaf Meethalavalappu Pallikunhi
<manaf.pallikunhi@oss.qualcomm.com>,
linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-rockchip@lists.infradead.org,
linux-kselftest@vger.kernel.org
Subject: Re: [PATCH v4 4/6] powercap: dtpm: Use generic powercap hierarchy helpers
Date: Mon, 2 Nov 2026 09:57:20 +0000 [thread overview]
Message-ID: <3005f6f5-3b6a-4139-a170-1f60d93c9902@arm.com> (raw)
In-Reply-To: <f34635d2ce1d5c741968708e6349f7f059b03173.1793288783.git.daniel.lezcano@oss.qualcomm.com>
Hi Daniel,
On 10/29/26 16:56, Daniel Lezcano wrote:
> DTPM implements its own hierarchy creation and destruction logic while
> the powercap core now provides generic helpers for this purpose.
>
> Convert DTPM to use the generic powercap hierarchy infrastructure.
> Duplicate the platform hierarchy before creating it, and use
> powercap_hierarchy_create() and powercap_hierarchy_destroy() to manage
> the DTPM zones.
>
> Add DTPM callbacks to create and destroy the zones associated with each
> powercap hierarchy node. Adapt the CPU and devfreq backends to return
> the created DTPM instance and use the node name provided by the
> hierarchy.
>
> Convert the Rockchip RK3399 description to struct powercap_hierarchy
> and keep the device tree path as DTPM-specific node data.
>
> This removes the DTPM-specific hierarchy traversal and destruction code
> and leaves the hierarchy management to the powercap core.
>
> Preserve best-effort creation: an unavailable backend returns NULL to
> skip its branch, and setup failures are warned about and skipped rather
> than rolling back independent zones. Invalid node descriptors remain
> fatal.
>
> When the representative CPU is offline, find an active policy through an
> online sibling whose related_cpus mask contains it. Hold the CPU hotplug
> read lock during selection and setup, and initialize the zone through the
> policy's active CPU while keeping the hierarchy-provided name. An entirely
> offline policy still has no active CPU to initialize through.
>
> Signed-off-by: Daniel Lezcano <daniel.lezcano@oss.qualcomm.com>
> ---
> Changes in v4 (since v3):
> - Rebase on v7.3; no code or commit-description changes.
>
> Changes in v3 (since v2):
> - Rebase on v7.3-rc7.
> - Preserve best-effort branch creation using the generic NULL result.
> - Find an online policy sibling for offline CPU representatives and
> protect policy selection and setup against CPU hotplug.
> - Keep generic API behavior and documentation in patch 1.
> - Fix __initdata placement; match-table indentation is handled in patch 3.
> - Name setup callback arguments and remove whitespace-only lines.
> - Update the description.
>
> drivers/powercap/dtpm.c | 177 +++++++++++++++-----------------
> drivers/powercap/dtpm_cpu.c | 62 ++++++++---
> drivers/powercap/dtpm_devfreq.c | 22 ++--
> drivers/soc/rockchip/dtpm.c | 67 +++++++++---
> include/linux/dtpm.h | 6 +-
> 5 files changed, 195 insertions(+), 139 deletions(-)
Tha patch in general looks good. I only have one
comment related to the future usage of this mechanism.
For this implementation it's safe, but I would add
some extra safety net around the of_find_node_by_path().
See comments below.
[snip]
>
> -static struct dtpm *dtpm_setup_dt(const struct dtpm_node *hierarchy,
> +static struct dtpm *dtpm_setup_dt(const char *name, const char *path,
> struct dtpm *parent)
> {
> struct device_node *np;
> - int i, ret;
> + struct dtpm *dtpm = NULL;
> + int i;
>
> - np = of_find_node_by_path(hierarchy->name);
I would add a NULL check for 'path' here, or below
where dtpm_setup_dt() is called.
Usually it's up the the code which is calling that API
to make sure that the NULL is not sneaked in.
We probably can force drivers code for that, right?
> + np = of_find_node_by_path(path);
> if (!np) {
> - pr_err("Failed to find '%s'\n", hierarchy->name);
> + pr_err("Failed to find '%s'\n", path);
> return ERR_PTR(-ENXIO);
> }
>
> for (i = 0; i < ARRAY_SIZE(dtpm_subsys); i++) {
> + struct dtpm *tmp;
>
> if (!dtpm_subsys[i]->setup)
> continue;
>
> - ret = dtpm_subsys[i]->setup(parent, np);
> - if (ret) {
> - pr_err("Failed to setup '%s': %d\n", dtpm_subsys[i]->name, ret);
> - of_node_put(np);
> - return ERR_PTR(ret);
> + tmp = dtpm_subsys[i]->setup(parent, np, name);
> + if (IS_ERR(tmp)) {
> + pr_err("Failed to setup '%s': %ld\n",
> + dtpm_subsys[i]->name, PTR_ERR(tmp));
> + dtpm = tmp;
> + break;
> + }
> +
> + if (tmp) {
> + dtpm = tmp;
> + break;
> }
> }
>
> of_node_put(np);
>
> - /*
> - * By returning a NULL pointer, we let know the caller there
> - * is no child for us as we are a leaf of the tree
> - */
> - return NULL;
> + return dtpm;
> }
>
> -typedef struct dtpm * (*dtpm_node_callback_t)(const struct dtpm_node *, struct dtpm *);
> -
> -static dtpm_node_callback_t dtpm_node_callback[] = {
> - [DTPM_NODE_VIRTUAL] = dtpm_setup_virtual,
> - [DTPM_NODE_DT] = dtpm_setup_dt,
> -};
> -
> -static int dtpm_for_each_child(const struct dtpm_node *hierarchy,
> - const struct dtpm_node *it, struct dtpm *parent)
> +static struct powercap_zone *
> +dtpm_node_create(struct powercap_control_type *pct, const char *name,
> + void *data, struct powercap_zone *parent)
> {
> + struct dtpm_node *node = data;
> + struct dtpm *dtpm_parent = parent ? to_dtpm(parent) : NULL;
> struct dtpm *dtpm;
> - int i, ret;
>
> - for (i = 0; hierarchy[i].name; i++) {
> + if (!node)
> + return ERR_PTR(-EINVAL);
> +
> + switch (node->type) {
> + case DTPM_NODE_VIRTUAL:
> + dtpm = dtpm_setup_virtual(name, dtpm_parent);
> + break;
> + case DTPM_NODE_DT:
... or a NULL check here.
> + dtpm = dtpm_setup_dt(name, node->path, dtpm_parent);
> + break;
> + default:
> + return ERR_PTR(-EINVAL);
> + }
The rest looks good.
If we are sure we would never experience that NULL ptr coming to those
registration callbacks - then OK.
Regards,
Lukasz
next prev parent reply other threads:[~2026-11-02 9:56 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-29 16:56 [PATCH v4 0/6] powercap: Add generic hierarchy support and convert DTPM Daniel Lezcano
2026-10-29 16:56 ` [PATCH v4 1/6] powercap: Add generic zone hierarchy creation helpers Daniel Lezcano
2026-10-30 14:02 ` Lukasz Luba
2026-10-30 14:26 ` Daniel Lezcano
2026-10-29 16:56 ` [PATCH v4 2/6] selftests/powercap: Add powercap hierarchy creation API tests Daniel Lezcano
2026-10-29 16:56 ` [PATCH v4 3/6] powercap: dtpm: Remove duplicate RK3399 CPU hierarchy nodes Daniel Lezcano
2026-10-30 14:03 ` Lukasz Luba
2026-10-29 16:56 ` [PATCH v4 4/6] powercap: dtpm: Use generic powercap hierarchy helpers Daniel Lezcano
2026-11-02 9:57 ` Lukasz Luba [this message]
2026-10-29 16:56 ` [PATCH v4 5/6] powercap: dtpm: Rename Rockchip virtual node descriptor Daniel Lezcano
2026-10-30 14:07 ` Lukasz Luba
2026-10-29 16:56 ` [PATCH v4 6/6] powercap: dtpm: Add RK3588 hierarchy Daniel Lezcano
2026-10-30 14:09 ` Lukasz Luba
2026-10-30 9:08 ` [PATCH v4 0/6] powercap: Add generic hierarchy support and convert DTPM Daniel Lezcano
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=3005f6f5-3b6a-4139-a170-1f60d93c9902@arm.com \
--to=lukasz.luba@arm.com \
--cc=daniel.lezcano@kernel.org \
--cc=daniel.lezcano@oss.qualcomm.com \
--cc=heiko@sntech.de \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=linux-rockchip@lists.infradead.org \
--cc=manaf.pallikunhi@oss.qualcomm.com \
--cc=rafael@kernel.org \
--cc=shuah@kernel.org \
/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®