All of lore.kernel.org
 help / color / mirror / Atom feed
From: Cristian Marussi <cristian.marussi@arm.com>
To: Sudeep Holla <sudeep.holla@kernel.org>
Cc: Cristian Marussi <cristian.marussi@arm.com>,
	arm-scmi@vger.kernel.org, linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH 4/4] firmware: arm_scmi: Validate Powercap domains before state access
Date: Tue, 19 May 2026 11:04:41 +0100	[thread overview]
Message-ID: <agw1ueCQ0WjoBX7-@pluto> (raw)
In-Reply-To: <20260517-scmi_fixes-v1-4-d86daec4defd@kernel.org>

On Sun, May 17, 2026 at 08:02:43PM +0100, Sudeep Holla wrote:
> Powercap protocol v2 keeps local enable and last-cap state per
> domain. Some public operations indexed that state before checking that
> the supplied domain id was valid, and cap_enable_get() updated it even
> when cap_get() failed.
> 
> Validate the domain before touching the per-domain state and only
> refresh cached enable state after a successful cap_get().
> 

Hi,

> Signed-off-by: Sudeep Holla <sudeep.holla@kernel.org>
> ---
>  drivers/firmware/arm_scmi/powercap.c | 25 ++++++++++++++++++-------
>  1 file changed, 18 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/firmware/arm_scmi/powercap.c b/drivers/firmware/arm_scmi/powercap.c
> index ab9733f4458b..eb5c35cad026 100644
> --- a/drivers/firmware/arm_scmi/powercap.c
> +++ b/drivers/firmware/arm_scmi/powercap.c
> @@ -453,10 +453,14 @@ static int scmi_powercap_cap_set(const struct scmi_protocol_handle *ph,
>  		return -EINVAL;
>  
>  	/* Just log the last set request if acting on a disabled domain */
> -	if (PROTOCOL_REV_MAJOR(ph->version) >= 0x2 &&
> -	    !pi->states[domain_id].enabled) {
> -		pi->states[domain_id].last_pcap = power_cap;
> -		return 0;
> +	if (PROTOCOL_REV_MAJOR(ph->version) >= 0x2) {
> +		if (!scmi_powercap_dom_info_get(ph, domain_id))
> +			return -EINVAL;
> +
> +		if (!pi->states[domain_id].enabled) {
> +			pi->states[domain_id].last_pcap = power_cap;
> +			return 0;
> +		}
>  	}

Yes, definitely better.

>  
>  	return __scmi_powercap_cap_set(ph, pi, domain_id,
> @@ -637,6 +641,9 @@ static int scmi_powercap_cap_enable_set(const struct scmi_protocol_handle *ph,
>  	if (PROTOCOL_REV_MAJOR(ph->version) < 0x2)
>  		return -EINVAL;
>  
> +	if (!scmi_powercap_dom_info_get(ph, domain_id))
> +		return -EINVAL;
> +
>  	if (enable == pi->states[domain_id].enabled)
>  		return 0;
>  
> @@ -678,16 +685,20 @@ static int scmi_powercap_cap_enable_get(const struct scmi_protocol_handle *ph,
>  	if (PROTOCOL_REV_MAJOR(ph->version) < 0x2)
>  		return 0;
>  
> +	if (!scmi_powercap_dom_info_get(ph, domain_id))
> +		return -EINVAL;
> +

Ok.

>  	/*
>  	 * Report always real platform state; platform could have ignored
>  	 * a previous disable request. Default true on any error.
>  	 */
>  	ret = scmi_powercap_cap_get(ph, domain_id, &power_cap);
> -	if (!ret)
> +	if (!ret) {
>  		*enable = !!power_cap;
>  
> -	/* Update internal state with current real platform state */
> -	pi->states[domain_id].enabled = *enable;
> +		/* Update internal state with current real platform state */
> +		pi->states[domain_id].enabled = *enable;
> +	}

Mmm, this changes the logic as stated in the above comments...now the
problem is recalling WHY I adopted this logic :<

Thanks,
Cristian

  reply	other threads:[~2026-05-19 10:04 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-05-17 19:02 [PATCH 0/4] firmware: arm_scmi: Fix protocol parsing and validation Sudeep Holla
2026-05-17 19:02 ` [PATCH 1/4] firmware: arm_scmi: Read sensor config as 32-bit value Sudeep Holla
2026-05-19  8:38   ` Cristian Marussi
2026-05-17 19:02 ` [PATCH 2/4] firmware: arm_scmi: Validate BASE_ERROR_EVENT payload size Sudeep Holla
2026-05-19  9:07   ` Cristian Marussi
2026-05-17 19:02 ` [PATCH 3/4] firmware: arm_scmi: Validate SENSOR_UPDATE " Sudeep Holla
2026-05-19  9:40   ` Cristian Marussi
2026-05-17 19:02 ` [PATCH 4/4] firmware: arm_scmi: Validate Powercap domains before state access Sudeep Holla
2026-05-19 10:04   ` Cristian Marussi [this message]
     [not found]     ` <20260519-utopian-parrot-of-sorcery-eff40c@sudeepholla>
2026-05-20  8:10       ` Sudeep Holla
2026-05-21 14:09 ` [PATCH 0/4] firmware: arm_scmi: Fix protocol parsing and validation Sudeep Holla

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=agw1ueCQ0WjoBX7-@pluto \
    --to=cristian.marussi@arm.com \
    --cc=arm-scmi@vger.kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=sudeep.holla@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.