[PATCH v2 0/5] scmi: Log client subsystem entity counts

[PATCH v2 0/5] scmi: Log client subsystem entity counts

[Alex Tran]

SCMI client drivers do not consistently log the number of supported
entities discovered from firmware. This information is useful during
debugging because it shows which domains or resources were exposed by
firmware during probe.

Add logging of the number of supported entities to the SCMI cpufreq,
pinctrl, reset, hwmon, and powercap client drivers after a successful
probe. This aligns these drivers with the existing logging in the SCMI
power and performance domain drivers.

Signed-off-by: Alex Tran <alex.tran@oss.qualcomm.com>
---
Changes in v2:
- Use dev_dbg instead of dev_info log level
- Link to v1: https://lore.kernel.org/r/20260513-scmi-client-probe-log-v1-0-00b47b1be009@oss.qualcomm.com

---
Alex Tran (5):
      powercap: arm_scmi_powercap: Log number of powercap domains
      cpufreq: scmi-cpufreq: Log number of perf domains
      hwmon: scmi-hwmon: Log number of sensors
      reset: reset-scmi: Log number of reset domains
      pinctrl: pinctrl-scmi: Log number of pins, groups, functions

 drivers/cpufreq/scmi-cpufreq.c       |  5 ++++-
 drivers/hwmon/scmi-hwmon.c           |  1 +
 drivers/pinctrl/pinctrl-scmi.c       | 11 ++++++++++-
 drivers/powercap/arm_scmi_powercap.c |  1 +
 drivers/reset/reset-scmi.c           |  8 +++++++-
 5 files changed, 23 insertions(+), 3 deletions(-)
---
base-commit: 1bfaee9d3351b9b32a99766bbfb1f5baed60ddef
change-id: 20260509-scmi-client-probe-log-173cf85d5563

Best regards,
-- 
Alex Tran <alex.tran@oss.qualcomm.com>

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

[Alex Tran]

The SCMI powercap driver does not currently report how many powercap
domains were discovered from firmware during probe. This makes it harder
to confirm the firmware exposed powercap resources during debugging.

Log the powercap domain count after a successful probe, aligning the
driver with the existing SCMI client driver logging pattern.

Signed-off-by: Alex Tran <alex.tran@oss.qualcomm.com>
---
 drivers/powercap/arm_scmi_powercap.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/powercap/arm_scmi_powercap.c b/drivers/powercap/arm_scmi_powercap.c
index ab66e9a3b1e2..3efe3743cce0 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_dbg(dev, "Initialized %d powercap domains\n", pr->num_zones);
 
 	return ret;
 }

-- 
2.43.0

[PATCH v2 2/5] cpufreq: scmi-cpufreq: Log number of perf domains

[Alex Tran]

The SCMI cpufreq driver does not currently log the number of performance
domains discovered from firmware. This information is useful for
confirming the firmware exposed performance domains during debugging.

Log the domain count after a successful probe to align with the existing
SCMI client driver logging pattern.

Signed-off-by: Alex Tran <alex.tran@oss.qualcomm.com>
---
 drivers/cpufreq/scmi-cpufreq.c | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/cpufreq/scmi-cpufreq.c b/drivers/cpufreq/scmi-cpufreq.c
index 4edb4f7a8aa9..f4cf59d862c6 100644
--- a/drivers/cpufreq/scmi-cpufreq.c
+++ b/drivers/cpufreq/scmi-cpufreq.c
@@ -468,9 +468,12 @@ static int scmi_cpufreq_probe(struct scmi_device *sdev)
 	if (ret) {
 		dev_err(dev, "%s: registering cpufreq failed, err: %d\n",
 			__func__, ret);
+		return ret;
 	}
 
-	return ret;
+	dev_dbg(dev, "Initialized %d performance domains\n",
+		 perf_ops->num_domains_get(ph));
+	return 0;
 }
 
 static void scmi_cpufreq_remove(struct scmi_device *sdev)

-- 
2.43.0

[PATCH v2 3/5] hwmon: scmi-hwmon: Log number of sensors

[Alex Tran]

