Changes in drivers

06c4e95e469c9c89e9ba4a6915d1be7bb8ea6fbc - crypto: asu: send hash address in request buffer for digest

Wed, 08 Apr 2026 09:00:00 +0000

crypto: asu: send hash address in request buffer for digestUpdate driver to read digest from hash address sent to firmwareinstead of response bufferFixes: 74ddb42edbe0 ("crypto: asu: Add crypto hash driver")Signed-off-by: Harish Ediga Acked-by: Jens Wiklander List of files: /optee_os/core/drivers/crypto/asu_driver/asu_hash.c

d80b90ce0df5c4f140ba9642085c54509ee7f5e9 - drivers: asu: guard wfe() with IRQ-mask check and add response timeout

Wed, 08 Apr 2026 07:00:00 +0000

drivers: asu: guard wfe() with IRQ-mask check and add response timeoutThe wfe()-based response loop in asu_update_queue_buffer_n_send_ipi()assumes THREAD_EXCP_NATIVE_INTR is clear at every call site. Thisdoes not hold during early boot: boot_init_primary_final() re-masks allexceptions including THREAD_EXCP_NATIVE_INTR at boot.c:1103 beforecalling thread_update_canaries() -> hw_get_random_bytes(). WithPSTATE.I=1 the GIC cannot deliver SPI 89 (ASU doorbell),asu_resp_handler() never fires, sev() is never called, and wfe() blocksindefinitely.Fix the response loop with two changes:1. Arm a 2s safety timeout unconditionally before the loop so ASU firmware failures surface as TEE_ERROR_TARGET_DEAD rather than a silent hang.2. Sample thread_get_exceptions() immediately before each wfe() call with no intervening code between the check and the instruction. This closes the TOCTOU window where the exception mask could change between a snapshot taken before the loop and the actual wfe(). - THREAD_EXCP_NATIVE_INTR clear (IRQs unmasked): wfe() yields the CPU; asu_resp_handler() fires sev() to wake it on response. - THREAD_EXCP_NATIVE_INTR set (IRQs masked): udelay(10) throttles the busy-poll, avoiding both a wfe() hang and uncontrolled bus hammering.asu_resp_handler() retains its sev() call to support the wfe() path.Fixes: 7f2d4e10736f ("drivers: amd: Add ASU support")Signed-off-by: Akshay Belsare Acked-by: Jens Wiklander List of files: /optee_os/core/drivers/amd/asu/asu_main.c

ac59b32ba611b6685830f5949ec32bd6a73fd4f7 - drivers: imx: rngb: soft reset in case of errors

Mon, 26 Jan 2026 10:00:00 +0000

drivers: imx: rngb: soft reset in case of errorsSoft reset the RNGB core before retrying, if errors are logged in theESR register.The i.MX 6ULL Applications Processor Reference Manual states in theRNG_CR[MASKERR] field description about errors in ESR: All errors are considered fatal, requiring the RNGB to be reset. Until the reset occurs, the RNGB does not service any random data.It was observed that issuing CMD[CE|CI] (Clear error / interruptcommand) did not clear the ESR[SATE] (Statistical test error) stateas expected. Issuing CMD[SR] (Software reset) instead, as suggestedby the reference manual, works.Signed-off-by: Philipp Zabel Acked-by: Jorge Ramirez-Ortiz List of files: /optee_os/core/drivers/imx_rngb.c