drivers/iommu/arm/Kconfig
Source file repositories/reference/linux-study-clean/drivers/iommu/arm/Kconfig
File Facts
- System
- Linux kernel
- Corpus path
drivers/iommu/arm/Kconfig- Extension
[no extension]- Size
- 4814 bytes
- Lines
- 144
- Domain
- Driver Families
- Bucket
- drivers/iommu
- 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.
- Touches IRQ or DMA behavior; this matters for the representative real-device path.
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
# ARM IOMMU support
config ARM_SMMU
tristate "ARM Ltd. System MMU (SMMU) Support"
depends on ARM64 || ARM || COMPILE_TEST
depends on !GENERIC_ATOMIC64 # for IOMMU_IO_PGTABLE_LPAE
select IOMMU_API
select IOMMU_IO_PGTABLE_LPAE
select ARM_DMA_USE_IOMMU if ARM
help
Support for implementations of the ARM System MMU architecture
versions 1 and 2.
Say Y here if your SoC includes an IOMMU device implementing
the ARM SMMU architecture.
if ARM_SMMU
config ARM_SMMU_LEGACY_DT_BINDINGS
bool "Support the legacy \"mmu-masters\" devicetree bindings"
depends on ARM_SMMU=y && OF
help
Support for the badly designed and deprecated "mmu-masters"
devicetree bindings. This allows some DMA masters to attach
to the SMMU but does not provide any support via the DMA API.
If you're lucky, you might be able to get VFIO up and running.
If you say Y here then you'll make me very sad. Instead, say N
and move your firmware to the utopian future that was 2016.
config ARM_SMMU_DISABLE_BYPASS_BY_DEFAULT
bool "Disable unmatched stream bypass by default" if EXPERT
default y
help
If your firmware is broken and fails to describe StreamIDs which
Linux should know about in order to manage the SMMU correctly and
securely, and you don't want to boot with the 'arm-smmu.disable_bypass=0'
command line parameter, then as a last resort you can turn it off
by default here. But don't. This option may be removed at any time.
Note that 'arm-smmu.disable_bypass=1' will still take precedence.
config ARM_SMMU_MMU_500_CPRE_ERRATA
bool "Enable errata workaround for CPRE in SMMU reset path"
default y
help
Say Y here (by default) to apply workaround to disable
MMU-500's next-page prefetcher for sake of 4 known errata.
Say N here only when it is sure that any errata related to
prefetch enablement are not applicable on the platform.
Refer silicon-errata.rst for info on errata IDs.
config ARM_SMMU_QCOM
def_tristate y
depends on ARCH_QCOM
select QCOM_SCM
help
When running on a Qualcomm platform that has the custom variant
of the ARM SMMU, this needs to be built into the SMMU driver.
config ARM_SMMU_QCOM_DEBUG
bool "ARM SMMU QCOM implementation defined debug support"
depends on ARM_SMMU_QCOM=y
help
Support for implementation specific debug features in ARM SMMU
hardware found in QTI platforms. This include support for
the Translation Buffer Units (TBU) that can be used to obtain
additional information when debugging memory management issues
like context faults.
Annotation
- Atlas domain: Driver Families / drivers/iommu.
- Implementation status: atlas-only.
- IRQ or DMA behavior appears here, which is relevant to the selected PCIe/NVMe device path.
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.