[LangRef] Specify that syncscopes can affect the monotonic modification order
If a target specifies that atomics with mismatching syncscopes appear
non-atomic to each other, there is no point in requiring them to be ordered in
the monotonic modification order. Notably, the [AMDGPU target user
guide](https://llvm.org/docs/AMDGPUUsage.html#memory-scopes) has specified
syncscopes to relax the modification order for years.
So far, I haven't found an example where this less constrained ordering would
be observable (at least with the AMDGPU inclusive scope rules). Whenever a load
would be able to see two monotonic stores with non-inclusive scope, that's
considered a data race (i.e., the load would return `undef`), so it cannot be
used to observe the order of the stores.
[AMDGPUUsage] Specify what one-as syncscopes do
This matches the currently implemented and (as far as I could determine)
intended semantics of these syncscopes.
The sync scope table is unchanged except for removing its indentation;
otherwise it would be rendered as part of the preceding note.
[LangRef][AMDGPU] Specify that syncscope can cause atomic operations to race (#189015)
Targets should be able to specify that the syncscope of atomic operations
influences whether they participate in data races with each other.
For example, in AMDGPU, we want (and already implement) the load in the
following case to be in a data race (i.e., return `undef` according to the
current definition), because there is an atomic store with workgroup syncscope
executing in a different workgroup:
```
; workgroup 0:
store atomic i32 1, ptr %p syncscope("workgroup") monotonic, align 4
; workgroup 1:
store atomic i32 2, ptr %p syncscope("workgroup") monotonic, align 4
load atomic i32, ptr %p syncscope("workgroup") monotonic, align 4
```
[3 lines not shown]
bnxt_en: Address review comments for core SR-IOV support
This patch addresses the code review comments provided for:
https://reviews.freebsd.org/D56197
* P7 VF PCI ID: rename NETXTREME_E_P7_VF to E_P7_VF (P7/Thor2 line drops the
Netxtreme name in product strings; other VF device IDs are unchanged).
* Use the return value of bnxt_vf_parse_schema() in bnxt_iov_vf_add() to
decide when to call bnxt_set_vf_admin_mac(); make parse_schema() return
bool and remove the has_admin_mac field.
* In bnxt_free_vf_resources(), fix indentation after dma_free_coherent() so
the NULL assignment is clearly separate from the call.
* In bnxt_hwrm_func_vf_resource_free(), use first_vf_id/last_vf_id in the
HWRM_FUNC_VF_RESC_FREE loop.
MFC after: 1 month
Reviewed by: ssaxena
Differential Revision: https://reviews.freebsd.org/D56644
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
bnxt_en: Re-enable SR-IOV after firmware reset
When the firmware undergoes a hot-reset and the driver re-opens the
device, previously active Virtual Functions lose their resource
configuration. bnxt_reenable_sriov() restores that configuration by
replaying bnxt_cfg_hw_sriov() with the saved resource parameters.
The function is called from bnxt_fw_reset_task() in the
BNXT_FW_RESET_STATE_OPENING state, guarded by #ifdef PCI_IOV.
Because bnxt_cfg_hw_sriov() is a no-op when active_vfs is zero the
call is safe on any PF regardless of whether VFs were ever created.
MFC after: 1 month
Reviewed by: ssaxena
Differential Revision: https://reviews.freebsd.org/D56201
bnxt_en: Add per-VF trust, spoof-check and promiscuous controls
Expose per-VF policy knobs via the FreeBSD sysctl tree and enforce
them at the data-path level.
Trust (dev.bnxt.<unit>.vfN.trusted):
bnxt_set_vf_trust() sets/clears BNXT_VF_TRUST and sends
HWRM_FUNC_CFG with FLAGS_TRUSTED_VF_ENABLE/DISABLE.
bnxt_create_trusted_vf_sysctls() / bnxt_destroy_trusted_vf_sysctls()
manage the sysctl lifetime with VF creation/teardown.
Spoof-check (dev.bnxt.<unit>.vfN.spoofchk):
bnxt_set_vf_spoofchk() issues HWRM_FUNC_CFG with
SRC_MAC_ADDR_CHECK_ENABLE/DISABLE.
Promiscuous gating:
bnxt_is_trusted_vf() queries firmware via HWRM_FUNC_QCFG.
bnxt_promisc_ok() returns false for untrusted VFs, preventing them
from entering promiscuous mode. bnxt_promisc_set() is updated to
[9 lines not shown]
bnxt_en: Add VF forwarded HWRM request handling
Enable the Physical Function to proxy HWRM commands issued by Virtual
Functions through the firmware forwarded-request mechanism.
When a VF issues a command that requires PF arbitration, the firmware
delivers a CMPL_BASE_TYPE_HWRM_FWD_REQ completion to the PF async ring.
* bnxt_process_async_msg() recognises CMPL_BASE_TYPE_HWRM_FWD_REQ,
identifies the originating VF by its firmware function ID, sets the
corresponding bit in pf.vf_event_bmap, and raises
BNXT_HWRM_EXEC_FWD_REQ_SP_EVENT to schedule deferred processing.
* bnxt_sp_task() dispatches to bnxt_hwrm_exec_fwd_req(), which iterates
over all pending VF bits and calls bnxt_vf_req_validate_snd() for each.
* bnxt_vf_req_validate_snd() inspects the encapsulated request type:
HWRM_FUNC_VF_CFG (MAC change) is handled by bnxt_vf_configure_mac()
which enforces trust/existing-MAC rules; HWRM_CFA_L2_FILTER_ALLOC is
[8 lines not shown]
[libc][math] Refactor fmin family to header-only (#194549)
Refactors the fmin math family to be header-only.
part of: #147386
Target Functions:
- fmin
- fminbf16
- fminf
- fminf128
- fminf16
- fminl
bnxt_en: Add VF load path and PF/VF context differentiation
Teach the driver to distinguish a Physical Function from a Virtual
Function at probe time and configure each appropriately.
* Introduce bnxt_is_vf_device() to identify all known VF device IDs
(NetXtreme-C/E Gen1-3, Thor1/2, Hyper-V variants). Add corresponding
PVID entries to bnxt_vendor_info_array.
* Refactor the iflib shared context: rename bnxt_sctx_init to
bnxt_sctx_template, add a Thor2-specific bnxt_sctx_template_p7, and
build per-call PF/VF instances via bnxt_init_sctx_variants(); the VF
instance carries IFLIB_IS_VF. bnxt_register() selects the correct sctx.
* bnxt_attach_pre(): replace the hard-coded NPAR/VF switch with
bnxt_set_flags_by_devid(); on a VF call bnxt_approve_mac() to request
PF approval for the firmware-assigned MAC address.
* bnxt_hwrm_func_qcaps(): populate fw_fid and MAC for PF and VF contexts
[12 lines not shown]
ImageMagick, p5-PerlMagick: Update to 7.1.2.21
7.1.2-21 - 2026-04-21
Commits
release c86de04
7.1.2-20 - 2026-04-21
Merged
Fix JXL orientation when writing. #8673
build(deps): bump actions/upload-artifact from 7.0.0 to 7.0.1 #8677
Commits
beta release f601163
Use the version instead of sha in the version of the AppImage. 3ec02c4
Corrected the patch that was made earlier to fix reading JPEG compressed TIFF images (dlemstra/Magick.NET/issues/1993) 3da25c6
eliminate deprecated omp_set_nested() e529068
[275 lines not shown]
PR/60214: panic: kernel diagnostic assertion "(armreg_ttbcr_read() & TTBCR_S_PD0) != 0" failed
TTBCR.PD[01] are only present in an implementation that includes the Security
Extensions. Relax the KASSERTs so that TTBCR.PD[01] value checks are only done
when security extensions are present
[clang][bytecode] Add a missing fallthrough() call (#194537)
When the local variable is enabled but we don't emit any dtor
instructions, we need to fallthrough to the `EndLabel`.
Make links to drivers man in hardware.adoc
Reviewed by: carlavilla, mhorne
Approved by: carlavilla
Differential Revision: https://reviews.freebsd.org/D56646
PR: 283060
[mlir][tosa] Make tosa-attach-target optional in addTosaToLinalgPasses (#193467)
addTosaToLinalgPasses unconditionally scheduled tosa-attach-target, thus
adding a `tosa.target_env` attribute to the module. Callers therefore
had no way to opt out of such attribute. This attribute is consumed if
validationOptions is enabled, which is optional. Therefore, if the
caller disables validationOptions, the tosa-attach-target attribute will
exist even after TosaToLinalg. So consumers that don't load the TOSA
dialect can't even parse the resulting module.
This PR makes sure that we schedule tosa-attach-target only when the
caller actually needs it, i.e. when validationOptions or
attachTargetOptions is set. The default values stay inside the
`!attachTargetOptions` branch so callers that set validationOptions
still get a target env to validate against, preserving existing
behavior.
Also add a `validation` pipeline option (default `true`) to the
registered `tosa-to-linalg-pipeline`, so it can be invoked without
scheduling either `tosa-attach-target` / `tosa-validate`. A lit test is
also added.
[clang-tidy] Fix UB in SuspiciousIncludeCheck when IgnoredRegex is not set (#194521)
When the "IgnoredRegex" option is not set, `IgnoredRegexString` is
default-constructed, i.e. initialized with a null data pointer. This is
passed to `llvm_regcomp` as the pattern argument, causing a nullptr+0 UB
in regcomp.c (caught by UBSan). Fix by initializing
`IgnoredRegexString` with an empty string literal instead.
