Re: [PATCH 1/5] powercap: arm_scmi_powercap: Log number of powercap domains

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Medium] Misleading and redundant log message introduced during probe.
- [Low] Incorrect format specifier used for an unsigned integer.
--

commit bbe520bfc76fbb3ccbb1f090461778e8837406ba
Author: Alex Tran <alex.tran@oss.qualcomm.com>

powercap: arm_scmi_powercap: Log number of powercap domains

The SCMI powercap driver does not currently report how many powercap
domains were discovered from firmware during probe. This commit adds a log
message indicating the powercap domain count after a successful probe.

> diff --git a/drivers/powercap/arm_scmi_powercap.c b/drivers/powercap/arm_scmi_powercap.c
> index ab66e9a3b1e2c..48d721385f946 100644
> --- a/drivers/powercap/arm_scmi_powercap.c
> +++ b/drivers/powercap/arm_scmi_powercap.c
> @@ -496,6 +496,7 @@ static int scmi_powercap_probe(struct scmi_device *sdev)
>  		return ret;
>  
>  	dev_set_drvdata(dev, pr);
> +	dev_info(dev, "Initialized %d powercap domains\n", pr->num_zones);

Before this line, scmi_zones_register() is called, which already logs the
number of successfully registered domains:

    dev_info(dev, "Registered %d SCMI Powercap domains !\n", reg_zones);

Does this new dev_info() call create redundant and potentially conflicting
output in the kernel ring buffer?

Additionally, scmi_powercap_probe() explicitly skips domains with abstract
power scales earlier in the function:

    if (!spz->info->powercap_scale_uw &&
        !spz->info->powercap_scale_mw) {
        dev_warn(dev,
                 "Abstract power scale not supported. Skip %s.\n",
                 spz->info->name);
        spz->invalid = true;
        continue;
    }

Because pr->num_zones represents the total discovered domains rather than
the number actually initialized, could the count in the new log message be
misleading?

Finally, pr->num_zones is defined as an unsigned int in
struct scmi_powercap_root. Should the format specifier be %u instead of %d
to ensure type correctness?

>  
>  	return ret;
>  }

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260513-scmi-client-probe-log-v1-0-00b47b1be009@oss.qualcomm.com?part=1