drivers/tee/optee/Kconfig
Source file repositories/reference/linux-study-clean/drivers/tee/optee/Kconfig
File Facts
- System
- Linux kernel
- Corpus path
drivers/tee/optee/Kconfig- Extension
[no extension]- Size
- 1144 bytes
- Lines
- 33
- Domain
- Driver Families
- Bucket
- drivers/tee
- Inferred role
- Driver Families: build/configuration rule
- Status
- atlas-only
Why This File Exists
Repeatable hardware-adapter layer. Deep compatibility for every driver is out of scope; this atlas records patterns, probe lifecycles, bus glue, IRQ/DMA usage, and links back to core abstractions.
- Repeatable hardware-adapter layer. Deep compatibility for every driver is out of scope; this atlas records patterns, probe lifecycles, bus glue, IRQ/DMA usage, and links back to core abstractions.
Dependency Surface
- No C-style include directives detected by the generator.
Detected Declarations
- No top-level syscall, struct, function, initcall, or export declaration detected by the generator.
Annotated Snippet
# SPDX-License-Identifier: GPL-2.0-only
# OP-TEE Trusted Execution Environment Configuration
config OPTEE
tristate "OP-TEE"
depends on HAVE_ARM_SMCCC
depends on MMU
depends on RPMB || !RPMB
help
This implements the OP-TEE Trusted Execution Environment (TEE)
driver.
config OPTEE_INSECURE_LOAD_IMAGE
bool "Load OP-TEE image as firmware"
default n
depends on OPTEE && ARM64
help
This loads the BL32 image for OP-TEE as firmware when the driver is
probed. This returns -EPROBE_DEFER until the firmware is loadable from
the filesystem which is determined by checking the system_state until
it is in SYSTEM_RUNNING. This also requires enabling the corresponding
option in Trusted Firmware for Arm. The documentation there explains
the security threat associated with enabling this as well as
mitigations at the firmware and platform level.
https://trustedfirmware-a.readthedocs.io/en/latest/threat_model/threat_model.html
Additional documentation on kernel security risks are at
Documentation/tee/op-tee.rst.
config OPTEE_STATIC_PROTMEM_POOL
bool
depends on HAS_IOMEM && TEE_DMABUF_HEAPS
default y
Annotation
- Atlas domain: Driver Families / drivers/tee.
- Implementation status: atlas-only.
Implementation Notes
- This generated page is the file-by-file coverage layer; curated subsystem chapters should link here when they synthesize a multi-file control flow.
- Core OS pages should be promoted from atlas-only to deep-reviewed when they explain data structures, invariants, locking, lifecycle, and C implementation snippets.
- Driver-family pages are intentionally pattern-oriented unless they are part of the selected PCIe/NVMe representative device path.