acpi: Post/pre device suspend/resume eventhandlers
These eventhandlers are called after suspending the device tree and
before resuming it. This is useful for PMC (power management controller)
drivers.
Reviewed by: olce
Approved by: olce
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D48735
acpi_spmc: Register SPMC suspend/resume routines
SPMC suspend runs after the device tree is suspended using the
acpi_post_dev_suspend eventhandler, and SPMC resume runs before the
device tree is resumed using the acpi_pre_dev_suspend eventhandler.
Reviewed by: olce
Approved by: olce
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D48735
heimdal: Pass the correct pointer to realloc when growing a string buffer
The realloc in my_fgetln was trying to grow the pointer to the string
buffer, not the string buffer itself.
In function 'my_fgetln',
inlined from 'mit_prop_dump' at crypto/heimdal/kdc/mit_dump.c:156:19:
crypto/heimdal/kdc/mit_dump.c:119:13: error: 'realloc' called on unallocated object 'line' [-Werror=free-nonheap-object]
119 | n = realloc(buf, *sz + (*sz >> 1));
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
crypto/heimdal/kdc/mit_dump.c: In function 'mit_prop_dump':
crypto/heimdal/kdc/mit_dump.c:139:11: note: declared here
139 | char *line = NULL;
| ^~~~
Reviewed by: rmacklem, cy
Fixes: a93e1b731ae4 ("heimdal-kadmin: Add support for the -f dump option")
Differential Revision: https://reviews.freebsd.org/D54933
(cherry picked from commit 03d8ac948b1ad9c419b294c3129b7da58d818363)
iicbb: Fix gcc12 complaint
So gcc12 doesn't understand that t->udelay is >= 1, so thinks that noack
might be unset sometimes. While we specifically constrain this on direct
assignment, there's a sysctl that might not. This is likely also a bug.
Instead of uglifying everything by using MAX(1, sc->udelay), I rewrote
the for loop as a do-while loop (which arguably dictates intent better
because this code clearly assumes it will be executed once).
Sponsored by: Netflix
(cherry picked from commit 4b301f7e7ab43bb61561786c2ab33f3a3c4a725d)
runat: Add -h to manipulate a symlink's named attribute dir
Lionel Cons <lionelcons1972 at gmail.com> requested
that a new option be added to runat(1) so that it could
be used to manipulate named attributes associated with
a symbolic link and not the file the symbolic link refers to).
This patch adds the option -h/--nofollow to do this.
Requested by: Lionel Cons <lionelcons1972 at gmail.com>
Reviewed by: kib
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D55023
sym(4): Map HCB memory as uncacheable also on x86
As part of making the chip-specific mix and match of different accesses
(DMA/bus space) work as desired, the intent is to map the HCB memory as
uncacheable. Prior to VM_MEMATTR_*, the !x86 way of indicating this to
bus_dmamem_alloc(9) was BUS_DMA_COHERENT. Then later on in 2db99100a4,
BUS_DMA_NOCACHE was hooked up to VM_MEMATTR_UNCACHEABLE for x86. As it
turns out, still as of today bus_dmamem_alloc(9) differs in this regard
across architectures. On arm, it still supports BUS_DMA_COHERENT only
for requesting uncacheable DMA and x86 still uses BUS_DMA_NOCACHE only.
On arm64 and riscv, BUS_DMA_COHERENT seems to effectively be an alias
for BUS_DMA_NOCACHE.
Thus, allocate the HCB memory with BUS_DMA_COHERENT | BUS_DMA_NOCACHE,
so we get uncacheable memory on all architectures including x86 and so
loads and stores from/to HCB won't get reordered. However, even on x86
we still need to use at least compiler barriers to achieve the desired
program order.
[10 lines not shown]
Revert "sym(4): Employ memory barriers also on x86"
The problem will be avoided in a different way.
This reverts commit e769bc77184312b6137a9b180c97b87c0760b849.
lang/python314: limit compileall to MAKE_JOBS_NUMBER
This seems to help with cross-builds (qemu) for RISC-V machines.
Obtained from: Siva Mahadevan
Differential Revision: https://reviews.freebsd.org/D55050
rpc: correct resultproc_t's type
It takes exactly three arguments of known type.
Tweak the types of various resultproc_t functions to match the type (mostly
added const to struct pointers) allowing us to drop casts.
Effort: CHERI upstreaming
Reviewed by: vangyzen, glebius
Sponsored by: DARPA, AFRL
Differential Revision: https://reviews.freebsd.org/D54941
clnt_broadcast(3): fix eachresult argument type
The `eachresult` argument is documented to take a function pointer of
type:
bool_t (*)(caddr_t, struct sockaddr_in *)
It was declared to take a resultproc_t which has historically been
declared to be:
bool_t (*resultproc_t)(caddr_t, ...);
This overlapped well enough for currently supported ABIs where variadic
arguments are passed in registers, but this declaration is misaligned
with the documentation (resultproc_t takes three arguments) and will be
fixed in a followup commit.
Fix the type to be non-variadic, matching callbacks, and define a
convenience type of as most callbacks take something other than a char *
[6 lines not shown]
clnt_broadcast(3): don't free function pointers
Replace use of thr_getspecific/thr_setspecific to stash the function
pointer we're smuggling between clnt_broadcast and rpc_wrap_bcast with a
simple thread local variable. Clear it after use so the reference
doesn't linger.
In the relatively unlikely event clnt_broadcast was called from threads
that exited prior to program termination, the previous code called free
on a function pointer, which is undefined and might corrupted allocator
state.
Effort: CHERI upstreaming
Reviewed by: glebius, jhb
Sponsored by: DARPA, AFRL
Differential Revision: https://reviews.freebsd.org/D54939
devel/py-spin: Add new port
Scientific Python INcantations (spin) is a developer tool
for scientific Python libraries.
https://pypi.python.org/pypi/spin
devfs: unlock the directory vnode around the call to dev_clone handler
The lock around dev_clone is unfortunate because cloner might need to
take its own locks that establish the order with devfs vnodes, and then
transiently participates in further VFS locks order. For instance, this
way the proctree_lock or allproc_lock become involved.
Unlock dvp, we can unwind if the vnode become doomed while cloner was
called.
Reported and tested by: pho
Reviewed by: kevans, markj
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D55028
audio/rubberband: fix build with libc++ 21
With libc++ 21 audio/rubberband fails to build, with errors similar to:
In file included from ../src/common/mathmisc.cpp:24:
../src/common/mathmisc.h:58:1: error: unknown type name 'size_t'; did you mean 'std::size_t'?
58 | size_t roundUp(size_t value); // to nearest power of two
| ^~~~~~
| std::size_t
/usr/include/c++/v1/__cstddef/size_t.h:20:7: note: 'std::size_t' declared here
20 | using size_t = decltype(sizeof(int));
| ^
This is because mathmisc.h depended on <stddef.h> being transitively
included, which is no longer the case. Add #include <stddef.h> to fix
the problem.
PR: 292868
Approved by: acm (maintainer)
MFH: 2026Q1
