Documentation/devicetree/bindings/i3c/i3c.yaml
Source file repositories/reference/linux-study-clean/Documentation/devicetree/bindings/i3c/i3c.yaml
File Facts
- System
- Linux kernel
- Corpus path
Documentation/devicetree/bindings/i3c/i3c.yaml- Extension
.yaml- Size
- 6579 bytes
- Lines
- 197
- Domain
- Support Tooling And Documentation
- Bucket
- Documentation
- Inferred role
- Support Tooling And Documentation: configuration, schema, or hardware description
- 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
dt-bindings/i3c/i3c.h
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 OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/i3c/i3c.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: I3C bus
maintainers:
- Alexandre Belloni <alexandre.belloni@bootlin.com>
- Miquel Raynal <miquel.raynal@bootlin.com>
description: |
I3C busses can be described with a node for the primary I3C controller device
and a set of child nodes for each I2C or I3C slave on the bus. Each of them
may, during the life of the bus, request mastership.
properties:
$nodename:
pattern: "^i3c@[0-9a-f]+$"
"#address-cells":
const: 3
description: |
Each I2C device connected to the bus should be described in a subnode.
All I3C devices are supposed to support DAA (Dynamic Address Assignment),
and are thus discoverable. So, by default, I3C devices do not have to be
described in the device tree. This being said, one might want to attach
extra resources to these devices, and those resources may have to be
described in the device tree, which in turn means we have to describe
I3C devices.
Another use case for describing an I3C device in the device tree is when
this I3C device has a static I2C address and we want to assign it a
specific I3C dynamic address before the DAA takes place (so that other
devices on the bus can't take this dynamic address).
"#size-cells":
const: 0
i3c-scl-hz:
description: |
Frequency of the SCL signal used for I3C transfers. When undefined, the
default value should be 12.5MHz.
May not be supported by all controllers.
i2c-scl-hz:
description: |
Frequency of the SCL signal used for I2C transfers. When undefined, the
default should be to look at LVR (Legacy Virtual Register) values of
I2C devices described in the device tree to determine the maximum I2C
frequency.
May not be supported by all controllers.
mctp-controller:
type: boolean
description: |
Indicates that the system is accessible via this bus as an endpoint for
MCTP over I3C transport.
required:
- "#address-cells"
- "#size-cells"
patternProperties:
"@[0-9a-f]+$":
type: object
Annotation
- Immediate include surface: `dt-bindings/i3c/i3c.h`.
- 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.