Documentation/firmware-guide/acpi/dsd/phy.rst
Source file repositories/reference/linux-study-clean/Documentation/firmware-guide/acpi/dsd/phy.rst
File Facts
- System
- Linux kernel
- Corpus path
Documentation/firmware-guide/acpi/dsd/phy.rst- Extension
.rst- Size
- 5388 bytes
- Lines
- 202
- Domain
- Support Tooling And Documentation
- Bucket
- Documentation
- Inferred role
- Support Tooling And Documentation: documentation
- 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
function Scope
Annotated Snippet
Device(PHY1) {
Name (_ADR, 0x1)
} // end of PHY1
Device(PHY2) {
Name (_ADR, 0x2)
} // end of PHY2
}
Later, during the MAC driver initialization, the registered PHY devices
have to be retrieved from the MDIO bus. For this, the MAC driver needs
references to the previously registered PHYs which are provided
as device object references (e.g. \_SB.MDI0.PHY1).
phy-mode
--------
The "phy-mode" _DSD property is used to describe the connection to
the PHY. The valid values for "phy-mode" are defined in [ethernet-controller].
managed
-------
Optional property, which specifies the PHY management type.
The valid values for "managed" are defined in [ethernet-controller].
fixed-link
----------
The "fixed-link" is described by a data-only subnode of the
MAC port, which is linked in the _DSD package via
hierarchical data extension (UUID dbb8e3e6-5886-4ba6-8795-1319f52a966b
in accordance with [dsd-guide] "_DSD Implementation Guide" document).
The subnode should comprise a required property ("speed") and
possibly the optional ones - complete list of parameters and
their values are specified in [ethernet-controller].
The following ASL example illustrates the usage of these properties.
DSDT entry for MDIO node
------------------------
The MDIO bus has an SoC component (MDIO controller) and a platform
component (PHYs on the MDIO bus).
a) Silicon Component
This node describes the MDIO controller, MDI0
---------------------------------------------
.. code-block:: none
Scope(_SB)
{
Device(MDI0) {
Name(_HID, "NXP0006")
Name(_CCA, 1)
Name(_UID, 0)
Name(_CRS, ResourceTemplate() {
Memory32Fixed(ReadWrite, MDI0_BASE, MDI_LEN)
Interrupt(ResourceConsumer, Level, ActiveHigh, Shared)
{
MDI0_IT
}
}) // end of _CRS for MDI0
} // end of MDI0
}
b) Platform Component
The PHY1 and PHY2 nodes represent the PHYs connected to MDIO bus MDI0
---------------------------------------------------------------------
.. code-block:: none
Annotation
- Detected declarations: `function Scope`.
- 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.