drivers: firmware: imx: fix dependency for IMX_SEC_ENCLAVE#31
Closed
MaxKrummenacher wants to merge 1 commit into
Closed
drivers: firmware: imx: fix dependency for IMX_SEC_ENCLAVE#31MaxKrummenacher wants to merge 1 commit into
MaxKrummenacher wants to merge 1 commit into
Conversation
IMX_SEC_ENCLAVE access the 'nvmem', thus on i.MX 8DXL/QXP/QM the following is required: NVMEM_IMX_OCOTP_SCU. Add it to the depends. With a missing NVMEM_IMX_OCOTP_SCU or with IMX_SEC_ENCLAVE=y and NVMEM_IMX_OCOTP_SCU=m we get repeated kernel messages as follows: kern :err : [ 1.911106] fsl-se secure-envlave-1: Fail to read FIPS fuse kern :err : [ 1.921674] fsl-se secure-envlave-1: Failed to fetch SoC Info. kern :err : [ 1.927537] fsl-se secure-envlave-1: failed[-EPROBE_DEFER] to fetch SoC Info kern :err : [ 1.938511] fsl-se secure-envlave-1: Fail to read FIPS fuse kern :err : [ 1.944164] fsl-se secure-envlave-1: Failed to fetch SoC Info. kern :info : [ 1.947717] mmc1: SDHCI controller on 5b020000.mmc [5b020000.mmc] using ADMA kern :err : [ 1.950016] fsl-se secure-envlave-1: failed[-EPROBE_DEFER] to fetch SoC Info kern :warn : [ 1.964431] ------------[ cut here ]------------ kern :warn : [ 1.969110] kobject: '' ((____ptrval____)): is not initialized, yet kobject_put() is being called. kern :warn : [ 1.978159] WARNING: CPU: 0 PID: 11 at /lib/kobject.c:734 kobject_put+0xf0/0x218 kern :warn : [ 1.985591] Modules linked in: kern :warn : [ 1.988664] CPU: 0 PID: 11 Comm: kworker/u8:0 Not tainted 6.6.101-7.4.0-devel nxp-imx#1 kern :warn : [ 1.996086] Hardware name: Toradex Colibri iMX8QXP on Colibri Evaluation Board V3 (DT) kern :warn : [ 2.004020] Workqueue: events_unbound deferred_probe_work_func kern :warn : [ 2.009878] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) kern :warn : [ 2.016853] pc : kobject_put+0xf0/0x218 kern :warn : [ 2.020699] lr : kobject_put+0xf0/0x218 kern :warn : [ 2.024548] sp : ffffffc08008bac0 kern :warn : [ 2.027877] x29: ffffffc08008bac0 x28: 0000000000000000 x27: 0000000000000000 kern :warn : [ 2.035045] x26: ffffff8000410028 x25: ffffff80004297c0 x24: ffffff800040fa0d kern :warn : [ 2.042213] x23: 0000000000000008 x22: ffffffc08008bb38 x21: ffffff8000633c10 kern :warn : [ 2.049371] x20: ffffff8000633c10 x19: ffffff80022a2300 x18: 0000000000000006 kern :warn : [ 2.056538] x17: 5f7463656a626f6b x16: 20746579202c6465 x15: 0720072007200720 kern :warn : [ 2.063705] x14: 0720072007200720 x13: ffffffd8ee42ad10 x12: 00000000000002b5 kern :warn : [ 2.070873] x11: 00000000000000e7 x10: ffffffd8ee482d10 x9 : ffffffd8ee42ad10 kern :warn : [ 2.078040] x8 : 00000000ffffefff x7 : ffffffd8ee482d10 x6 : 80000000fffff000 kern :warn : [ 2.085207] x5 : 0000000000000000 x4 : 0000000000000000 x3 : 0000000000000000 kern :warn : [ 2.092374] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffffff80004a8e00 kern :warn : [ 2.099544] Call trace: kern :warn : [ 2.101997] kobject_put+0xf0/0x218 kern :warn : [ 2.105500] se_if_probe_cleanup+0xf8/0x134 kern :warn : [ 2.109703] devm_action_release+0x14/0x20 kern :warn : [ 2.113812] devres_release_all+0xa8/0x110 kern :warn : [ 2.117922] device_unbind_cleanup+0x18/0x68 kern :warn : [ 2.122214] really_probe+0x120/0x3c4 kern :warn : [ 2.125888] __driver_probe_device+0x7c/0x16c kern :warn : [ 2.130260] driver_probe_device+0x3c/0x110 kern :warn : [ 2.134463] __device_attach_driver+0xbc/0x158 kern :warn : [ 2.138928] bus_for_each_drv+0x88/0xe8 kern :warn : [ 2.142776] __device_attach+0xa0/0x1b4 kern :warn : [ 2.146625] device_initial_probe+0x14/0x20 kern :warn : [ 2.150821] bus_probe_device+0xa8/0xac kern :warn : [ 2.154669] deferred_probe_work_func+0x94/0xe4 kern :warn : [ 2.159214] process_one_work+0x144/0x29c kern :warn : [ 2.163245] worker_thread+0x31c/0x434 kern :warn : [ 2.167006] kthread+0x110/0x114 kern :warn : [ 2.170246] ret_from_fork+0x10/0x20 kern :warn : [ 2.173837] ---[ end trace 0000000000000000 ]--- Fixes: 4faa6ae ("LF-13910-8: drivers: firmware: imx: add support for i.MX8DXL/QXP/QM") Signed-off-by: Max Krummenacher <max.krummenacher@toradex.com>
Contributor
|
Thanks @MaxKrummenacher I have forwarded this internally! |
|
This fix is necessary, but I believe that the stack trace is caused by another issue that I explained and fixed here: #32. I included this commit there with an edited commit message. Thanks! |
Contributor
|
@ernestvh Please close this PR as we will follow the other PR. |
Overdr0ne
added a commit
to Overdr0ne/linux-imx
that referenced
this pull request
Sep 18, 2025
The driver should force this behavior, but specify explicitly to suppress warnings
Contributor
Author
|
Closed as the change is now discussed in #32 |
microhobby
pushed a commit
to gaiaBuildSystem/linux
that referenced
this pull request
Feb 24, 2026
IMX_SEC_ENCLAVE access the 'nvmem', thus on i.MX 8DXL/QXP/QM the following is required: NVMEM_IMX_OCOTP_SCU. Add it to the depends. With a missing NVMEM_IMX_OCOTP_SCU or with IMX_SEC_ENCLAVE=y and NVMEM_IMX_OCOTP_SCU=m, the probe can keep getting deferred. Upstream-Status: Submitted [nxp-imx/linux-imx#31] Fixes: 4faa6ae ("LF-13910-8: drivers: firmware: imx: add support for i.MX8DXL/QXP/QM") Signed-off-by: Max Krummenacher <max.krummenacher@toradex.com>
ossaleem
pushed a commit
to AirLinkOS/linux-imx
that referenced
this pull request
May 12, 2026
[ Upstream commit 8ffe28b ] commit 2a6c727 ("cpufreq: Initialize cpufreq-based frequency-invariance later") postponed the frequency invariance initialization to avoid disabling it in the error case. This isn't locking safe, instead move the initialization up before the subsys interface is registered (which will rebuild the sched_domains) and add the corresponding disable on the error path. Observed lockdep without this patch: [ 0.989686] ====================================================== [ 0.989688] WARNING: possible circular locking dependency detected [ 0.989690] 6.17.0-rc4-cix-build+ nxp-imx#31 Tainted: G S [ 0.989691] ------------------------------------------------------ [ 0.989692] swapper/0/1 is trying to acquire lock: [ 0.989693] ffff800082ada7f8 (sched_energy_mutex){+.+.}-{4:4}, at: rebuild_sched_domains_energy+0x30/0x58 [ 0.989705] but task is already holding lock: [ 0.989706] ffff000088c89bc8 (&policy->rwsem){+.+.}-{4:4}, at: cpufreq_online+0x7f8/0xbe0 [ 0.989713] which lock already depends on the new lock. Fixes: 2a6c727 ("cpufreq: Initialize cpufreq-based frequency-invariance later") Signed-off-by: Christian Loehle <christian.loehle@arm.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
ossaleem
pushed a commit
to AirLinkOS/linux-imx
that referenced
this pull request
May 12, 2026
commit b4d37cdb77a0015f51fee083598fa227cc07aaf1 upstream. When deassigning a KVM_IRQFD, don't clobber the irqfd's copy of the IRQ's routing entry as doing so breaks kvm_arch_irq_bypass_del_producer() on x86 and arm64, which explicitly look for KVM_IRQ_ROUTING_MSI. Instead, to handle a concurrent routing update, verify that the irqfd is still active before consuming the routing information. As evidenced by the x86 and arm64 bugs, and another bug in kvm_arch_update_irqfd_routing() (see below), clobbering the entry type without notifying arch code is surprising and error prone. As a bonus, checking that the irqfd is active provides a convenient location for documenting _why_ KVM must not consume the routing entry for an irqfd that is in the process of being deassigned: once the irqfd is deleted from the list (which happens *before* the eventfd is detached), it will no longer receive updates via kvm_irq_routing_update(), and so KVM could deliver an event using stale routing information (relative to KVM_SET_GSI_ROUTING returning to userspace). As an even better bonus, explicitly checking for the irqfd being active fixes a similar bug to the one the clobbering is trying to prevent: if an irqfd is deactivated, and then its routing is changed, kvm_irq_routing_update() won't invoke kvm_arch_update_irqfd_routing() (because the irqfd isn't in the list). And so if the irqfd is in bypass mode, IRQs will continue to be posted using the old routing information. As for kvm_arch_irq_bypass_del_producer(), clobbering the routing type results in KVM incorrectly keeping the IRQ in bypass mode, which is especially problematic on AMD as KVM tracks IRQs that are being posted to a vCPU in a list whose lifetime is tied to the irqfd. Without the help of KASAN to detect use-after-free, the most common sympton on AMD is a NULL pointer deref in amd_iommu_update_ga() due to the memory for irqfd structure being re-allocated and zeroed, resulting in irqfd->irq_bypass_data being NULL when read by avic_update_iommu_vcpu_affinity(): BUG: kernel NULL pointer dereference, address: 0000000000000018 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 40cf2b9067 P4D 40cf2b9067 PUD 408362a067 PMD 0 Oops: Oops: 0000 [#1] SMP CPU: 6 UID: 0 PID: 40383 Comm: vfio_irq_test Tainted: G U W O 6.19.0-smp--5dddc257e6b2-irqfd nxp-imx#31 NONE Tainted: [U]=USER, [W]=WARN, [O]=OOT_MODULE Hardware name: Google, Inc. Arcadia_IT_80/Arcadia_IT_80, BIOS 34.78.2-0 09/05/2025 RIP: 0010:amd_iommu_update_ga+0x19/0xe0 Call Trace: <TASK> avic_update_iommu_vcpu_affinity+0x3d/0x90 [kvm_amd] __avic_vcpu_load+0xf4/0x130 [kvm_amd] kvm_arch_vcpu_load+0x89/0x210 [kvm] vcpu_load+0x30/0x40 [kvm] kvm_arch_vcpu_ioctl_run+0x45/0x620 [kvm] kvm_vcpu_ioctl+0x571/0x6a0 [kvm] __se_sys_ioctl+0x6d/0xb0 do_syscall_64+0x6f/0x9d0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 RIP: 0033:0x46893b </TASK> ---[ end trace 0000000000000000 ]--- If AVIC is inhibited when the irfd is deassigned, the bug will manifest as list corruption, e.g. on the next irqfd assignment. list_add corruption. next->prev should be prev (ffff8d474d5cd588), but was 0000000000000000. (next=ffff8d8658f86530). ------------[ cut here ]------------ kernel BUG at lib/list_debug.c:31! Oops: invalid opcode: 0000 [#1] SMP CPU: 128 UID: 0 PID: 80818 Comm: vfio_irq_test Tainted: G U W O 6.19.0-smp--f19dc4d680ba-irqfd nxp-imx#28 NONE Tainted: [U]=USER, [W]=WARN, [O]=OOT_MODULE Hardware name: Google, Inc. Arcadia_IT_80/Arcadia_IT_80, BIOS 34.78.2-0 09/05/2025 RIP: 0010:__list_add_valid_or_report+0x97/0xc0 Call Trace: <TASK> avic_pi_update_irte+0x28e/0x2b0 [kvm_amd] kvm_pi_update_irte+0xbf/0x190 [kvm] kvm_arch_irq_bypass_add_producer+0x72/0x90 [kvm] irq_bypass_register_consumer+0xcd/0x170 [irqbypass] kvm_irqfd+0x4c6/0x540 [kvm] kvm_vm_ioctl+0x118/0x5d0 [kvm] __se_sys_ioctl+0x6d/0xb0 do_syscall_64+0x6f/0x9d0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 </TASK> ---[ end trace 0000000000000000 ]--- On Intel and arm64, the bug is less noisy, as the end result is that the device keeps posting IRQs to the vCPU even after it's been deassigned. Note, the worst of the breakage can be traced back to commit cb21073 ("KVM: Pass new routing entries and irqfd when updating IRTEs"), as before that commit KVM would pull the routing information from the per-VM routing table. But as above, similar bugs have existed since support for IRQ bypass was added. E.g. if a routing change finished before irq_shutdown() invoked kvm_arch_irq_bypass_del_producer(), VMX and SVM would see stale routing information and potentially leave the irqfd in bypass mode. Alternatively, x86 could be fixed by explicitly checking irq_bypass_vcpu instead of irq_entry.type in kvm_arch_irq_bypass_del_producer(), and arm64 could be modified to utilize irq_bypass_vcpu in a similar manner. But (a) that wouldn't fix the routing updates bug, and (b) fixing core code doesn't preclude x86 (or arm64) from adding such code as a sanity check (spoiler alert). Fixes: f70c20a ("KVM: Add an arch specific hooks in 'struct kvm_kernel_irqfd'") Fixes: cb21073 ("KVM: Pass new routing entries and irqfd when updating IRTEs") Fixes: a0d7e2f ("KVM: arm64: vgic-v4: Only attempt vLPI mapping for actual MSIs") Cc: stable@vger.kernel.org Cc: Marc Zyngier <maz@kernel.org> Cc: Oliver Upton <oupton@kernel.org> Link: https://patch.msgid.link/20260113174606.104978-2-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
IMX_SEC_ENCLAVE access the 'nvmem', thus on i.MX 8DXL/QXP/QM the following is required: NVMEM_IMX_OCOTP_SCU.
Add it to the depends.
With a missing NVMEM_IMX_OCOTP_SCU or with IMX_SEC_ENCLAVE=y and NVMEM_IMX_OCOTP_SCU=m we get repeated kernel messages as follows:
kern :err : [ 1.911106] fsl-se secure-envlave-1: Fail to read FIPS fuse
kern :err : [ 1.921674] fsl-se secure-envlave-1: Failed to fetch SoC Info.
kern :err : [ 1.927537] fsl-se secure-envlave-1: failed[-EPROBE_DEFER] to fetch SoC Info
kern :err : [ 1.938511] fsl-se secure-envlave-1: Fail to read FIPS fuse
kern :err : [ 1.944164] fsl-se secure-envlave-1: Failed to fetch SoC Info.
kern :info : [ 1.947717] mmc1: SDHCI controller on 5b020000.mmc [5b020000.mmc] using ADMA
kern :err : [ 1.950016] fsl-se secure-envlave-1: failed[-EPROBE_DEFER] to fetch SoC Info
kern :warn : [ 1.964431] ------------[ cut here ]------------
kern :warn : [ 1.969110] kobject: '' ((ptrval)): is not initialized, yet kobject_put() is being called.
kern :warn : [ 1.978159] WARNING: CPU: 0 PID: 11 at /lib/kobject.c:734 kobject_put+0xf0/0x218
kern :warn : [ 1.985591] Modules linked in:
kern :warn : [ 1.988664] CPU: 0 PID: 11 Comm: kworker/u8:0 Not tainted 6.6.101-7.4.0-devel #1
kern :warn : [ 1.996086] Hardware name: Toradex Colibri iMX8QXP on Colibri Evaluation Board V3 (DT)
kern :warn : [ 2.004020] Workqueue: events_unbound deferred_probe_work_func
kern :warn : [ 2.009878] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
kern :warn : [ 2.016853] pc : kobject_put+0xf0/0x218
kern :warn : [ 2.020699] lr : kobject_put+0xf0/0x218
kern :warn : [ 2.024548] sp : ffffffc08008bac0
kern :warn : [ 2.027877] x29: ffffffc08008bac0 x28: 0000000000000000 x27: 0000000000000000
kern :warn : [ 2.035045] x26: ffffff8000410028 x25: ffffff80004297c0 x24: ffffff800040fa0d
kern :warn : [ 2.042213] x23: 0000000000000008 x22: ffffffc08008bb38 x21: ffffff8000633c10
kern :warn : [ 2.049371] x20: ffffff8000633c10 x19: ffffff80022a2300 x18: 0000000000000006
kern :warn : [ 2.056538] x17: 5f7463656a626f6b x16: 20746579202c6465 x15: 0720072007200720
kern :warn : [ 2.063705] x14: 0720072007200720 x13: ffffffd8ee42ad10 x12: 00000000000002b5
kern :warn : [ 2.070873] x11: 00000000000000e7 x10: ffffffd8ee482d10 x9 : ffffffd8ee42ad10
kern :warn : [ 2.078040] x8 : 00000000ffffefff x7 : ffffffd8ee482d10 x6 : 80000000fffff000
kern :warn : [ 2.085207] x5 : 0000000000000000 x4 : 0000000000000000 x3 : 0000000000000000
kern :warn : [ 2.092374] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffffff80004a8e00
kern :warn : [ 2.099544] Call trace:
kern :warn : [ 2.101997] kobject_put+0xf0/0x218
kern :warn : [ 2.105500] se_if_probe_cleanup+0xf8/0x134
kern :warn : [ 2.109703] devm_action_release+0x14/0x20
kern :warn : [ 2.113812] devres_release_all+0xa8/0x110
kern :warn : [ 2.117922] device_unbind_cleanup+0x18/0x68
kern :warn : [ 2.122214] really_probe+0x120/0x3c4
kern :warn : [ 2.125888] __driver_probe_device+0x7c/0x16c
kern :warn : [ 2.130260] driver_probe_device+0x3c/0x110
kern :warn : [ 2.134463] __device_attach_driver+0xbc/0x158
kern :warn : [ 2.138928] bus_for_each_drv+0x88/0xe8
kern :warn : [ 2.142776] __device_attach+0xa0/0x1b4
kern :warn : [ 2.146625] device_initial_probe+0x14/0x20
kern :warn : [ 2.150821] bus_probe_device+0xa8/0xac
kern :warn : [ 2.154669] deferred_probe_work_func+0x94/0xe4
kern :warn : [ 2.159214] process_one_work+0x144/0x29c
kern :warn : [ 2.163245] worker_thread+0x31c/0x434
kern :warn : [ 2.167006] kthread+0x110/0x114
kern :warn : [ 2.170246] ret_from_fork+0x10/0x20
kern :warn : [ 2.173837] ---[ end trace 0000000000000000 ]---
Fixes: 4faa6ae ("LF-13910-8: drivers: firmware: imx: add support for i.MX8DXL/QXP/QM")