[LTP] cpufreq.c: add new test for cpufreq sysfs interface validation

linuxtestproject.agent@gmail.com linuxtestproject.agent@gmail.com
Thu Jun 11 14:32:47 CEST 2026


Hi Piotr,

On Thu, 11 Jun 2026 13:42:20 +0200, Piotr Kubaj wrote:
> cpufreq.c: add new test for cpufreq sysfs interface validation

> +		if (cpuinfo_max_freq < scaling_max_freq) {
> +			tst_res(TINFO, "cpuinfo_max_freq: %ld", cpuinfo_max_freq);
> +			tst_res(TINFO, "scaling_max_freq: %ld", scaling_max_freq);
> +			tst_res(TFAIL, "Failure setting %s", path);
> +		} else {
> +			tst_res(TPASS, "Successfully set up %s", path);
> +		}

The frequency write-back checks throughout run() use one-directional
comparisons. Here the test writes cpuinfo_max_freq to scaling_max_freq
and reads it back, but only fails when the read value is *higher*
than what was written. If the kernel rounded the value *down* (or the
write silently failed to a lower value), the test would still report
TPASS with "Successfully set up".

The same pattern applies to the scaling_min_freq checks further down,
which only fail when the read value is *lower* than what was written.

Since the purpose of these checks is to validate that exact boundary
values can be written, would it not be more correct to use != instead
of < / > here?

> +		if (cpuinfo_max_freq < scaling_min_freq) {

Same issue: only catches upward deviations.

> +		if (cpuinfo_min_freq > scaling_min_freq) {

Same issue: only catches downward deviations.

> +		if (cpuinfo_min_freq > scaling_max_freq) {

Same issue: only catches downward deviations.

Verdict: Needs revision

---
Note:

The agent can sometimes produce false positives although often its
findings are genuine. If you find issues with the review, please
comment this email or ignore the suggestions.

Regards,
LTP AI Reviewer


More information about the ltp mailing list