Re: [PATCH v49 3/7] firmware: imx: add driver for NXP EdgeLock Enclave
From: sashiko-bot@kernel.org
Date: 2026-09-08 12:03:01
Also in:
imx
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider: - [Medium] Unchecked return value of dma_set_mask_and_coherent() can break system suspend and cause silent truncation. -- commit 11689bad8661c5539198f994ba798438370f3e15 Author: Pankaj Gupta [off-list ref] Subject: firmware: imx: add driver for NXP EdgeLock Enclave This commit introduces the driver for the NXP EdgeLock Enclave (ELE). It adds a messaging-unit based communication interface for secure enclaves on i.MX SoC platforms, managing firmware authentication, loading, and suspend/resume states.
quoted hunk ↗ jump to hunk
diff --git a/drivers/firmware/imx/se_ctrl.c b/drivers/firmware/imx/se_ctrl.c index 0000000000000..4b9354b0e24aa 100644 --- /dev/null +++ b/drivers/firmware/imx/se_ctrl.c
[ ... ]
quoted hunk ↗ jump to hunk
@@ -396,6 +396,16 @@ static int se_if_probe(struct platform_device *pdev) + if (if_node->reserved_dma_ranges) { + ret = of_reserved_mem_device_init(dev); + if (ret) + return dev_err_probe(dev, ret, + "Failed to init reserved memory region.\n"); + } + + dma_set_mask_and_coherent(dev, DMA_BIT_MASK(32));
[Severity: Medium] Is it safe to ignore the return value of dma_set_mask_and_coherent() here? If the platform cannot satisfy the 32-bit DMA mask requirement, this will fail silently but the probe will succeed anyway. Later, if DMA allocations (like imem.buf or firmware images) return physical addresses above 32 bits, functions like ele_service_swap() or ele_fw_authenticate() will explicitly reject them with -ERANGE or -EINVAL. This could render the enclave non-functional and break system suspend. Should we check the return value and fail the probe if the required DMA mask isn't supported?
+ + /* + * Initialize load_fw_lock before registering the misc device.
-- Sashiko AI review · https://sashiko.dev/#/patchset/20260908-imx-se-if-v49-0-a59529118839@nxp.com?part=3