[Bug 297788] cpufreq_dt(4) rejects all single-processor systems on stable/14; one-line fix exists in main

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: [email protected]
          Reporter: [email protected]

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 <[email protected]>
                  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.