Re: [PATCH 3/4] perf/arm_cspmu: Improve sub-module error reporting
From: Ilkka Koskinen <hidden>
Date: 2026-07-13 06:13:54
Also in:
linux-acpi, linux-perf-users
On Thu, 9 Jul 2026, Robin Murphy wrote:
When waiting for a sub-module to register, we return a bare -EPROBE_DEFER that ends up showing the end user: platform arm-cs-arch-pmu.1: deferred probe pending (no reason) wherein it's not necessarily clear that they might need to take some action to ensure the appropriate module is available to load. Let's use dev_err_probe() here so we can show exactly what we're waiting for. Similarly, in the case where something's gone horribly wrong with an already-registered module, we can use dev_WARN() to standardise the device/driver attribution rather than just open-coding "arm_cspmu". Signed-off-by: Robin Murphy <robin.murphy@arm.com>
Looks good to me, Reviewed-by: Ilkka Koskinen <redacted> Cheers, Ilkka
quoted hunk ↗ jump to hunk
--- drivers/perf/arm_cspmu/arm_cspmu.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-)diff --git a/drivers/perf/arm_cspmu/arm_cspmu.c b/drivers/perf/arm_cspmu/arm_cspmu.c index 0570be74d11f..0b26a1588eba 100644 --- a/drivers/perf/arm_cspmu/arm_cspmu.c +++ b/drivers/perf/arm_cspmu/arm_cspmu.c@@ -438,13 +438,15 @@ static int arm_cspmu_init_impl_ops(struct arm_cspmu *cspmu)if (ret) module_put(match->module); } else { - WARN(1, "arm_cspmu failed to get module: %s\n", + dev_WARN(cspmu->dev, "Failed to get module: %s\n", match->module_name); ret = -EINVAL; } } else { request_module_nowait(match->module_name); - ret = -EPROBE_DEFER; + ret = dev_err_probe(cspmu->dev, -EPROBE_DEFER, + "Waiting for module %s to load\n", + match->module_name); } mutex_unlock(&arm_cspmu_lock); -- 2.54.0.dirty