Which revisions to use for the Intel and AMD DSMs is unclear. For the
Intel one, the written specification indicates only 0, but Linux uses
1 (possibly an oversight). For the AMD one, for which there is no
specification, Linux uses 0, but at least on the Framework 13 AMD 7040
series, the "enumerate functions" function only returns a mask that
covers all the functions we expect when called with revision 2.
Introduce an auto-detection strategy where each revision starting from
0 is tried in turn up to some limit (included; default: 15). As soon as
a revision implements all expected functions, we stop the loop and use
that one, in effect selecting the minimum revision that implements all
we need, which should avoid potential backwards-compatibility problems.
If no revision implements all expected functions, the highest available
revision in the checked range is selected, but higher revisions that do
not bring new functions are discarded (see the explanatory comment in
acpi_spmc_probe_dsm()).
The revision policy is still tunable using the same existing sysctl(8)
knobs 'debug.acpi.spmc.intel_dsm_revision' and
'debug.acpi.spmc.amd_dsm_revision'. They have been extended so that
a negative value indicates to use the auto-detection mechanism up to
a revision of minus the value. As before, a 0 or positive value
requests a specific revision. A new knob is introduced for the
Microsoft DSM just in case ('debug.acpi.spmc.ms_dsm_revision').
Since now the revision can be auto-detected, and thus depends on
a particular device instance, move it into 'struct dsm_info' on the
softc. This also enables finishing the split between static and
dynamic/tunable information, allowing to constify all the DSM
descriptors.
Print the revision eventually used along with the supported functions.
Tested on an Intel Framework laptop.
Reviewed by: obiwac
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D56882
This is in preparation to adding the revision as a probed information.
Reviewed by: obiwac
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D56880
Examination of the DSDT in a Framework laptop generally hints at
firmware designers sometimes providing ACPI methods for convenience
(e.g., same firmware for multiple models) but not using them (or not
expecting them to be used) depending on tweaks or the actual hardware
platform.
On an Intel Framework laptop, we specifically observe the presence of
a Microsoft DSM that just reports availability of the SLEEP_ENTRY and
SLEEP_EXIT (7 and 8) functions although the Microsoft specification
requires other functions, whose purpose is similar to corresponding
Intel DSM's ones (such as DISPLAY_OFF). However, we currently always
call the latter even on the Microsoft DSM. On that laptop, fortunately,
the way the code is structured in the _DSM method leads to nothing being
executed on this call.
Given the similarity of intent between most functions from the Microsoft
DSM on one side and those of ADM and Intel on the other, it is
imaginable that other firmware developers could use a strategy where
functions are in fact aliased, in which case insisting on calling the
Microsoft's DSM function even if not enumerated would cause the action
to be performed twice (because we also call the corresponding function
on the Intel/AMD DSM), which may or may not cause other problems and in
any case seems a waste.
So, by default, do not try to run any function that is not enumerated,
as that looks like the safest approach. Add a debug sysctl(8) knob to
revert to the previous behavior, just in case
('debug.acpi.spmc.force_call_expected_functions').
acpi_spmc_run() now checks if a DSM/function combination has been
enumerated, and skips the actual call if it does not. This allows to
remove all checks from the acpi_spmc_*_notif() functions, making the
code much more compact.
acpi_spmc_get_constraints() now checks whether
DSM_GET_DEVICE_CONSTRAINTS is supported in order to determine which DSM
to use and whether to call the function at all.
Reviewed by: obiwac
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D56879
Since we are now keeping in the softc the information about which DSM
functions are available (in supported_functions[]), the 'dsms' field
there is somewhat redundant.
Make it completely redundant by keeping the bit representing the
enumeration function itself in each element of supported_functions[],
and then remove the field.
As a result, convert has_dsm() to rely on supports_function().
Adapt acpi_spmc_dsm_check_functions() so that it does not take into
account the enumeration function bit.
While here, use the self-explanatory stance
IDX_TO_BIT(DSM_ENUM_FUNCTIONS) instead of a hardcoded 1.
Reviewed by: obiwac
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D56878
This function actually runs a function of a given DSM. Remove the
'_dsm' suffix to remove the inaccuracy and make things simpler.
Reviewed by: obiwac
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D56877
Do not print by default details of failures that are unlikely to help
a normal user and to have a crucial influence on whether suspension
works correctly. Do so only on a verbose boot or if requested
explicitly by the user via 'debug.acpi.spmc.verbose'.
In particular:
- On an Intel Framework laptop, the Microsoft DSM only reports the
SLEEP_ENTRY and SLEEP_EXIT functions. That makes some sense since,
according to its specification, all functions of a Microsoft DSM
except these two are in fact redundant with Intel DSM's ones (also,
that of AMD DSM's ones). Those functions being missing are only
a potential problem if there is no other DSM than Microsoft's (yet to
be observed in the field).
- The details of malformed/unapplicable constraints or ones with a newer
format the driver does not know about are not readily actionable
pieces of information, but rather debug/developer-oriented ones. When
verbosity is not requested, only print the details of the first such
failure to encourage reporting and at the same time avoid cluttering
the output.
- Detecting and printing unknown DSM functions is not directly
actionable either, and the driver not using these functions may not
prevent suspending (but might, e.g., prevent reaching deeper sleep
states).
Reviewed by: obiwac
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D56876
The driver will be more verbose on this knob being non-zero or
'bootverbose' being set. The corresponding variable is typed as an
integer to leave room for expansion. To be used in subsequent commits.
Reviewed by: obiwac
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D56875
The handle is already held by the softc, which is also passed.
No functional change (intended).
Reviewed by: imp, obiwac
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D56818
Support the (so far hypothetical) case of a machine with multiple
instances of the PNP0D80 device (e.g., if multiple DSMs are not
implemented on the same device), by allowing multiple instances of the
device to co-exist.
This is achieved by moving 'supported_functions' from 'struct dsm' into
the softc, so each instance has its own view of which functions are
supported.
Consequently, the check on the instance unit on probe can be removed.
Reviewed by: imp (older version), obiwac
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D56817
...in order to indicate to users that power state constraints will not
be checked at all.
Reviewed by: imp, obiwac
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D56816
In acpi_spmc_get_constraints(), stop assuming that if there is no AMD
DSM, then the Intel one is present. Although this is likely to be the
overwhelming majority of cases on amd64, there is no technical reason
nor constraint in our code that really needs assuming that. On (so far
hypothetical) machines with only the Microsoft DSM, this assumption
would cause a cryptic and irrelevant error message (and, prior to the
previous commit, a panic on INVARIANTS).
Warn the user if both the Intel and AMD DSMs are present, and use the
constraints reported by the Intel one (see the comment for why).
Reviewed by: imp (older version), obiwac
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D56813
Just continue without constraints checking in this case.
To this end, remove the 'constraints_populated' field from 'struct
acpi_spmc_softc' and any reference to it.
However, we introduce another boolean, 'sc->get_constraints_succeeded',
in order to check (under INVARIANTS) that acpi_spmc_get_constraints() is
called only once on success. Calling that function another time after
a success would leak memory. It would be easy to change that function
to support multiple calls (e.g., by adding a call to
acpi_spmc_free_constraints() near its start), however trying to retrieve
the constraints again simply looks like wasted time as the same results
are expected to be returned on each call.
Reviewed by: imp, obiwac
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D56812
This makes things more top-down, as expected when probing devices.
Reviewed by: imp, obiwac
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D56811
Once we have recognized a device by PNP ID, declare support
unconditionally on probe, and only check for DSMs in attach.
We do this for these reasons:
1. PNP0D80 is de-facto a device supposed to hold DSMs related to
suspend-to-idle, so we assume it cannot be used for other purposes.
And if that changes, we need another architecture anyway (e.g., have
a new driver claiming those devices and behaving like a bus, to which
this driver would be a sub-driver).
2. If there are no DSMs that we support on such a device, then a new DSM
was added that the driver does not know about and which "replaces"
(in terms of functionality) the known ones, or the firmware is buggy.
In both cases, failing the attach instead of the probe is reasonable,
as that leads to printing some error which we (and probably users
too) would like to know about.
3. This is a step to enable multiple instances of this driver (just to
be a good citizen, and also to be future proof against weird
firmwares that would, e.g., implement the Microsoft DSM on another
device than the Intel one).
Reviewed by: imp (older version), obiwac
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D56810
We do not check these constraints (yet), so stop printing that they are
verified.
While here, make the (not compiled in at the moment) "constraint
violated" message more terse, and move the warning it contains to
outside of the loop (no need to print it repeatedly if multiple
constraints are violated).
While here, bail out early if there are no constraints to avoid printing
(in the future) that constraints are respected even when there are none.
Reviewed by: imp (older version), obiwac
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D56809
Currently, the "failed to get handle for ..." log messages on attach are
a bit alarming and no context is provided. Print out that these are
retrieved when trying to match constraints and that such failures are
ignored, which should make administrators worry less.
While here, remove duplicated handle retrieving code in
acpi_spmc_check_constraints() because:
1. As is, it is dead code: We 'continue' if the handle is NULL, i.e.,
not already resolved, before trying to resolve it again.
2. This code is called after device suspension, which might make some
objects disappear from the ACPI namespace. In any case, it seems
unlikely that, suddenly, new objects would appear.
Reviewed by: imp, obiwac
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D56808
While here, capitalize their messages.
Reviewed by: imp, obiwac
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D56807
Rename acpi_spmc_get_constraints_intel() and
acpi_spmc_get_constraints_amd() ("get" => "parse") to reflect that they
are actually just parsing the constraints passed by
acpi_spmc_get_constraints().
No functional change (intended).
Reviewed by: imp, obiwac
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D56806
To this end, revamp how DSMs and their functions are represented.
Replace enumerations, which only bring minimal advantages, with plain
macros, allowing to get rid of 'union dsm_index' and in passing the associated bug
that an underlying type smaller than 'int' is aliased to an 'int', which
assumes little-endian architectures. Associate to each function
a printable name, in the form of a per-DSM array that maps a function
index into a string. Make sure that every used array and their number
of items are sized at compile-time and are declared constant, and that
as little code as possible depends on the particular set of present DSMs
and associated functions.
Since the set of DSMs and sets of per-DSM functions are represented as
bitsets, introduce print_bit_field() to print such sets. This new
function is akin to printf("%b", ...) but with more flexibility. It
takes a function associating a name to some bit index and an opaque
pointer, allowing to leverage existing structures containing names
instead of imposing the use of a separate string containing all names to
be printed. It also provides a default name to bits without an explicit
name, composed of a common prefix and the bit index as a suffix.
Reviewed by: imp (older version), obiwac
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D56756
Introduce failed_to_call_dsm(), which prepends "function" before the
function index for better clarity. For now, it prints the function
number, as before, but will soon print a human-readable name.
Reviewed by: imp (older version), obiwac
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D56805
For better readability and because this stance will be used in many
more places in a subsequent commit.
No functional change (intended).
Reviewed by: imp (older version), obiwac
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D56803
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).
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D56802
...through a new function has_dsm(), which slightly simplifies reading.
No functional change (intended).
Reviewed by: obiwac, imp
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D56801
...from acpi_spmc_get_constraints_spec() to
acpi_spmc_get_constraints_intel(), as really there is no ACPI
specification proper and parsing the constraints is done according to
some *Intel* specification (even if it is true that, by contrast, AMD
has none).
No functional change (intended).
Reviewed by: obiwac, imp
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D56800
There is really nothing we can do about a DSM function that works on
first call but fails on subsequent calls, except calling it only once,
which we already do.
While here, soften the comment message, as failure was observed with
some specific machines only.
No functional change.
Reviewed by: emaste, obiwac
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D56799
The fields themselves are not unused, we actually fill them, but once
filled we indeed do not use their values (yet). See the '#ifdef notyet'
section in acpi_spmc_check_constraints().
No functional change.
Reviewed by: emaste, obiwac, imp
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D56798
Create new /dev/power node with super simple ioctl for initiating sleep
state transitions.
This is meant as a generic interface to replace the ACPI- and
APM-specific interfaces. This allows for non-ACPI states to be entered,
such as suspend-to-idle when setting kern.power.suspend=suspend_to_idle.
Reviewed by: markj, olce
Approved by: markj, olce
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D55508
Fix length validation of RTA_MULTIPATH attributes in
nlattr_get_multipath() by making sure the user request is align.
PR: 295102
Reported by: Robert Morris <rtm@lcs.mit.edu>
Reviewed by: markj
Fixes: 7e5bf68495 ("netlink: add netlink support")
MFC after: 3 days
Differential Revision: https://reviews.freebsd.org/D56963
Check for alloction failure on `npt_alloc()` for RTA_MULTIPATH
attributes in `nlattr_get_multipath()`.
Also, add tests for maximum number of rtnexthop in rtnetlink.
Reported by: Joshua Rogers of AISLE Research Team
Reviewed by: markj
MFC after: 3 days
Differential Revision: https://reviews.freebsd.org/D56954
Intersting/relevant changes since bmake-20260313
ChangeLog since bmake-20260313
2026-05-08 Simon J Gerraty <sjg@beast.crufty.net>
* VERSION (_MAKE_VERSION): 20260508
Merge with NetBSD make, pick up
o make.1: fix description of '-' handling in jobs-mod
by intenting it correctly.
2026-04-13 Simon J Gerraty <sjg@beast.crufty.net>
* VERSION (_MAKE_VERSION): 20260406
Merge with NetBSD make, pick up
o cleanup unnecessary parens
* configure.in: add --with-save-dollars to control default for
.MAKE.SAVE.DOLLARS - address FreeBSD PR 294436
mk/ChangeLog since bmake-20260313
2026-05-09 Simon J Gerraty <sjg@beast.crufty.net>
* gendirdeps.mk: also apply ':S,/$,,' and ':C,/(\.[^.]*)$,\1,'
when setting DIRDEPS prior to saving.
* dirdeps.mk: when debugging it is handy to be able to skip
recursing so if DEBUG_DIRDEPS contains 'norecurse' we will only
process the immediate DIRDEPS.
Also if DEBUG_DIRDEPS contains '-V' we process sections normally
skipped when doing 'make -V'.
o ensure we do not get duplicate build dirs due to someone
adding a trailing '/' or '/.${TARGET_SPEC}' to a DIRDEPS entry.
Add ':S,/$,,' when setting '__depdirs' and
add ':C,/(\.[^.]*)$,\1,' when setting '__qual_depdirs'.
2026-04-24 Simon J Gerraty <sjg@beast.crufty.net>
* install-mk (MK_VERSION): 20260424
* Use MK_META_AUTODEP to control use of meta.autodep.mk
so it can be used independently of MK_DIRDEPS_BUILD for
bootstrapping.
* sys.vars.mk (M_type): use :sh rather than :sh1 to avoid
surprises in a .for loop.
The patch in the PR failed to apply, so I manually applied the same
changes.
PR: 295231
Submitted by: Mike Tancsa <mike@sentex.net>
Reviewed by: emaste
Cirrus-CI is shutting down at the end of the month, but we can still
finish with an up-to-date working build with an LLVM version matching
the in-tree toolchain.
Sponsored by: The FreeBSD Foundation
Full release notes are available at
https://www.openssh.com/txt/release-10.2
Selected highlights from the release notes:
Bugfixes
--------
* ssh(1): fix mishandling of terminal connections when
ControlPersist was active that rendered the session unusable.
bz3872
Sponsored by: The FreeBSD Foundation
Full release notes are available at
https://www.openssh.com/txt/release-10.1
Selected highlights from the release notes:
Potentially-incompatible changes
* ssh(1): add a warning when the connection negotiates a non-post
quantum key agreement algorithm.
* ssh(1), sshd(8): major changes to handling of DSCP marking/IPQoS
* ssh(1), sshd(8): deprecate support for IPv4 type-of-service (ToS)
keywords in the IPQoS configuration directive.
* ssh-add(1): when adding certificates to an agent, set the expiry
to the certificate expiry time plus a short (5 min) grace period.
* ssh-agent(1), sshd(8): move agent listener sockets from /tmp to
under ~/.ssh/agent for both ssh-agent(1) and forwarded sockets
in sshd(8).
Security
* ssh(1): disallow control characters in usernames passed via the
commandline or expanded using %-sequences from the configuration
file, and disallow \0 characters in ssh:// URIs.
New features
* ssh(1), sshd(8): add SIGINFO handlers to log active channel and
session information.
Sponsored by: The FreeBSD Foundation
When igmp_v3_merge_state_changes() is iterating over state-change
packets, there is a case where it'll free a queued packet but will fail
to remove it from the queue. Fix that.
Reported by: Yuxiang Yang, Yizhou Zhao, Xuewei Feng, Qi Li, and Ke Xu from Tsinghua University using GLM5.1 from Z.ai
Reviewed by: pouria, glebius
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D56947
vxlan_input()'s caller is supposed to free *m0 if it is non-NULL after
the function returns. vxlan_input() failed to update *m0 after the
pullup however, so if it hits an error case after the pullup, we'll free
the mbuf twice. Currently this can happen only if the interface is
brought down or due to a packet loop.
Reported by: Yuxiang Yang, Yizhou Zhao, Xuewei Feng, Qi Li, and Ke Xu from Tsinghua University using GLM5.1 from Z.ai
Reviewed by: pouria, zlei
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D56944
The _*.h headers are for structure definitions and should avoid
dependencies on other headers. This convention is violated by using
__BEGIN_DECLS/__END_DECLS.
Move the declarations to cpuset.h, I see no reason they can't be there.
Reviewed by: olce, brooks, kib
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D56856
MAXBSIZE is defined in param.h, which defines many other things. To
avoid forcing all consumers of libufs.h to include param.h, let's
instead redefine it and verify the definition in inode.c.
Reviewed by: kib
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D56859
- gjournal.c needs param.h to get a definition of isclr().
- fsck.h needs signal.h for sig_atomic_t.
Sort includes while here.
Reviewed by: kib
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D56858