Documentation/devicetree/bindings/regmap/regmap.txt
Source file repositories/reference/linux-study-clean/Documentation/devicetree/bindings/regmap/regmap.txt
File Facts
- System
- Linux kernel
- Corpus path
Documentation/devicetree/bindings/regmap/regmap.txt- Extension
.txt- Size
- 907 bytes
- Lines
- 30
- Domain
- Support Tooling And Documentation
- Bucket
- Documentation
- Inferred role
- Support Tooling And Documentation: documentation
- Status
- atlas-only
Why This File Exists
Repository support layer: documentation, build tooling, samples, user-space helper tools, generated initramfs support, licenses, and validation utilities.
- Repository support layer: documentation, build tooling, samples, user-space helper tools, generated initramfs support, licenses, and validation utilities.
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
Devicetree binding for regmap
Optional properties:
little-endian,
big-endian,
native-endian: See common-properties.txt for a definition
Note:
Regmap defaults to little-endian register access on MMIO based
devices, this is by far the most common setting. On CPU
architectures that typically run big-endian operating systems
(e.g. PowerPC), registers can be defined as big-endian and must
be marked that way in the devicetree.
On SoCs that can be operated in both big-endian and little-endian
modes, with a single hardware switch controlling both the endianness
of the CPU and a byteswap for MMIO registers (e.g. many Broadcom MIPS
chips), "native-endian" is used to allow using the same device tree
blob in both cases.
Examples:
Scenario 1 : a register set in big-endian mode.
dev: dev@40031000 {
compatible = "syscon";
reg = <0x40031000 0x1000>;
big-endian;
...
};
Annotation
- Atlas domain: Support Tooling And Documentation / Documentation.
- 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.