The SCMI hwmon driver does not currently report how many sensors were
discovered from firmware during probe. This makes it harder to confirm
the firmware exposed sensor resources during debugging.

Log the sensor count after a successful probe, aligning the driver with
the existing SCMI client driver logging pattern.

Signed-off-by: Alex Tran <alex.tran@oss.qualcomm.com>
---
 drivers/hwmon/scmi-hwmon.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/hwmon/scmi-hwmon.c b/drivers/hwmon/scmi-hwmon.c
index eec223d174c0..456ce11d050c 100644
--- a/drivers/hwmon/scmi-hwmon.c
+++ b/drivers/hwmon/scmi-hwmon.c
@@ -362,6 +362,7 @@ static int scmi_hwmon_probe(struct scmi_device *sdev)
 		}
 	}
 
+	dev_dbg(dev, "Initialized %d sensors\n", nr_sensors);
 	return 0;
 }
 

-- 
2.43.0

[PATCH v2 4/5] reset: reset-scmi: Log number of reset domains

[Alex Tran]

The SCMI reset driver does not currently report how many reset domains
were discovered from firmware during probe. This makes it harder to
confirm the firmware reset resources during debugging.

Log the reset domain count after a successful probe, aligning the driver
with the existing SCMI client driver logging pattern.

Signed-off-by: Alex Tran <alex.tran@oss.qualcomm.com>
---
 drivers/reset/reset-scmi.c | 8 +++++++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/reset/reset-scmi.c b/drivers/reset/reset-scmi.c
index 4335811e0cfa..114470c12931 100644
--- a/drivers/reset/reset-scmi.c
+++ b/drivers/reset/reset-scmi.c
@@ -93,6 +93,7 @@ static int scmi_reset_probe(struct scmi_device *sdev)
 	struct device_node *np = dev->of_node;
 	const struct scmi_handle *handle = sdev->handle;
 	struct scmi_protocol_handle *ph;
+	int ret;
 
 	if (!handle)
 		return -ENODEV;
@@ -111,7 +112,12 @@ static int scmi_reset_probe(struct scmi_device *sdev)
 	data->rcdev.nr_resets = reset_ops->num_domains_get(ph);
 	data->ph = ph;
 
-	return devm_reset_controller_register(dev, &data->rcdev);
+	ret = devm_reset_controller_register(dev, &data->rcdev);
+	if (ret)
+		return ret;
+
+	dev_dbg(dev, "Initialized %d reset domains\n", data->rcdev.nr_resets);
+	return 0;
 }
 
 static const struct scmi_device_id scmi_id_table[] = {

-- 
2.43.0

[PATCH v2 5/5] pinctrl: pinctrl-scmi: Log number of pins, groups, functions

[Alex Tran]

The SCMI pinctrl driver does not currently log the number of pins,
groups, and functions discovered from firmware. This information is
useful for confirming the firmware exposed pinctrl resources during
debugging.

Log these counts after a successful probe to align with the existing
SCMI client driver logging pattern.

Signed-off-by: Alex Tran <alex.tran@oss.qualcomm.com>
---
 drivers/pinctrl/pinctrl-scmi.c | 11 ++++++++++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/drivers/pinctrl/pinctrl-scmi.c b/drivers/pinctrl/pinctrl-scmi.c
index f22be6b7b82a..999c2061ddc3 100644
--- a/drivers/pinctrl/pinctrl-scmi.c
+++ b/drivers/pinctrl/pinctrl-scmi.c
@@ -40,6 +40,7 @@ struct scmi_pinctrl {
 	struct pinctrl_desc pctl_desc;
 	struct pinfunction *functions;
 	unsigned int nr_functions;
+	unsigned int nr_groups;
 };
 
 static int pinctrl_scmi_get_groups_count(struct pinctrl_dev *pctldev)
@@ -578,7 +579,15 @@ static int scmi_pinctrl_probe(struct scmi_device *sdev)
 	if (!pmx->functions)
 		return -ENOMEM;
 
-	return pinctrl_enable(pmx->pctldev);
+	pmx->nr_groups = pinctrl_scmi_get_groups_count(pmx->pctldev);
+
+	ret = pinctrl_enable(pmx->pctldev);
+	if (ret)
+		return ret;
+
+	dev_dbg(dev, "Initialized %d pins, %d groups, %d functions\n",
+		 pmx->pctl_desc.npins, pmx->nr_groups, pmx->nr_functions);
+	return 0;
 }
 
 static const struct scmi_device_id scmi_id_table[] = {

-- 
2.43.0

Re: [PATCH v2 0/5] scmi: Log client subsystem entity counts

[Andy Shevchenko]

On Wed, May 13, 2026 at 10:16:53AM -0700, Alex Tran wrote:
> SCMI client drivers do not consistently log the number of supported
> entities discovered from firmware. This information is useful during
> debugging because it shows which domains or resources were exposed by
> firmware during probe.
> 
> Add logging of the number of supported entities to the SCMI cpufreq,
> pinctrl, reset, hwmon, and powercap client drivers after a successful
> probe. This aligns these drivers with the existing logging in the SCMI
> power and performance domain drivers.

Too quick between the series, the v1 discussion is still ongoing.
Hence this should not be applied (at least yet).

Read Submitting Patches and other process documentation that suggest at least
24h period for review and in patch series even week or so.

> ---
> Changes in v2:
> - Use dev_dbg instead of dev_info log level
> - Link to v1: https://lore.kernel.org/r/20260513-scmi-client-probe-log-v1-0-00b47b1be009@oss.qualcomm.com


-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v2 5/5] pinctrl: pinctrl-scmi: Log number of pins, groups, functions

