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>
---
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>

+Greg (I believe the trend is to drop such messages and not add them [back]?)

On Wed, May 13, 2026 at 09:44:18AM -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.

-- 
With Best Regards,
Andy Shevchenko

On 5/13/26 11:02, Andy Shevchenko wrote:
> +Greg (I believe the trend is to drop such messages and not add them [back]?)
> 

Is there some common guidance on this ? I'd be all for dropping messages
instead of adding them, but there seems to be a perpetual battle between
people who want to log everything and people concerned about logging noise.
As maintainer I always seem to be stuck between those two camps.

Guenter

> On Wed, May 13, 2026 at 09:44:18AM -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.
>

On Wed, May 13, 2026 at 11:27:21AM -0700, Guenter Roeck wrote:
> On 5/13/26 11:02, Andy Shevchenko wrote:
> > +Greg (I believe the trend is to drop such messages and not add them [back]?)
> > 
> 
> Is there some common guidance on this ? I'd be all for dropping messages
> instead of adding them, but there seems to be a perpetual battle between
> people who want to log everything and people concerned about logging noise.
> As maintainer I always seem to be stuck between those two camps.

When drivers work properly, they should be quiet.  This patch series
adds a bunch of dev_info() calls, which is not ok.  If a developer wants
to see extra messages, use the dev_dbg() infrastructure, or the tracing
infrastructure, both of which are there for this very reason.

So yes, I agree with Andy, this series is not ok, don't make more noise
please.

thanks,

greg k-h

On Thu, May 14, 2026 at 08:48:19AM +0200, Greg Kroah-Hartman wrote:
> On Wed, May 13, 2026 at 11:27:21AM -0700, Guenter Roeck wrote:
> > On 5/13/26 11:02, Andy Shevchenko wrote:
> > > +Greg (I believe the trend is to drop such messages and not add them [back]?)
> > > 
> > 
> > Is there some common guidance on this ? I'd be all for dropping messages
> > instead of adding them, but there seems to be a perpetual battle between
> > people who want to log everything and people concerned about logging noise.
> > As maintainer I always seem to be stuck between those two camps.
> 
> When drivers work properly, they should be quiet.  This patch series
> adds a bunch of dev_info() calls, which is not ok.  If a developer wants
> to see extra messages, use the dev_dbg() infrastructure, or the tracing
> infrastructure, both of which are there for this very reason.
> 

I completely agree and tend to follow that. But I always assumed it was
left to maintainers taste.

> So yes, I agree with Andy, this series is not ok, don't make more noise
> please.
> 

I am now thinking if [1] was the one setting example for this series. I did
ack it as I left it to the subsystem maintainer's choice(in this case author
as well).

-- 
Regards,
Sudeep

[1] https://lore.kernel.org/all/20260304101457.7470-1-ulf.hansson@linaro.org/