Documentation/devicetree/bindings/access-controllers/access-controllers.yaml
Source file repositories/reference/linux-study-clean/Documentation/devicetree/bindings/access-controllers/access-controllers.yaml
File Facts
- System
- Linux kernel
- Corpus path
Documentation/devicetree/bindings/access-controllers/access-controllers.yaml- Extension
.yaml- Size
- 3100 bytes
- Lines
- 85
- 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
- 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 OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/access-controllers/access-controllers.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Generic Domain Access Controllers
maintainers:
- Oleksii Moisieiev <oleksii_moisieiev@epam.com>
description: |+
Common access controllers properties
Access controllers are in charge of stating which of the hardware blocks under
their responsibility (their domain) can be accesssed by which compartment. A
compartment can be a cluster of CPUs (or coprocessors), a range of addresses
or a group of hardware blocks. An access controller's domain is the set of
resources covered by the access controller.
This device tree binding can be used to bind devices to their access
controller provided by access-controllers property. In this case, the device
is a consumer and the access controller is the provider.
An access controller can be represented by any node in the device tree and
can provide one or more configuration parameters, needed to control parameters
of the consumer device. A consumer node can refer to the provider by phandle
and a set of phandle arguments, specified by '#access-controller-cells'
property in the access controller node.
Access controllers are typically used to set/read the permissions of a
hardware block and grant access to it. Any of which depends on the access
controller. The capabilities of each access controller are defined by the
binding of the access controller device.
Each node can be a consumer for the several access controllers.
# always select the core schema
select: true
properties:
"#access-controller-cells":
description:
Number of cells in an access-controllers specifier;
Can be any value as specified by device tree binding documentation
of a particular provider. The node is an access controller.
access-controller-names:
$ref: /schemas/types.yaml#/definitions/string-array
description:
A list of access-controllers names, sorted in the same order as
access-controllers entries. Consumer drivers will use
access-controller-names to match with existing access-controllers entries.
access-controllers:
$ref: /schemas/types.yaml#/definitions/phandle-array
description:
A list of access controller specifiers, as defined by the
bindings of the access-controllers provider.
additionalProperties: true
examples:
- |
clock_controller: access-controllers@50000 {
reg = <0x50000 0x400>;
#access-controller-cells = <2>;
};
bus_controller: bus@60000 {
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.