[Andy Shevchenko]

On Wed, May 13, 2026 at 10:16:58AM -0700, Alex Tran wrote:
> The SCMI pinctrl driver does not currently log the number of pins,
> groups, and functions discovered from firmware. This information is
> useful for confirming the firmware exposed pinctrl resources during
> debugging.
> 
> Log these counts after a successful probe to align with the existing
> SCMI client driver logging pattern.

NAK. Even for debug level. This can be easily derived from debugfs.

-- 
With Best Regards,
Andy Shevchenko

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

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Medium] The log message incorrectly reports the number of 'Initialized' domains using the count of 'Discovered' domains, leading to inaccurate and contradictory logs.
- [Low] Format string type mismatch for `pr->num_zones`.
--

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

powercap: arm_scmi_powercap: Log number of powercap domains

This commit adds a debug log to report the number of powercap domains
discovered from the firmware during probe. This helps confirm the firmware
exposed powercap resources.

> diff --git a/drivers/powercap/arm_scmi_powercap.c b/drivers/powercap/arm_scmi_powercap.c
> index ab66e9a3b1e2c..3efe3743cce0a 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_dbg(dev, "Initialized %d powercap domains\n", pr->num_zones);

Are all of these domains actually initialized?

During the probe process, domains using an abstract power scale are
explicitly skipped and marked as invalid (spz->invalid = true).
scmi_zones_register() also tracks and logs the actual successfully
registered count.

If there are skipped domains, this will produce confusing logs, such as
"Registered 3 SCMI Powercap domains !" from scmi_zones_register() followed
by "Initialized 5 powercap domains" here.

Should the log message say "Discovered" instead of "Initialized" to match
the commit message?

Also, this isn't a bug, but does this code use the correct format specifier
for pr->num_zones? Since num_zones is an unsigned int in struct
scmi_powercap_root, should this use %u instead of %d?

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

Re: [PATCH v2 2/5] cpufreq: scmi-cpufreq: Log number of perf domains

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] Misleading debug log message contradicts driver behavior and commit message.
--

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

cpufreq: scmi-cpufreq: Log number of perf domains

This commit adds a debug log to the SCMI cpufreq driver to report the
number of performance domains discovered from firmware.

> diff --git a/drivers/cpufreq/scmi-cpufreq.c b/drivers/cpufreq/scmi-cpufreq.c
> index 4edb4f7a8aa97..f4cf59d862c61 100644
> --- a/drivers/cpufreq/scmi-cpufreq.c
> +++ b/drivers/cpufreq/scmi-cpufreq.c
> @@ -468,9 +468,12 @@ static int scmi_cpufreq_probe(struct scmi_device *sdev)

