Documentation/devicetree/bindings/mux/mux-controller.yaml
Source file repositories/reference/linux-study-clean/Documentation/devicetree/bindings/mux/mux-controller.yaml
File Facts
- System
- Linux kernel
- Corpus path
Documentation/devicetree/bindings/mux/mux-controller.yaml- Extension
.yaml- Size
- 5931 bytes
- Lines
- 200
- 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/mux/mux.hdt-bindings/gpio/gpio.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
%YAML 1.2
---
$id: http://devicetree.org/schemas/mux/mux-controller.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Common multiplexer controller provider
maintainers:
- Peter Rosin <peda@axentia.se>
description: |
A multiplexer (or mux) controller will have one, or several, consumer devices
that uses the mux controller. Thus, a mux controller can possibly control
several parallel multiplexers. Presumably there will be at least one
multiplexer needed by each consumer, but a single mux controller can of course
control several multiplexers for a single consumer.
A mux controller provides a number of states to its consumers, and the state
space is a simple zero-based enumeration. I.e. 0-1 for a 2-way multiplexer,
0-7 for an 8-way multiplexer, etc.
Mux controller nodes
--------------------
Mux controller nodes must specify the number of cells used for the
specifier using the '#mux-control-cells' or '#mux-state-cells' property.
The value of '#mux-state-cells' will always be one greater than the value
of '#mux-control-cells'.
Optionally, mux controller nodes can also specify the state the mux should
have when it is idle. The idle-state property is used for this. If the
idle-state is not present, the mux controller is typically left as is when
it is idle. For multiplexer chips that expose several mux controllers, the
idle-state property is an array with one idle state for each mux controller.
The special value (-1) may be used to indicate that the mux should be left
as is when it is idle. This is the default, but can still be useful for
mux controller chips with more than one mux controller, particularly when
there is a need to "step past" a mux controller and set some other idle
state for a mux controller with a higher index.
Some mux controllers have the ability to disconnect the input/output of the
multiplexer. Using this disconnected high-impedance state as the idle state
is indicated with idle state (-2).
These constants are available in
#include <dt-bindings/mux/mux.h>
as MUX_IDLE_AS_IS (-1) and MUX_IDLE_DISCONNECT (-2).
An example mux controller node look like this (the adg972a chip is a triple
4-way multiplexer):
mux: mux-controller@50 {
compatible = "adi,adg792a";
reg = <0x50>;
#mux-control-cells = <1>;
idle-state = <MUX_IDLE_DISCONNECT MUX_IDLE_AS_IS 2>;
};
select:
anyOf:
- required:
- '#mux-control-cells'
- required:
- '#mux-state-cells'
Annotation
- Immediate include surface: `dt-bindings/mux/mux.h`, `dt-bindings/gpio/gpio.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.