Mk/Uses/npm.mk: Add support for pnpm >= 12
pnpm 12 has been rewritten in Rust and introduced an
architecture-dependent node module, which is required to be installed
separately from the main node module.
By default, the installation occurs upon the first pnpm execution and
breaks poudriere builds. So prefetch and extract the native executable
to the expected location in advance to avoid breakage.
security/openssl: Security upgrade to 3.5.9
OpenSSL 3.0 is end-of-life and has known vulnerabilities.
Upgrade port to OpenSSL 3.5 by renaming security/openssl35
Security: 0d183075-bcb5-11f1-b09d-8447094a420
MFH: 2026Q3
lang/swift6: lang/swift6: Update to 6.4.0
Swift 6.4 has removed the ability for bootstrapping without a
pre-built host swift compiler. So now the port requires a bootstrap
swift toolchain regardless of the build mode.
The installation paths have been changed from
${PREFIX}/swift6/{bin,include,lib,...} to
${PREFIX}/swift6/usr/local/{bin,include,lib,...} to follow the
standard Swift toolchain layout.
Release Announcement: https://www.swift.org/blog/swift-6.4-released/
Reported by: GitHub (watch releases)
dwc(4): Support a major update of Synopsys IP.
Support new versions 4.x and 5.x of Synopsys DesignWare Gigabit
Ethernet MAC, often referred to as DWC Quality-of-Service IP Core.
In particular:
- version 5_30 (0x53) that is found on stm32mp2 arm64 SoC
- version 5_40 (0x54) that is found on Spacemit K3 RISC-V RVA23 SoC
DWC Ethernet QoS introduced a new scalable multi-channel architecture
with up to eight TX/RX channels, enhanced DCB support, TCP segmentation
offload (TSO).
Thanks to manu@ for start splitting out the DMA code of the older
(dwc version 3.x) driver to separate files in 2023. This patch is
a continuation of that work to support new core and DMA engine.
Thanks to mmel@ for initial review. Initial support covers the same
interface capabilities as the version 3 (VLAN_MTU, HWCSUM, HWCSUM_IPV6).
[5 lines not shown]
net/samba42[234Ø: fix on ZFS STATUS_INTERNAL_ERROR, Input/output error from vfs_freebsd.c
Replace strlcpy() to memmove() in vfs_freebsd.c.
PR: 292618
Reported by: Dave Baukus <daveb at spectralogic.com>
Sponsored by: Klara, Inc
security/openssl30: Resurrect OpenSSL 3.0 port
For FreeBSD 14, expires 2028-11-30
Has known vulnerabilities, users are encouraged to move
to OpenSSL 3.5 from security/openssl
Add security advisories affecting 14.4R, 14.5R, 15.0R and 15.1R
FreeBSD-SA-26:64.sysvsem affects all supported releases
FreeBSD-SA-26:65.kqueue affects 15.1R
FreeBSD-SA-26:66.jail affects all supported releases
FreeBSD-SA-26:67.ktls affects all supported releases
FreeBSD-SA-26:68.openssl affects all supported releases
FreeBSD-SA-26:69.udp affects all supported releases
While here, note that FreeBSD-SA-26:50.kqueue did not affect 15.0R.
if_bnxt: add bnxt logger module files to sys/conf/files for built-in kernel builds
The bnxt snapdump and coredump support patches added bnxt_log/{_data}.c. and listed it in
sys/modules/bnxt/bnxt_en/Makefile, but missed to add these files in sys/conf/files.
Fix up the issue by adding bnxt_log/{_data}.c in sys/conf/files.
Fixes: f85e66e655c9 ("if_bnxt/bnxt_re: add support for driver snapdump")
(cherry picked from commit 03676cafa882c471a29436aae76c8751d451dd07)
if_bnxt: Add support for HWRM passthrough with multiple DMA buffers
Added support for HWRM passthrough commands with multiple DMA buffers.
Also, changed the mgmt_lock to sleepable exclusive lock.
MFC after: 2 weeks
Reviewed by: gallatin, ssaxena
Differential Revision: https://reviews.freebsd.org/D56686
(cherry picked from commit 9d87ca8b9f60bdec0bbc1733920df250a08beb0c)
if_bnxt: add few source files to version control
Commits- f85e66e655c9 ("if_bnxt/bnxt_re: add support for driver snapdump")
and 03839879a2dd ("if_bnxt: Add Firmware crashdump collection support")
missed to add few files under version control, those files are
added now:
sys/dev/bnxt/bnxt_en/bnxt_log.c
sys/dev/bnxt/bnxt_en/bnxt_log.h
sys/dev/bnxt/bnxt_en/bnxt_log_data.c
sys/dev/bnxt/bnxt_en/bnxt_log_data.h
sys/dev/bnxt/bnxt_en/bnxt_coredump.c
sys/dev/bnxt/bnxt_en/bnxt_coredump.h
bnxt_coredump.c entry is added in sys/conf/files as well.
Fixes: f85e66e655c9 ("if_bnxt/bnxt_re: add support for driver snapdump")
Fixes: 03839879a2dd ("if_bnxt: Add Firmware crashdump collection support")
(cherry picked from commit 9931dc5bf3831146c08a381c42ecbfcedb8ac7f1)
if_bnxt: Add Firmware crashdump collection support
This patch adds support for DDR-based firmware coredump memory handling.
It detects firmware coredump capability, allocates host DDR (DMA) memory
for crash dumps, and programs the firmware with the allocated memory during
attach. The allocated memory is released during driver detach.
Also, This patch adds functions to retrieve crash dump data from host DDR
memory. The implementation handles data copying from page tables and
checks dump availability. Main function bnxt_get_coredump() copies
stored crash dump data from DDR memory to the application buffer.
MFC after: 2 weeks
Reviewed by: gallatin, ssaxena
Differential Revision: https://reviews.freebsd.org/D56684
(cherry picked from commit 03839879a2dd2505eab80b99211b0637ebdc9d32)
bnxt: Fix build / load error for bnxt(4) in kernels without PCI_IOV
This change removes the hard-forcing of PCI_IOV and adds shims to
allow the driver to compile and work when the kernel is missing
PCI_IOV support.
Fixes: 7c450d1127c7
Reviewed by: sumit.saxena_broadcom.com
Differential Revision: https://reviews.freebsd.org/D57300
Sponsored by: Netflix
(cherry picked from commit 3118f1b99f23431235c202d9aadbe3d183bcc259)
bnxt: Fix up ioctl opcodes to support IOC_VOID along with IOC_IN
The driver and applications currently use hard-coded numeric ioctl command
opcodes. These opcodes are interpreted as having the IOC_IN direction (data
copied from the user application to the driver), regardless of the actual packet
size. Consequently, when the packet size is zero and the direction is set to
IOC_IN, the kernel fails these ioctls if COMPAT is disabled.
While the driver and applications should ideally set the direction correctly—
for example, using IOC_VOID when the packet size is zero—the driver will now
be updated to define ioctl opcodes using the _IOC macro to support both
IOC_VOID and IOC_IN. This change ensures backward compatibility with older
applications that exclusively use IOC_IN.
Reviewed by: gallatin
Differential Revision: https://reviews.freebsd.org/D54601
MFC after: 3 days
(cherry picked from commit d53d7b466016408229491cfd2f8bdc742ff642e3)
if_bnxt: Fix the Unknown command 0x80000000 ioctl command error
With the latest niccli version, user will observe below
Unknown command command error when try to list the devices.
if_bnxt: Unknown command 0x80000000
Here, niccli is issuing command opcode as 0x80000000 but
driver is expecting 0x20000000 command opcode.
So, replaced _IOW(0,0,0) with the _IOC(IOC_IN,0,0,0).
Fixes: d53d7b4 ("bnxt: Fix up ioctl opcodes to support IOC_VOID along with IOC_IN")
MFC after: 2 weeks
Reviewed by: gallatin, ssaxena
Differential Revision: https://reviews.freebsd.org/D56685
(cherry picked from commit 3987058a3a943c461c27dbebf10dad555b1bb2fa)
if_bnxt/bnxt_re: add support for driver snapdump
Add a logging module which helps to log and collect the driver`s
various events and state of device data structures.
APIs help modules like l2, RoCE etc. to register and
add logs into thg buffers. A segment header is added to the
data available in buffers.
The final log messages are arranged in following fashion
|SegHeader0|Data0|SegHeader1|Data1|
Logging module provides two different kinds of buffers:
a) A large contiguous memory chunk is used to form circular buffers.
Module need to provide a number of buffers while registering to
the logging module.Please note that, since memory for the
buffers remains with the module as long as it is registered, memory
footprints of the driver could be higher so the modules should
allocate an appropriate number of buffers. Also, due to limited
[23 lines not shown]
bnxt_en: VF ring reservation, HWRM registration, and PF-only operation guards
VFs require separate HWRM commands for ring reservation and async
completion ring setup, so a common PF/VF dispatcher is introduced and
the async CR path is extended to handle both. The PF must populate the
VF request forwarding bitmap during driver registration so the firmware
correctly forwards VF-originated HWRM commands. VF reservation strategy
and min-guaranteed capability flags are now parsed for correct resource
partitioning, and PF-only operations (DCB, NVM, package version sysctl)
are guarded against VF invocation.
The short command buffer allocation is also reordered before the function
reset to ensure extended HWRM messages are available when needed, a
prerequisite uncovered during VF bring-up.
MFC after: 1 month
Reviewed by: ssaxena
Differential Revision: https://reviews.freebsd.org/D56232
(cherry picked from commit c972c5acbac472a5dc797856f39f478862b6c6ea)
