Documentation/devicetree/bindings/phy/ti,keystone-usbphy.yaml
Source file repositories/reference/linux-study-clean/Documentation/devicetree/bindings/phy/ti,keystone-usbphy.yaml
File Facts
- System
- Linux kernel
- Corpus path
Documentation/devicetree/bindings/phy/ti,keystone-usbphy.yaml- Extension
.yaml- Size
- 867 bytes
- Lines
- 38
- 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/phy/ti,keystone-usbphy.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: TI Keystone USB PHY
maintainers:
- Nishanth Menon <nm@ti.com>
- Santosh Shilimkar <ssantosh@kernel.org>
description:
The main purpose of this PHY driver is to enable the USB PHY reference clock
gate on the Keystone SOC for both the USB2 and USB3 PHY. Otherwise it is just
an NOP PHY driver. Hence this node is referenced as both the usb2 and usb3
phy node in the USB Glue layer driver node.
properties:
compatible:
const: ti,keystone-usbphy
reg:
maxItems: 1
required:
- compatible
- reg
additionalProperties: false
examples:
- |
usb-phy@2620738 {
compatible = "ti,keystone-usbphy";
reg = <0x2620738 32>;
};
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.