summaryrefslogtreecommitdiff
path: root/tools/docs/parse-headers.py
diff options
context:
space:
mode:
authorArd Biesheuvel <ardb@kernel.org>2025-10-15 22:56:39 +0200
committerCatalin Marinas <catalin.marinas@arm.com>2025-11-11 18:59:22 +0000
commit7137a203b2515bdbeae1cf13446bdce17db2c2f7 (patch)
tree6ca812f211815c05782b1dc014fb6e5e83d76fcc /tools/docs/parse-headers.py
parent1d038e801833f6dcfd4b18d59f96eca5a963a816 (diff)
arm64/fpsimd: Permit kernel mode NEON with IRQs off
Currently, may_use_simd() will return false when called from a context where IRQs are disabled. One notable case where this happens is when calling the ResetSystem() EFI runtime service from the reboot/poweroff code path. For this case alone, there is a substantial amount of FP/SIMD support code to handle the corner case where a EFI runtime service is invoked with IRQs disabled. The only reason kernel mode SIMD is not allowed when IRQs are disabled is that re-enabling softirqs in this case produces a noisy diagnostic when lockdep is enabled. The warning is valid, in the sense that delivering pending softirqs over the back of the call to local_bh_enable() is problematic when IRQs are disabled. While the API lacks a facility to simply mask and unmask softirqs without triggering their delivery, disabling softirqs is not needed to begin with when IRQs are disabled, given that softirqs are only every taken asynchronously over the back of a hard IRQ. So dis/enable softirq processing conditionally, based on whether IRQs are enabled, and relax the check in may_use_simd(). Acked-by: Will Deacon <will@kernel.org> Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Acked-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Diffstat (limited to 'tools/docs/parse-headers.py')
0 files changed, 0 insertions, 0 deletions