Port amd64 fix for PR port-xen/58561 to i386, with one extra fix:
with recent Xen (maybe since pvshim), traps handlers are called with
interrupts enabled, so adjust the i386 assembly code for this.
updating curcup()->ci_vcpu->evtchn_upcall_mask requires 2 intructions, e.g.
movl CPUVAR(VCPU),reg
movb $1,EVTCHN_UPCALL_MASK(reg)
With preemption enabled we may be moved to another CPU between the
2 intructions and we end up updating the evtchn_upcall_mask of another VCPU
than the one we're now running on.
Fix for Xen/i386:
- Add a CLI2 macro, which disables preemtion before the above sequence.
Use it instead of CLI where preemtion may be enabled
- Add DIAGNOSTIC code to check that preemtion is disabled in CLI
- Add DIAGNOSTIC code to check that interrupts are disabled when calling STI and STIC
- rename PUSHF to PUSHFCLI and change it to both read and disable
EVTCHN_UPCALL_MASK with preemption disabled
- remove the XENPVHVM version of STIC which is unused
updating curcup()->ci_vcpu->evtchn_upcall_mask requires 2 intructions, e.g.
movq CPUVAR(VCPU),%r ## temp_reg ;
movb $1,EVTCHN_UPCALL_MASK(%r ## temp_reg);
With preemption enabled we may be moved to another CPU between the
2 intructions and we end up updating the evtchn_upcall_mask of another VCPU
than the one we're now running on.
Fix for Xen/amd64:
- Add a CLI2 macro, which disables preemtion before the above sequence.
Use it instead of CLI where preemtion may be enabled
- Add DIAGNOSTIC code to check that preemtion is disabled in CLI
- Add DIAGNOSTIC code to check that interrupts are disabled when calling STI
while there, remove PUSHF/POPF macros which are unused
Hopefully fixes PR port-xen/58561
Thanks to Konrad Schroder for testing and Taylor R Campbell for review.
PR toolchain/59652 DNS utilities core dump in -current
Fix the alignment of TLS initialised data for __HAVE_TLS_VARIANT_I
platforms by registering the largest alignment required and allocating
memory accordingly. Additionally calculate correct offsets for each
object's data relative to the end of the struct tls_tcb placed at the
beginning of the TCB.
This makes the tests/libexec/ld.elf_so:t_tls_alignment pass.
I also tested it against a program that attempts to dlopen a DSO that
(erroneously) attempts to use tls_model("initial-exec") and it correctly
failed with
Use of initialized Thread Local Storage with model initial-exec and dlopen is not supported
py-stripe: updated to 14.2.0
14.2.0
Update generated code
Add support for event notifications V2CoreAccountClosedEvent, V2CoreAccountCreatedEvent, V2CoreAccountIncludingConfigurationCustomerCapabilityStatusUpdatedEvent, V2CoreAccountIncludingConfigurationCustomerUpdatedEvent, V2CoreAccountIncludingConfigurationMerchantCapabilityStatusUpdatedEvent, V2CoreAccountIncludingConfigurationMerchantUpdatedEvent, V2CoreAccountIncludingConfigurationRecipientCapabilityStatusUpdatedEvent, V2CoreAccountIncludingConfigurationRecipientUpdatedEvent, V2CoreAccountIncludingDefaultsUpdatedEvent, V2CoreAccountIncludingFutureRequirementsUpdatedEvent, V2CoreAccountIncludingIdentityUpdatedEvent, V2CoreAccountIncludingRequirementsUpdatedEvent, and V2CoreAccountUpdatedEvent with related object v2.core.Account
Add support for event notification V2CoreAccountLinkReturnedEvent
Add support for event notifications V2CoreAccountPersonCreatedEvent, V2CoreAccountPersonDeletedEvent, and V2CoreAccountPersonUpdatedEvent with related object v2.core.AccountPerson
Fix DeprecationWarning when encoding StripeObject metadata
Update ci to run on Python 3.14 as well
hackrf: updated to 2026.01.2
HackRF 2026.01.2 Release Notes
This is a firmware bug fix release. There are no changes to host software.
Changes in this release include:
- Fixed RX, TX, and self-test on rad1o.
- Fixed intermittent tuning failures with SDR++.
- Fixed intermittent spectrum inversion in RX mode when changing the sample
rate on HackRF Pro.
fdt: add basic usb nodes support.
The Odriod-C1 has an internal USB node with a reset GPIO. The USB node
support here detects the usb node (in this case a device) and {,de-}asserts
the GPIO pin.
The Linux device tree specification for this is less than ideal.
Done correctly with the "fdt" interface attribute on the dwctwo_fdt
attachment now that this is supported in the config(5) system.
With a big thankyou to Jason.
Allow "attach" directives to have interface attributes, rather than
restricting them to plain attributes only.
Consider the case of a USB controller for which there is a generic
driver with multiple front-end bus attachments. Normally, a USB
controller driver carries the interface attribute necessary to attach
a USB root hub / bus instance. But, on some systems, a platform-specific
attachment may have other nodes in the device tree that are needed to
enable or configure the USB controller, that appear in the device tree
as children of the USB controller. These devices may need to attach
using a different interface attribute, unrelated to USB functionality.
Prior to this change, it would have been necessary to put the platform-
specific interface attribute onto the generic driver. But that comes
with side-effects on other platforms where that driver might be used.
In an ideal scenario, an attachment with special requirements should be
able to carry attachment-specific interface attributes to handle those
requirements, and this change enables that. When searching for prospective
[14 lines not shown]
bootimage: make ${FATFILES} dependency more explicit for readability
Only add the FATFILES -> TARGETFS dependency in Makefile.bootimage
when FATFILES is defined in MD Makefiles.
This makes the optional nature of FATFILES clearer for MD ports and
avoids relying on empty-target handling as an implicit make(1) behavior.
