Documentation/devicetree/bindings/usb/usb-device.yaml
Source file repositories/reference/linux-study-clean/Documentation/devicetree/bindings/usb/usb-device.yaml
File Facts
- System
- Linux kernel
- Corpus path
Documentation/devicetree/bindings/usb/usb-device.yaml- Extension
.yaml- Size
- 3958 bytes
- Lines
- 127
- 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/usb/usb-device.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Generic USB Device
maintainers:
- Greg Kroah-Hartman <gregkh@linuxfoundation.org>
description: |
Usually, we only use device tree for hard wired USB device.
The reference binding doc is from:
http://www.devicetree.org/open-firmware/bindings/usb/usb-1_0.ps
Four types of device-tree nodes are defined: "host-controller nodes"
representing USB host controllers, "device nodes" representing USB devices,
"interface nodes" representing USB interfaces and "combined nodes"
representing simple USB devices.
A combined node shall be used instead of a device node and an interface node
for devices of class 0 or 9 (hub) with a single configuration and a single
interface.
A "hub node" is a combined node or an interface node that represents a USB
hub.
properties:
compatible:
contains:
pattern: "^usb[0-9a-f]{1,4},[0-9a-f]{1,4}$"
description: Device nodes or combined nodes.
"usbVID,PID", where VID is the vendor id and PID the product id.
The textual representation of VID and PID shall be in lower case
hexadecimal with leading zeroes suppressed. The other compatible
strings from the above standard binding could also be used,
but a device adhering to this binding may leave out all except
for "usbVID,PID".
reg:
description: the number of the USB hub port or the USB host-controller
port to which this device is attached.
items:
- minimum: 1
maximum: 255
"#address-cells":
description: should be 1 for hub nodes with device nodes,
should be 2 for device nodes with interface nodes.
enum: [1, 2]
"#size-cells":
const: 0
patternProperties:
"^interface@[0-9a-f]{1,2}(,[0-9a-f]{1,2})$":
type: object
description: USB interface nodes.
The configuration component is not included in the textual
representation of an interface-node unit address for configuration 1.
properties:
compatible:
pattern: "^usbif[0-9a-f]{1,4},[0-9a-f]{1,4}.config[0-9a-f]{1,2}.[0-9a-f]{1,2}$"
description: Interface nodes.
"usbifVID,PID.configCN.IN", where VID is the vendor id, PID is
the product id, CN is the configuration value and IN is the interface
number. The textual representation of VID, PID, CN and IN shall be
in lower case hexadecimal with leading zeroes suppressed.
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.