[ ... ]

>  	if (ret) {
>  		dev_err(dev, "%s: registering cpufreq failed, err: %d\n",
>  			__func__, ret);
> +		return ret;
>  	}
>  
> -	return ret;
> +	dev_dbg(dev, "Initialized %d performance domains\n",
> +		 perf_ops->num_domains_get(ph));

The commit message states the intent is to log the number of domains
"discovered from firmware". Does the wording "Initialized" in this log
message accurately reflect the driver's behavior?

The driver primarily registers the cpufreq driver and does not actually
initialize the SCMI performance domains. Additionally, num_domains_get()
returns the total count of SCMI performance domains exposed by the
firmware, which may also include non-CPU domains like GPUs.

Would a word like "Discovered" be more appropriate here?

> +	return 0;
>  }

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260513-scmi-client-probe-log-v2-0-36607e9dd540@oss.qualcomm.com?part=2

Re: [PATCH v2 3/5] hwmon: scmi-hwmon: Log number of sensors

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] The scmi_hwmon_probe function configures the wrong sensors because it passes the array index `i` instead of the actual firmware `sensor->id` to `sensor_ops->config_set`.
--

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

hwmon: scmi-hwmon: Log number of sensors

This commit logs the number of discovered sensors upon a successful probe in
the SCMI hwmon driver. This aligns the driver with the existing SCMI client
driver logging pattern, making it easier to confirm firmware-exposed resources
during debugging.

> diff --git a/drivers/hwmon/scmi-hwmon.c b/drivers/hwmon/scmi-hwmon.c
> index eec223d174c07..456ce11d050c6 100644
> --- a/drivers/hwmon/scmi-hwmon.c
> +++ b/drivers/hwmon/scmi-hwmon.c
> @@ -335,49 +335,50 @@ static int scmi_hwmon_probe(struct scmi_device *sdev)
[ ... ]
>  	for (i = 0; i < nr_count_temp; i++) {
>  		int ret;
>  
>  		sensor = *(scmi_sensors->info[hwmon_temp] + i);
>  		if (!sensor)
>  			continue;
>  
>  		ret = sensor_ops->config_set(ph, i, sensor_config);

This isn't a regression introduced by this commit, but could passing the
local array index i to sensor_ops->config_set() instead of the firmware
sensor->id result in configuring the wrong sensors?

Since SCMI sensor IDs are global and can map to any sensor type, passing
the local array index might mistakenly configure arbitrary unrelated
hardware components.

Could this leave the actual temperature sensors unconfigured and break
subsequent thermal zone registration? Is it possible that thermal
mitigation would fail to function correctly due to the underlying
temperature sensors remaining disabled?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260513-scmi-client-probe-log-v2-0-36607e9dd540@oss.qualcomm.com?part=3

Re: [PATCH v2 4/5] reset: reset-scmi: Log number of reset domains

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] The dev_dbg() statement uses the '%d' format specifier to log `data->rcdev.nr_resets`, which is defined as an `unsigned int` in `struct reset_controller_dev`. The correct format specifier should be '%u'.
--

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

reset: reset-scmi: Log number of reset domains

This commit updates the SCMI reset driver to log the number of reset domains
discovered from firmware during probe.

> diff --git a/drivers/reset/reset-scmi.c b/drivers/reset/reset-scmi.c
> index 4335811e0cfaa..114470c12931f 100644
> --- a/drivers/reset/reset-scmi.c
> +++ b/drivers/reset/reset-scmi.c

[ ... ]

> @@ -111,7 +112,12 @@ static int scmi_reset_probe(struct scmi_device *sdev)
>  	data->rcdev.nr_resets = reset_ops->num_domains_get(ph);
>  	data->ph = ph;
>  
> -	return devm_reset_controller_register(dev, &data->rcdev);
> +	ret = devm_reset_controller_register(dev, &data->rcdev);
> +	if (ret)
> +		return ret;
> +
> +	dev_dbg(dev, "Initialized %d reset domains\n", data->rcdev.nr_resets);

