[Bug 297788] cpufreq_dt(4) rejects all single-processor systems on stable/14; one-line fix exists in main
Date: Sun, 23 Aug 2026 07:34:20 UTC
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=297788
Bug ID: 297788
Summary: cpufreq_dt(4) rejects all single-processor systems on
stable/14; one-line fix exists in main
Product: Base System
Version: 14.5-STABLE
Hardware: Any
OS: Any
Status: New
Severity: Affects Some People
Priority: ---
Component: kern
Assignee: bugs@FreeBSD.org
Reporter: rick@sloservers.com
DESCRIPTION
cpufreq_dt(4) requires an opp-shared property on the operating-point table and
refuses to attach without it:
sys/dev/cpufreq/cpufreq_dt.c:405
if (!OF_hasprop(opp_table, "opp-shared")) {
device_printf(sc->dev, "Only opp-shared is supported\n");
return (ENXIO);
opp-shared states that several CPUs share one operating-point table, so it has
no meaning on a single-processor system, and device trees for such boards do
not set it. The effect is that cpufreq is unavailable on every single-core
platform running stable/14.
This is not AM335x-specific. Any single-core board with an opp-v2 table is
affected.
Observed on a BeagleBone Black (single-core TI AM3358, armv7), 14.5-STABLE:
cpufreq_dt0: <Generic cpufreq driver> on cpu0
cpufreq_dt0: Only opp-shared is supported
cpufreq_dt0: Failed to parse opp-v2 table
device_attach: cpufreq_dt0 attach returned 6
The same board on 15.1-STABLE, which already carries the fix, attaches and
reports frequencies normally:
cpufreq_dt0: <Generic cpufreq driver> on cpu0
cpufreq_dt0: 300.000 Mhz (0 uV)
cpufreq_dt0: 275.000 Mhz (0 uV)
THE FIX, ALREADY IN MAIN
def7999c2ccd riscv: enable cpufreq_dt driver
Mitchell Horne <mhorne@FreeBSD.org>
authored 2024-10-08, committed to main 2025-01-10
https://reviews.freebsd.org/D48124
Sponsored by: The FreeBSD Foundation
The relevant hunk is a single line:
- if (!OF_hasprop(opp_table, "opp-shared")) {
+ if (!OF_hasprop(opp_table, "opp-shared") && mp_ncpus > 1) {
BRANCH STATE
Verified 2026-08-23:
main guard present (mp_ncpus > 1)
stable/15 guard present (mp_ncpus > 1)
stable/14 guard ABSENT
releng/14.5 guard ABSENT
The commit subject does not appear in the stable/14 log, and the mp_ncpus test
is not present in that branch's cpufreq_dt.c. It has been in main for roughly
nineteen months.
REQUESTED ACTION
MFC the sys/dev/cpufreq/cpufreq_dt.c portion of def7999c2ccd to stable/14.
Only stable/14 is being requested; 15.x and main already have it. releng/14.5
is affected but is a frozen release branch and would pick this up through a
future release cut from stable/14 rather than by MFC.
Note the commit also touches riscv-specific files:
sys/conf/files.riscv | 1 +
sys/dev/cpufreq/cpufreq_dt.c | 2 +-
sys/riscv/conf/GENERIC | 3 +++
sys/riscv/include/pcpu.h | 3 ++-
sys/riscv/riscv/machdep.c | 12 +++++++++++-
If a wholesale MFC is undesirable, only the one-line cpufreq_dt.c hunk is
needed to fix this.
VERIFICATION PERFORMED
Applied the one-line change to a 14.5-STABLE tree and booted it on a BeagleBone
Black Rev B3 (single-core AM3358).
Before:
cpufreq_dt0: <Generic cpufreq driver> on cpu0
cpufreq_dt0: Only opp-shared is supported
cpufreq_dt0: Failed to parse opp-v2 table
device_attach: cpufreq_dt0 attach returned 6
After, same board and same kernel config:
cpufreq_dt0: <Generic cpufreq driver> on cpu0
cpufreq_dt0: 300.000 Mhz (0 uV)
cpufreq_dt0: 275.000 Mhz (0 uV)
cpufreq_dt0: 500.000 Mhz (0 uV)
cpufreq_dt0: 600.000 Mhz (0 uV)
The kernel boots to multi-user with zero device attach failures.
No new code is proposed in this PR.
--
You are receiving this mail because:
You are the assignee for the bug.