libjail, jls(8), jail(8): use the JAIL_PARAM_* constants
Replaced hardcoded jail parameter name strings in the base userland
consumers with the JAIL_PARAM_* constants.
No functional change.
Reviewed by: jamie, adrian
Differential Revision: https://reviews.freebsd.org/D59577
linuxkpi: Add `int_sqrt()`
The implementation comes from `isqrt64()` in `sys/cam/cam_iosched.c`. It
is modified to take an `unsigned long` and return an `unsigned int`.
The i915 DRM driver started to use it in Linux 6.15.
Reviewed by: bz
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D58251
jail: define well-known parameter names in sys/jail.h
Userland jail managers hardcode jail parameter name strings; nothing
in the headers has ever named them, even when sys/jail.h already
has JAIL_META_PRIVATE/JAIL_META_SHARED for the metadata pair.
Added JAIL_PARAM_* string constants for the static parameters registered
by the base kernel.
No functional change.
MFC After: 1 week
Reviewed by: jamie, adrian
Differential Revision: https://reviews.freebsd.org/D59572
ig4: Add Lunar Lake-M I2C controllers 4 and 5
Commit 851dffef532a added the Lunar Lake-M I2C controllers 0 through 3
(0xa878-0xa87b), which sit on PCI device 0x15. The platform exposes two
further controllers at 0xa850 and 0xa851 on PCI device 0x19, reported by
Intel as I2C #4 and #5. This mirrors the layout already handled for
Arrow Lake-U, where both the 0x777x and 0x775x ranges are listed.
On an HP OmniBook X Flip 16-as0xxx (Core Ultra 9 288V) the firmware
enables only four of the six controllers, and both HID devices sit on
the two that were missing: an ELAN2514 touchscreen on controller 4 and
a SYNA3503 touchpad on controller 5. Neither attaches without this
change, so the machine has no working pointing device.
Like the other four, these use the Tiger Lake revision of the I2C IP;
Linux treats 0xa850/0xa851 identically to 0xa878-0xa87b in
intel-lpss-pci.c.
Tested on: HP OmniBook X Flip 16-as0xxx (Intel Core Ultra 9 288V)
[4 lines not shown]
MAINTAINERS/CODEOWNERS: Scheduling/Priorities: Add a bit more files
These files are not about scheduling per se but about priority
management, mostly from user space.
ng_hci: build the devd notification in a stack buffer
sbuf_new_auto() sleeps, and ng_hci_default_rcvmsg() can run under the
raw HCI socket pcb mutex held across NG_SEND_MSG_PATH().
Reported by: WITNESS
Fixes: ad91d47db306
Reviewed by: glebius, adrian
Differential Revision: https://reviews.freebsd.org/D59550
MAINTAINERS/CODEOWNERS: Add myself to scheduler files
I have been the de-facto maintainer for a few years now.
Also mention the #scheduler group for reviews on Phabricator.
Sponsored by: The FreeBSD Foundation
tests/fib_lookup: Fix compilation by adding SYSDIR
This module is intended to compile in its own directory.
Therefore, the SYSDIR is not defined by default. See 0433870efefc.
Fixes: 8e985774117d ("kern: Remove needless kern.opts.mk")
dpaa2: Allocate DMA tag per Rx buffer
Previously each channel allocated its own set of buffers using the
channel's DMA tag which causes a DMA lock contention under load.
Even a single saturated 1 Gbps link caused ~50,000 adaptive
mutex spin events (as per lockstat) per second. With the proposed
approach there's no more contention on the channel's DMA mutex and the
adaptive mutex spin events dropped to ~6,000/s.
Stress test where iperf3 pushed as much traffic as possible to the 4
ports revealed that throughput drops from expected 940 Mbps down to
600-800 on each link with the "bounce pages lock" generating ~110,000
adaptive mutex spin events per second, but this is to be addressed
later on.
Tested by: flo_purplekraken.com, gnikl_justmail.de, bofh@
MFC after: 3 weeks
Differential Revision: reviews.freebsd.org/D59463
Event: EuroBSDcon Devsummit 2026
LinuxKPI: Fix DMA_BIDIRECTIONAL and other mappings
In dma_sync_single_for_cpu(), the DMA_BIDIRECTIONAL direction currently
performs BUS_DMASYNC_POSTREAD followed by BUS_DMASYNC_PREREAD. This
patch corrects the mapping to use BUS_DMASYNC_POSTREAD |
BUS_DMASYNC_POSTWRITE.
When ownership of the DMA area is transferred to the CPU, we must assume
the previous device access was bidirectional. Both POST operations are
necessary to ensure the CPU sees a consistent view of memory after
potential device reads and writes. A PREREAD is unnecessary here because
the device will no longer access the memory since ownership has been
transferred to the CPU.
Conversely, for dma_sync_single_for_device(), ownership is being
transferred back to the hardware. The buffer must be prepared for
potential bidirectional access by the device, requiring
BUS_DMASYNC_PREREAD | BUS_DMASYNC_PREWRITE.
[9 lines not shown]
usbdevs: add TP-Link Archer T4U ver 3
USB Vendor:Product 0x2357:0x0115
The data was provided by Pavel Timofeev (timp87 gmail com)
and the device will be supported by rtw88 USB (rtw8822bu.c)
in the future.
(cherry picked from commit 95e9c3b1aa9fb2e78295e5053e1e84afad938e31)
LinuxKPI: Correct nents passed to dma_{un,}map_sg_attrs()
According to Linux documentation the nents argument to dma_unmap_sg()
must be the number one passed in, not the number of DMA addresses.
In LinuxKPI this means orig_nents and not nents, so adjust this.
Given nents and orig_nents should always be the same in LinuxKPI,
this should only be a NOP for correctness.
Reviewed by: bz, aokblast (LGTM)
Differential Revision: https://reviews.freebsd.org/D57842
(cherry picked from commit 33574d47d9dea317b9a4bfe543c4f20be6a565ef)
LinuxKPI: implement dma_sync_sg_for_{cpu, device}()
Implement dma_sync_sg_for_{cpu, device}() and
dma_sync_sgtable_for_device().
These functions are useful for my GSoC 2026 project, udmabuf.
Reviewed by: bz
Differential Revision: https://reviews.freebsd.org/D57766
(cherry picked from commit 9dec0cd79c693951fc58d82a99918fc5a02cbcd0)
ath10k: remove some early FreeBSD-specific debugging
The extra DELAY seems to no longer be needed and the dump_stack()
is definitively a problem now. Remove all this.
Sponsored by: The FreeBSD Foundation
(cherry picked from commit 523c3992cf9e50dce7948372ef703f0057e22561)
LinuxKPI: 802.11: implement cfg80211_calculate_bitrate()
lkpi_cfg80211_calculate_bitrate_vht() was constantly showing up
in my debug traces as a TODO with rtw89 so I went ahead and implemented
the HT and VHT versions. Realtek seems to limit amsdu sizes based
on the value and ask for it whether needed or not.
Sponsored by: The FreeBSD Foundation
(cherry picked from commit 654cffe59dd6c8818241bf44eff333af28e10168)
LinuxKPI: 802.11: add != NULL check in ieee80211_tx_status_ext()
There seems to be another possible race with net80211 state machine
changing the bss from under us (another lvif_bss_synched case).
Just do the != NULL check to avoid a NULL pointer deref in
ieee80211_ratectl_rate().
(bz extended the original comment and wrote the commit message).
Sponosred by: The FreeBSD Foundation (commit)
PR: 297184
(cherry picked from commit 0211e64ce1e5ba208f4b96453ce6740a49689b91)
LinuxKPI: 802.11: assert wiphy lock for lkpi_bss_info_change() and MO
Finish reviewing all callers for lkpi_80211_mo_link_info_changed() and
lkpi_80211_mo_bss_info_changed(), which are called from
lkpi_bss_info_change() only. Add the lockdep_assert_wiphy() to
lkpi_bss_info_change() and make sure all callers are holding the
wiphy lock.
PR: 297228
Sponsored by: The FreeBSD Foundation
(cherry picked from commit d1057074b277443e11b04e8513acdf43fd133123)
LinuxKPI: 802.11: deal with wdev list, and misc
Fill in more (lvif) wdev details and add it to the list under the wiphy
struct so that iterators at least work and find the (one) device.
This is needed for the upcoming espwl(4) driver.
misc: add WPI-SMS4 to the list of cipher suits (we won't support it but
at least print the name).
(cherry picked from commit 3e42109d846766248b7d0d0b077543ffc1a9db22)
