devel/llvm-devel: new snapshot, aarch64 improvements
Enable COMPILER_RT, FLANG, and OPENMP options. Flang requires a
patch to make not compile quadmath functions requiring C11 functionality
FreeBSD hasn't implemented. It's unclear to me why we're attemping
to compile them on aarch64 and not other targets, but it's easy to
just ifdef out the file and this should match x86.
virtio_gpu: use an X8R8G8B8 resource on big-endian guests
The virtio-gpu resource formats are defined by byte order in memory,
while vt(4) and the X server (through vt_fb and the fb mmap) write
native 32-bit 0x00RRGGBB pixels into the shadow framebuffer. On a
big-endian guest such as powerpc64 those pixels land in memory as
00 RR GG BB, which the host interprets under B8G8R8X8 with red and
blue swapped and the padding byte taken as blue: white renders yellow
and blue renders black.
Request X8R8G8B8 on big-endian guests instead, which is also what the
Linux driver does (DRM_FORMAT_HOST_XRGB8888). Reproduced with a colour
test pattern on a powerpc64 QEMU pseries guest using the identically
coded out-of-tree fork of this driver (graphics/virtio-gpu-qemu-kmod);
little-endian guests are unchanged.
Differential Revision: https://reviews.freebsd.org/D60085
Approved by: jhibbits
MFC after: 1 week
[3 lines not shown]
virtio_gpu: use an X8R8G8B8 resource on big-endian guests
The virtio-gpu resource formats are defined by byte order in memory,
while vt(4) and the X server (through vt_fb and the fb mmap) write
native 32-bit 0x00RRGGBB pixels into the shadow framebuffer. On a
big-endian guest such as powerpc64 those pixels land in memory as
00 RR GG BB, which the host interprets under B8G8R8X8 with red and
blue swapped and the padding byte taken as blue: white renders yellow
and blue renders black.
Request X8R8G8B8 on big-endian guests instead, which is also what the
Linux driver does (DRM_FORMAT_HOST_XRGB8888). Reproduced with a colour
test pattern on a powerpc64 QEMU pseries guest using the identically
coded out-of-tree fork of this driver (graphics/virtio-gpu-qemu-kmod);
little-endian guests are unchanged.
Differential Revision: https://reviews.freebsd.org/D60085
Approved by: jhibbits
MFC after: 1 week
[2 lines not shown]
audio/neuralrack-lv2: fix packaging on non-amd64
Name the VST3 bundle directory after the compiler target instead of
uname -m, which is the platform (powerpc, arm64) on FreeBSD, and make
pkg-plist follow ARCH.
(cherry picked from commit 6e11c236419afce9175df1daa5b2fb9518f69622)
graphics/photivo: the port had been slightly improved (+)
- Stretch out CMAKE_MINIMUM_REQUIRED() version range to
accommodate for upcoming CMake 4.x and beyond
- Drop `dos2unix' from USES in favor of PATCH_ARGS+=-l
security/vuxml: add FreeBSD SAs issued on 2026-10-14
FreeBSD-SA-26:70.tcp affects 15.1R
FreeBSD-SA-26:71.sound affects all supported releases
FreeBSD-SA-26:72.bhyve affects all supported releases
iwm: add return status to set/clear prph bits
This brings these functions inline with OpenBSD
Locally tested:
* 3160, STA mode
* 7260, STA mode
* 8260, STA mode
* 9260, STA mode
Obtained from: OpenBSD a6e25c727a2214219715b51ba6af2221d7e0d674
Reviewed by: emaste
Differential Revision: https://reviews.freebsd.org/D60211
iwm: update phy context routines; add HT channel width parameter
Update the phy context routines to match what the openbsd snapshot
is doing. This involves some HT channel width stuff which although
I am not doing HT right now, it was juts easier to sync these
entirely versus just a partial sync.
* Update the phy context routines to match what openbsd is doing
* Although the openbsd driver has an iwm_phy_ctxt_update() routine
instead of add and modify, I'm leaving it as-is for now.
A bunch of refactoring is going to need to be done to properly
use an iwm_phy_ctxt_update() call and I didn't want to tackle
that in here.
* Add a UHB firmware capability phy context call; I can't test it
but it's mostly copy/paste.
* Add in a util to turn ieee80211_channel into the 'sco' variable
(the HT low/hi parameter) since it's done in openbsd in a
slightly different way.
[10 lines not shown]
iwm: bring IWM_CSR_HW_IF_CONFIG_REG programming in line with openbsd
bring the iwm_nic_config() / IWM_CSR_HW_IF_CONFIG_REG programming
in line with openbsd.
Locally tested:
* 3160 STA mode
* 7260 STA mode
* 8260 STA mode
* 9260 STA mode
Obtained from: OpenBSD a6e25c727a2214219715b51ba6af2221d7e0d674
Differential Revision: https://reviews.freebsd.org/D60081
iwm: add DQA (dynamic queue assignment)
This is the minimum set of DQA bits from iwm at the given openbsd
commit place.
* add a method to map ac to queue / ring
* use the DQA command queue if needed
* glue to wire it up
Locally tested:
* Intel 7260, STA mode
* Intel 9260, STA mode
* Intel 8260, STA mode
* Intel 3160, STA mode
Obtained from: OpenBSD a6e25c727a2214219715b51ba6af2221d7e0d674
Differential Revision: https://reviews.freebsd.org/D60080
nfs_nfsdsocket.c: Fix "nfsstats -d" for ERELOOKUP
When ERELOOKLUP is returned by a file operation
(always vop_lookup?) the operation is retried without
doing nfsrv_statsend().
This patch fixes this problem,
The only effect of the bug was bogus "nfsstat -d"
output.
PR: 298534
(cherry picked from commit 9a237074d380233e93a17ddee6b155cc2f90ee96)
nfs_nfsdsocket.c: Fix "nfsstats -d" for ERELOOKUP
When ERELOOKLUP is returned by a file operation
(always vop_lookup?) the operation is retried without
doing nfsrv_statsend().
This patch fixes this problem,
The only effect of the bug was bogus "nfsstat -d"
output.
PR: 298534
(cherry picked from commit 9a237074d380233e93a17ddee6b155cc2f90ee96)
