public inbox for linux-arm-kernel@lists.infradead.org
 help / color / mirror / Atom feed
From: Cristian Marussi <cristian.marussi@arm.com>
To: Philip Radford <philip.radford@arm.com>
Cc: linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org, arm-scmi@vger.kernel.org,
	linux-pm@vger.kernel.org, sudeep.holla@arm.com,
	james.quinlan@broadcom.com, f.fainelli@gmail.com,
	vincent.guittot@linaro.org, etienne.carriere@st.com,
	peng.fan@oss.nxp.com, michal.simek@amd.com,
	quic_sibis@quicinc.com, dan.carpenter@linaro.org, d-gole@ti.com,
	souvik.chakravarty@arm.com, cristian.marussi@arm.com
Subject: Re: [PATCH v5 12/12] powercap: arm_scmi: Synthetic zone enable/disable
Date: Tue, 5 May 2026 23:28:09 +0100	[thread overview]
Message-ID: <afpu-Wf01J3l0gAu@pluto> (raw)
In-Reply-To: <20260428090922.346069-13-philip.radford@arm.com>

On Tue, Apr 28, 2026 at 10:09:21AM +0100, Philip Radford wrote:
> Add functionality to disable and enable the synthetic zone which
> also affects the immediate children of the synthetic zone by applying
> the same command to them.
> 
> Signed-off-by: Philip Radford <philip.radford@arm.com>
> ---
>  drivers/powercap/arm_scmi_powercap.c | 81 ++++++++++++++++++++++++++++
>  1 file changed, 81 insertions(+)
> 
> diff --git a/drivers/powercap/arm_scmi_powercap.c b/drivers/powercap/arm_scmi_powercap.c
> index 81b5214acda4..1ed2949b06cb 100644
> --- a/drivers/powercap/arm_scmi_powercap.c
> +++ b/drivers/powercap/arm_scmi_powercap.c
> @@ -270,6 +270,85 @@ static int instance_root_release(struct powercap_zone *pz)
>  	return 0;
>  }
>  
> +static int instance_root_set_enable_state(struct powercap_zone *pz, bool enable)
> +{
> +	struct scmi_powercap_zone *root;
> +	struct scmi_powercap_root *pr;
> +	struct scmi_powercap_zone *child;

...child and root on the same line of declarations...

> +	int ret, first_err = 0;
> +
> +	if (!pz)
> +		return -EINVAL;
> +
> +	root = to_scmi_powercap_zone(pz);
> +	pr = container_of(root, struct scmi_powercap_root, instance_root);

...another user of you new macro !

> +
> +	list_for_each_entry(child, &pr->registered_zones[0], node) {
> +		if (child == &pr->instance_root)
> +			continue;
> +
> +		if (child->info->parent_id != SCMI_POWERCAP_ROOT_ZONE_ID)
> +			continue;
> +
> +		if (!child->info->cpli[0].cap_config)
> +			continue;
> +
> +		ret = powercap_ops->cap_enable_set(child->ph, child->info->id, enable);
> +
> +		if (ret && !first_err) {

...mmm what is the logic here ? why not bailing out on any error ?

> +			first_err = ret;
> +			dev_err(child->dev, "failed to %s zone %s: %d\n",
> +				enable ? "enable" : "disable",
> +				child->info->name, ret);
> +		}
> +	}
> +
> +	return first_err;

...especially if you anyway fails globally on any error....
..I am not completely sure bit given that youare operating on a
synthetic zone that you enable as a whole, while acting on its children
in the backstage...I would say that if any enable/disable fails on a
chidlren you should revert the enable status of the children thate were
succesffull and report the error...I mean the state of top synthatic
zones AND the states of the children MUST remain consistent...
...it CANNOT be that some chidlren fails, some succeeds and you report
an error..it must be all or nothing...
...example..top syntethic zone is OFF if all children were successfully
disabled...on a failure with one of the children you shoudl revert the
already successfully set children and report the global error...

> +}
> +
> +static int instance_root_set_enable(struct powercap_zone *pz, bool mode)
> +{
> +	return instance_root_set_enable_state(pz, mode);
> +}
> +
> +static int instance_root_get_enable(struct powercap_zone *pz, bool *mode)
> +{
> +	struct scmi_powercap_zone *root;
> +	struct scmi_powercap_root *pr;
> +	struct scmi_powercap_zone *child;
> +	bool enabled;
> +	int ret;
> +
> +	if (!pz || !mode)
> +		return -EINVAL;
> +
> +	root = to_scmi_powercap_zone(pz);
> +	pr = container_of(root, struct scmi_powercap_root, instance_root);
> +
> +	*mode = true;
> +
> +	list_for_each_entry(child, &pr->registered_zones[0], node) {

mmm...what is the point here of scanning the children to GET the
state...you should report the top syntethic zone state right ?
You could have disable children directly...that wont be reflected in the
Linux powercap hiearcrhy right ?
I mean should you NOT simply return the stae of the top syntethic zone
which is should have saved in the previous state_set operation above ?

I think that anyway if you disable a zone...any zone...ONLY that zone is
marked as disable in Lnux powercap ... am I right ? 

Then probably our SCMI fw will do much more on all the children..

Thanks,
Cristian


      reply	other threads:[~2026-05-05 22:28 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-04-28  9:09 [PATCH v5 00/12] Add support for SCMIv4.0 Powercap Extensions Philip Radford
2026-04-28  9:09 ` [PATCH v5 01/12] firmware: arm_scmi: Add an optional custom parameter to fastchannel helpers Philip Radford
2026-04-28  9:09 ` [PATCH v5 02/12] firmware: arm_scmi: Refactor powercap domain layout Philip Radford
2026-04-28  9:09 ` [PATCH v5 03/12] firmware: arm_scmi: Add SCMIv4.0 Powercap basic support Philip Radford
2026-04-28  9:09 ` [PATCH v5 04/12] firmware: arm_scmi: Add SCMIv4.0 Powercap FCs support Philip Radford
2026-04-28  9:09 ` [PATCH v5 05/12] firmware: arm_scmi: Add SCMIV4.0 Powercap notifications support Philip Radford
2026-04-28  9:09 ` [PATCH v5 06/12] firmware: arm_scmi: Extend powercap report to include MAI Philip Radford
2026-05-05 20:13   ` Cristian Marussi
2026-05-05 21:21     ` Philip Radford
2026-04-28  9:09 ` [PATCH v5 07/12] include: trace: Add new parameter to trace_scmi_fc_call Philip Radford
2026-04-28  9:09 ` [PATCH v5 08/12] powercap: arm_scmi: Enable multiple constraints support Philip Radford
2026-04-28  9:09 ` [PATCH v5 09/12] firmware: arm_scmi: add Powercap MAI get/set support Philip Radford
2026-05-05 20:36   ` Cristian Marussi
2026-05-05 21:44     ` Philip Radford
2026-05-05 22:09       ` Cristian Marussi
2026-04-28  9:09 ` [PATCH v5 10/12] powercap: arm_scmi: Create synthetic parent node for multi-instance Philip Radford
2026-05-05 22:03   ` Cristian Marussi
2026-04-28  9:09 ` [PATCH v5 11/12] powercap: arm_scmi: Add get_power_uw to synthetic node Philip Radford
2026-05-05 22:13   ` Cristian Marussi
2026-04-28  9:09 ` [PATCH v5 12/12] powercap: arm_scmi: Synthetic zone enable/disable Philip Radford
2026-05-05 22:28   ` Cristian Marussi [this message]

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=afpu-Wf01J3l0gAu@pluto \
    --to=cristian.marussi@arm.com \
    --cc=arm-scmi@vger.kernel.org \
    --cc=d-gole@ti.com \
    --cc=dan.carpenter@linaro.org \
    --cc=etienne.carriere@st.com \
    --cc=f.fainelli@gmail.com \
    --cc=james.quinlan@broadcom.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=michal.simek@amd.com \
    --cc=peng.fan@oss.nxp.com \
    --cc=philip.radford@arm.com \
    --cc=quic_sibis@quicinc.com \
    --cc=souvik.chakravarty@arm.com \
    --cc=sudeep.holla@arm.com \
    --cc=vincent.guittot@linaro.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