This isn't a bug, but does this dev_dbg() statement use the wrong format
specifier?

The nr_resets field in struct reset_controller_dev is an unsigned int, so
should it use %u instead of %d?

> +	return 0;
>  }

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260513-scmi-client-probe-log-v2-0-36607e9dd540@oss.qualcomm.com?part=4

Re: [PATCH v2 5/5] pinctrl: pinctrl-scmi: Log number of pins, groups, functions

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
- [Low] Unnecessary structure bloat by adding `nr_groups` to persistent driver state.
- [Low] Missing error handling for firmware query result before assignment to an unsigned integer.
- [Low] Format specifier type mismatch in `dev_dbg`.
--

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

pinctrl: pinctrl-scmi: Log number of pins, groups, functions

The SCMI pinctrl driver does not currently log the number of pins, groups,
and functions discovered from firmware. This commit adds a debug log statement
to print these counts after a successful probe.

> diff --git a/drivers/pinctrl/pinctrl-scmi.c b/drivers/pinctrl/pinctrl-scmi.c
> index f22be6b7b82a4..999c2061ddc38 100644
> --- a/drivers/pinctrl/pinctrl-scmi.c
> +++ b/drivers/pinctrl/pinctrl-scmi.c
> @@ -40,6 +40,7 @@ struct scmi_pinctrl {
>  	struct pinctrl_desc pctl_desc;
>  	struct pinfunction *functions;
>  	unsigned int nr_functions;
> +	unsigned int nr_groups;

Is it necessary to add nr_groups to struct scmi_pinctrl?

Unlike nr_functions which is used later, nr_groups is only written and read
sequentially within scmi_pinctrl_probe() to populate the dev_dbg message.
Could this simply be a local variable in the probe function to avoid bloating
the persistent device data structure?

>  };
>  
>  static int pinctrl_scmi_get_groups_count(struct pinctrl_dev *pctldev)

[ ... ]

> @@ -578,7 +579,15 @@ static int scmi_pinctrl_probe(struct scmi_device *sdev)
>  	if (!pmx->functions)
>  		return -ENOMEM;
>  
> -	return pinctrl_enable(pmx->pctldev);
> +	pmx->nr_groups = pinctrl_scmi_get_groups_count(pmx->pctldev);

What happens if pinctrl_scmi_get_groups_count() returns a negative error code
due to an SCMI firmware query failure?

Since nr_groups is an unsigned int, assigning a negative error code will
result in a silent integer underflow. While this isn't used for memory
allocation or bounds checking, it will result in incorrect values being
logged.

> +
> +	ret = pinctrl_enable(pmx->pctldev);
> +	if (ret)
> +		return ret;
> +
> +	dev_dbg(dev, "Initialized %d pins, %d groups, %d functions\n",
> +		 pmx->pctl_desc.npins, pmx->nr_groups, pmx->nr_functions);

Should we use %u instead of %d for these format specifiers?

pmx->pctl_desc.npins, nr_groups, and nr_functions are all unsigned integers.
Using %d causes any underflowed error codes to print deceptively as negative
numbers in the logs rather than revealing the implicit cast.

> +	return 0;
>  }

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260513-scmi-client-probe-log-v2-0-36607e9dd540@oss.qualcomm.com?part=5

Re: [PATCH v2 0/5] scmi: Log client subsystem entity counts

[Jonathan Cameron]

On Wed, 13 May 2026 10:16:53 -0700
Alex Tran <alex.tran@oss.qualcomm.com> wrote:

> SCMI client drivers do not consistently log the number of supported
> entities discovered from firmware. This information is useful during
> debugging because it shows which domains or resources were exposed by
> firmware during probe.
> 
> Add logging of the number of supported entities to the SCMI cpufreq,
> pinctrl, reset, hwmon, and powercap client drivers after a successful
> probe. This aligns these drivers with the existing logging in the SCMI
> power and performance domain drivers.
> 
> Signed-off-by: Alex Tran <alex.tran@oss.qualcomm.com>
Hi Alex,

Just curious but why +CC linux-iio and IIO folk?

