On Mon, Apr 13, 2026 at 06:30:18PM +0800, Jie Gan wrote:
[...]
tested on QCOM sa8775-ride:
=== 1. Sysfs mode: basic enable/disable === PASS: Sink tmc_etr0 enabled PASS: Source etm0 enabled PASS: Source etm0 disabled cleanly PASS: Sink tmc_etr0 disabled cleanly
=== 2. Sysfs mode: repeated enable/disable cycles (10x) === PASS: 10 enable/disable cycles completed without error
=== 3. Sysfs mode: enable source with no active sink === PASS: Enable without sink returned error (expected)
=== 4. Sysfs mode: enable/disable all per-CPU sources === etm0 (cpu0): enabled OK etm1 (cpu1): enabled OK etm2 (cpu2): enabled OK etm3 (cpu3): enabled OK etm4 (cpu4): enabled OK etm5 (cpu5): enabled OK etm6 (cpu6): enabled OK etm7 (cpu7): enabled OK PASS: All online per-CPU sources enabled/disabled successfully
=== 5. CPU hotplug: offline CPU while sysfs tracing active === Using source etm1 on cpu1 Tracing active on cpu1, offlining CPU... [ 82.805359] psci: CPU1 killed (polled 0 ms) PASS: Source auto-disabled on CPU offline [ 83.346033] Detected PIPT I-cache on CPU1 [ 83.346114] GICv3: CPU1: found redistributor 100 region 0:0x0000000017a80000 [ 83.346283] CPU1: Booted secondary processor 0x0000000100 [0x410fd4b2] PASS: Source re-enabled after CPU re-online
=== 6. Sysfs: enable source on offline CPU (expect ENODEV) === [ 84.013788] psci: CPU1 killed (polled 0 ms) PASS: Enable on offline cpu1 rejected (enable_source=0) [ 84.349558] Detected PIPT I-cache on CPU1 [ 84.349640] GICv3: CPU1: found redistributor 100 region 0:0x0000000017a80000 [ 84.349811] CPU1: Booted secondary processor 0x0000000100 [0x410fd4b2]
=== 7. CPU PM: trace survives CPU idle entry/exit === Sleeping 3s to allow CPU idle entry... Idle entries on cpu0 during test: 35 PASS: Source still enabled after idle (PM save/restore working)
=== 8. Perf mode: basic cs_etm recording === SKIP: perf not found in PATH
=== 11. TRBE: check save/restore sysfs nodes (if present) === SKIP: No TRBE devices found
Tested-by: Jie Gan jie.gan@oss.qualcomm.com
Just heads up: since Sashiko [1] pointed out a corner case where an SMP call may fail when disabling the source device, the per-CPU path pointer might not be cleared. If the ETMv4 device is then removed (e.g. if the user unloads the ETMv4 module), CPU PM notifier might access the stale path pointer. Though this is a rare case, we should handle it safely. This is why the series was not picked for the v7.1 merge window.
Thanks a lot for the testing, Jie! It's very helpful, and I will add your test tags in the next spin.
Anyway, please expect more iterations.
Thanks, Leo
[1] https://sashiko.dev/#/patchset/20260405-arm_coresight_path_power_management_...