drivers/mtd/lpddr/Kconfig
Source file repositories/reference/linux-study-clean/drivers/mtd/lpddr/Kconfig
File Facts
- System
- Linux kernel
- Corpus path
drivers/mtd/lpddr/Kconfig- Extension
[no extension]- Size
- 966 bytes
- Lines
- 31
- Domain
- Driver Families
- Bucket
- drivers/mtd
- 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
menu "LPDDR & LPDDR2 PCM memory drivers"
depends on MTD
config MTD_LPDDR
tristate "Support for LPDDR flash chips"
select MTD_QINFO_PROBE
help
This option enables support of LPDDR (Low power double data rate)
flash chips. Synonymous with Mobile-DDR. It is a new standard for
DDR memories, intended for battery-operated systems.
config MTD_QINFO_PROBE
depends on MTD_LPDDR
tristate "Detect flash chips by QINFO probe"
help
Device Information for LPDDR chips is offered through the Overlay
Window QINFO interface, permits software to be used for entire
families of devices. This serves similar purpose of CFI on legacy
Flash products
config MTD_LPDDR2_NVM
# ARM dependency is only for writel_relaxed()
depends on MTD && ARM
tristate "Support for LPDDR2-NVM flash chips"
help
This option enables support of PCM memories with a LPDDR2-NVM
(Low power double data rate 2) interface.
endmenu
Annotation
- Atlas domain: Driver Families / drivers/mtd.
- 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.