May be you had a false suggestion to add them from get maintainers.
If so be sure to check it's suggestions make sense!

Not to worry - we can all hit the delete button ;)

Jonathan


> ---
> Changes in v2:
> - Use dev_dbg instead of dev_info log level
> - Link to v1: https://lore.kernel.org/r/20260513-scmi-client-probe-log-v1-0-00b47b1be009@oss.qualcomm.com
> 
> ---
> Alex Tran (5):
>       powercap: arm_scmi_powercap: Log number of powercap domains
>       cpufreq: scmi-cpufreq: Log number of perf domains
>       hwmon: scmi-hwmon: Log number of sensors
>       reset: reset-scmi: Log number of reset domains
>       pinctrl: pinctrl-scmi: Log number of pins, groups, functions
> 
>  drivers/cpufreq/scmi-cpufreq.c       |  5 ++++-
>  drivers/hwmon/scmi-hwmon.c           |  1 +
>  drivers/pinctrl/pinctrl-scmi.c       | 11 ++++++++++-
>  drivers/powercap/arm_scmi_powercap.c |  1 +
>  drivers/reset/reset-scmi.c           |  8 +++++++-
>  5 files changed, 23 insertions(+), 3 deletions(-)
> ---
> base-commit: 1bfaee9d3351b9b32a99766bbfb1f5baed60ddef
> change-id: 20260509-scmi-client-probe-log-173cf85d5563
> 
> Best regards,

Re: [PATCH v2 0/5] scmi: Log client subsystem entity counts

[Sudeep Holla]

On Thu, May 14, 2026 at 04:44:22PM +0100, Jonathan Cameron wrote:
> On Wed, 13 May 2026 10:16:53 -0700
> Alex Tran <alex.tran@oss.qualcomm.com> wrote:
> 
> > SCMI client drivers do not consistently log the number of supported
> > entities discovered from firmware. This information is useful during
> > debugging because it shows which domains or resources were exposed by
> > firmware during probe.
> > 
> > Add logging of the number of supported entities to the SCMI cpufreq,
> > pinctrl, reset, hwmon, and powercap client drivers after a successful
> > probe. This aligns these drivers with the existing logging in the SCMI
> > power and performance domain drivers.
> > 
> > Signed-off-by: Alex Tran <alex.tran@oss.qualcomm.com>
> Hi Alex,
> 
> Just curious but why +CC linux-iio and IIO folk?
> 
> May be you had a false suggestion to add them from get maintainers.
> If so be sure to check it's suggestions make sense!
>

My guess, the intention was to add similar logging in scmi_iio_dev_probe()
as well, may have got dropped {un/}intentionally, but the list remained
in place. The author of the driver is also cc-ed.

-- 
Regards,
Sudeep

Re: [PATCH v2 0/5] scmi: Log client subsystem entity counts

[Alex Tran]

On 5/14/2026 8:44 AM, Jonathan Cameron wrote:

> On Wed, 13 May 2026 10:16:53 -0700
> Alex Tran <alex.tran@oss.qualcomm.com> wrote:
>
>> SCMI client drivers do not consistently log the number of supported
>> entities discovered from firmware. This information is useful during
>> debugging because it shows which domains or resources were exposed by
>> firmware during probe.
>>
>> Add logging of the number of supported entities to the SCMI cpufreq,
>> pinctrl, reset, hwmon, and powercap client drivers after a successful
>> probe. This aligns these drivers with the existing logging in the SCMI
>> power and performance domain drivers.
>>
>> Signed-off-by: Alex Tran <alex.tran@oss.qualcomm.com>
> Hi Alex,
>
> Just curious but why +CC linux-iio and IIO folk?
>
> May be you had a false suggestion to add them from get maintainers.
> If so be sure to check it's suggestions make sense!
>
> Not to worry - we can all hit the delete button ;)
>
> Jonathan
Hi Jonathan,

Originally, there was another patch in this series to add the same functionality to scmi_iio probe but it was dropped. Apparently running b4 prep --auto-to-cc does not prune stale entries from the cover letter. Will manually remove all entries and rerun the command in the future.

Alex