acpi_spmc(4): Clear confusion between DSMs and their functions
ClosedPublic
Actions

Authored by olce on May 4 2026, 8:30 PM.

Details

Reviewers

obiwac

Commits

rG27d99ff07908: acpi_spmc(4): Clear confusion between DSMs and their functions

Summary

Stick to the ACPI specification's terminology where DSM means "device
specific method", but is in fact a set of multiple functions (actually,
there is one set of functions per DSM revision, with the set for some
revision in theory including those of the previous revisions), by
renaming some of the fields of 'struct acpi_spmc_softc' and local
variables accordingly.

To this end, rename appropriate structures, fields, parameters and
variables, mechanically.

No functional change (intended).

Diff Detail

Repository

rG FreeBSD src repository

Lint

Lint Not Applicable

Unit

Tests Not Applicable

Event Timeline

olce created this revision.May 4 2026, 8:30 PM

Herald added a subscriber: imp. · View Herald TranscriptMay 4 2026, 8:30 PM

olce requested review of this revision.May 4 2026, 8:30 PM

Harbormaster completed remote builds in B72787: Diff 177193.May 4 2026, 8:30 PM

olce added a parent revision: D56801: acpi_spmc(4): Factor out code to test for a DSM's presence.May 4 2026, 8:38 PM

olce added a child revision: D56803: acpi_spmc(4): Introduce supports_function().

this can probably go further, but yes it's good that we clear up the DSM/functions naming. Actually what I call a DSM "set" here is really just a DSM. I just think the naming "method" to actually mean many different methods to be a bit confusing

In D56802#1301694, @obiwac wrote:

this can probably go further, but yes it's good that we clear up the DSM/functions naming. Actually what I call a DSM "set" here is really just a DSM. I just think the naming "method" to actually mean many different methods to be a bit confusing

Yes, I actually go further in subsequent revisions, probably because it was easier, but I'll check. So maybe the commit message here is promising more than what is delivered in that revision, but if including further revisions it turns out it is true. :-)

Comprehensive renaming to clear the mentioned confusion (moving the corresponding changes from later in the stack to here).

Harbormaster completed remote builds in B72886: Diff 177391.May 7 2026, 7:36 PM

olce mentioned this in D56804: acpi_spmc(4): softc: Remove unused 'obj'.May 7 2026, 7:41 PM

olce mentioned this in D56756: acpi_spmc(4): Human-readably print supported DSMs and their functions.May 7 2026, 7:57 PM

olce mentioned this in D56811: acpi_spmc(4): Print supported functions after DSMs.May 7 2026, 8:05 PM

olce mentioned this in D56812: acpi_spmc(4): INVARIANTS: Do not panic on getting constraints failure.

olce mentioned this in D56816: acpi_spmc(4): Global message on constraints parsing failure.May 7 2026, 8:12 PM

still don't quite know about just calling these "DSM". Technically, the _DSM object already encompasses all UUIDs. So maybe a name like dsm_fn_set? or dsm_vendor?

In D56802#1303698, @obiwac wrote:

still don't quite know about just calling these "DSM". Technically, the _DSM object already encompasses all UUIDs. So maybe a name like dsm_fn_set? or dsm_vendor?

Yes, a _DSM object encompasses all UUIDs, but it was introduced by ACPI to avoid naming collisions from uncoordinated vendors/actors wanting to define a DSM on a peripheral (by "requiring" to pass some UUID). So I view each UUID as a DSM on its own, I think that's really ACPI's intent, the _DSM object by itself is just a switch between DSMs despite the name. Expressed in a different manner, _DSM is actually the *set* of DSMs present on a device.

This revision was not accepted when it landed; it landed in state Needs Review.May 13 2026, 12:40 PM

Closed by commit rG27d99ff07908: acpi_spmc(4): Clear confusion between DSMs and their functions (authored by olce). · Explain Why

This revision was automatically updated to reflect the committed changes.

olce added a commit: rG27d99ff07908: acpi_spmc(4): Clear confusion between DSMs and their functions.