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

[PATCH 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>
---
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 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..48d721385f94 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);
 
 	return ret;
 }

-- 
2.43.0

[PATCH 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..d5c33eea2477 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_info(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 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..6f1b0559d5c2 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_info(dev, "Initialized %d sensors\n", nr_sensors);
 	return 0;
 }
 

-- 
2.43.0

[PATCH 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..f26fad0dc726 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_info(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 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..abc90a3a7eaf 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_info(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 3/5] hwmon: scmi-hwmon: Log number of sensors

[Guenter Roeck]

On 5/13/26 09:44, Alex Tran wrote:
> 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.
                                         ^^^^^^^^^^^^^^^^

Then please use dev_dbg().

Thanks,
Guenter

> 
> 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..6f1b0559d5c2 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_info(dev, "Initialized %d sensors\n", nr_sensors);
>   	return 0;
>   }
>   
> 

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

[Andy Shevchenko]

+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

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

[Guenter Roeck]

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

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

[Greg Kroah-Hartman]

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

Re: [PATCH 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] 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

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

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Critical] Use-After-Free (UAF) vulnerability due to global state overwrite in multi-SCMI configurations.
- [Low] Misleading and factually incorrect log message regarding initialized performance domains.
--

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

cpufreq: scmi-cpufreq: Log number of perf domains

This commit adds a log message to the SCMI cpufreq driver probe function
to display the number of performance domains discovered from firmware.
This is intended to align with the existing SCMI client driver logging
pattern.

> diff --git a/drivers/cpufreq/scmi-cpufreq.c b/drivers/cpufreq/scmi-cpufreq.c
> index 4edb4f7a8aa97..d5c33eea24773 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_info(dev, "Initialized %d performance domains\n",
> +		 perf_ops->num_domains_get(ph));

Is this log message entirely accurate?

The num_domains_get() function returns the total number of performance
domains exposed by the SCMI firmware, which includes domains for other
devices like GPUs or DSPs.

Since the scmi-cpufreq driver only initializes domains explicitly associated
with CPUs, could this log message be misleading during debugging by claiming
all SCMI performance domains were initialized here?

This isn't a bug introduced by this commit, but does the use of the global
perf_ops and ph variables here expose a use-after-free on systems with
multiple SCMI agents?

When a second device probes, it overwrites the global perf_ops and ph handles
earlier in the function:

    perf_ops = handle->devm_protocol_get(sdev, SCMI_PROTOCOL_PERF, &ph);

The second probe then calls cpufreq_register_driver(), which fails with
-EEXIST because a cpufreq driver is already registered.

The probe failure triggers devres cleanup for the second device, which calls
scmi_protocol_release() and frees the protocol instance.

Since the global ph pointer now points to freed memory, will subsequent
frequency transitions for the first device's CPUs dereference a dangling
pointer?

> +	return 0;
>  }
>  
>  static void scmi_cpufreq_remove(struct scmi_device *sdev)

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

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

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Low] The log message incorrectly reports the number of initialized sensors instead of discovered sensors.
- [Low] The format specifier `%d` is used to log an unsigned 16-bit integer.
--

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

hwmon: scmi-hwmon: Log number of sensors

This commit adds a log message to report the number of sensors during probe,
making it easier to confirm the firmware exposed the expected resources.

> diff --git a/drivers/hwmon/scmi-hwmon.c b/drivers/hwmon/scmi-hwmon.c
> index eec223d174c07..6f1b0559d5c28 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_info(dev, "Initialized %d sensors\n", nr_sensors);

The nr_sensors variable holds the total number of sensors discovered from
the firmware, but the driver filters these and only initializes specific
supported hwmon types like TEMPERATURE_C and VOLTAGE. Should this message
say "Discovered" instead, or perhaps use the count of actually initialized
sensors?

This isn't a bug, but since nr_sensors is a u16, should it use the %u
format specifier instead of %d?

>  	return 0;
>  }

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

Re: [PATCH 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 format specifier `%d` is used to print an `unsigned int` in `dev_info()`.
--

commit dfa791ed52b95e32859483ac051e58c6d9c9975b
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 during probe. It saves the return value of the registration function
to conditionally print the information upon success.

> diff --git a/drivers/reset/reset-scmi.c b/drivers/reset/reset-scmi.c
> index 4335811e0cfaa..f26fad0dc7268 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_info(dev, "Initialized %d reset domains\n", data->rcdev.nr_resets);

This isn't a bug, but should this format specifier be %u instead of %d?

Looking at struct reset_controller_dev, nr_resets is defined as an unsigned
int.

> +	return 0;
>  }

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

Re: [PATCH 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:
- [Medium] Unhandled error code from pinctrl_scmi_get_groups_count() masks firmware failure.
- [Low] Unnecessary persistent state added to struct scmi_pinctrl.
- [Low] Format string type mismatch in dev_info() logging.
--

commit d7d0dd8e474d3b2b3d8c68dd2d8713e62d0299a0
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.

> diff --git a/drivers/pinctrl/pinctrl-scmi.c b/drivers/pinctrl/pinctrl-scmi.c
> index f22be6b7b82a4..abc90a3a7eaf4 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;
>  };

Does nr_groups need to be stored in the scmi_pinctrl struct? It looks like
it is only used once in scmi_pinctrl_probe() for logging, so could it be
declared as a local variable instead?

[ ... ]

> @@ -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);

Can pinctrl_scmi_get_groups_count() return a negative error code here if the
firmware fails? Since pmx->nr_groups is an unsigned int, would a negative
error code be implicitly cast to a large positive value and mask the failure?

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

This isn't a bug, but the variables npins, nr_groups, and nr_functions are
all unsigned integers. Should these format specifiers be %u instead of %d?

> +	return 0;
>  }

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

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

[Sudeep Holla]

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/