drivers/net/phy/phy_device.c
Source file repositories/reference/linux-study-clean/drivers/net/phy/phy_device.c
File Facts
- System
- Linux kernel
- Corpus path
drivers/net/phy/phy_device.c- Extension
.c- Size
- 107985 bytes
- Lines
- 4014
- Domain
- Driver Families
- Bucket
- drivers/net
- Inferred role
- Driver Families: operation-table or driver-model contract
- Status
- pattern implementation candidate
Why This File Exists
Repeatable hardware-adapter layer. Deep compatibility for every driver is out of scope; this atlas records patterns, probe lifecycles, bus glue, IRQ/DMA usage, and links back to core abstractions.
- Repeatable hardware-adapter layer. Deep compatibility for every driver is out of scope; this atlas records patterns, probe lifecycles, bus glue, IRQ/DMA usage, and links back to core abstractions.
- Defines an operation table; this is where Linux turns generic core objects into subsystem-specific behavior.
- Uses kernel synchronization; read lock ordering, sleepability, and interrupt context assumptions before translating.
- Touches IRQ or DMA behavior; this matters for the representative real-device path.
- Allocates kernel memory; connect allocation flags and lifetime to context constraints.
- Defines or uses C structs; map object ownership, embedded links, reference counts, and lock ownership.
Dependency Surface
linux/acpi.hlinux/bitmap.hlinux/delay.hlinux/errno.hlinux/etherdevice.hlinux/ethtool.hlinux/init.hlinux/interrupt.hlinux/io.hlinux/kernel.hlinux/list.hlinux/mdio.hlinux/mii.hlinux/mm.hlinux/module.hlinux/of.hlinux/netdevice.hlinux/phy.hlinux/phylib_stubs.hlinux/phy_led_triggers.hlinux/phy_link_topology.hlinux/phy_port.hlinux/pse-pd/pse.hlinux/property.hlinux/ptp_clock_kernel.hlinux/rtnetlink.hlinux/sfp.hlinux/skbuff.hlinux/slab.hlinux/string.hlinux/uaccess.hlinux/unistd.h
Detected Declarations
struct phy_fixupfunction features_initfunction phy_device_freefunction phy_mdio_device_freefunction phy_device_releasefunction phy_mdio_device_removefunction phy_drv_wol_enabledfunction phy_may_wakeupfunction phy_link_changefunction phy_startfunction mdio_bus_phy_may_suspendfunction mdio_bus_phy_suspendfunction mdio_bus_phy_resumefunction comparisonfunction phy_register_fixup_for_uidfunction phy_register_fixup_for_idfunction phy_needs_fixupfunction phy_scan_fixupsfunction genphy_match_phy_devicefunction phy_bus_matchfunction phy_id_showfunction phy_interface_showfunction phy_has_fixups_showfunction phy_dev_flags_showfunction phy_mmd_is_visiblefunction phy_request_driver_modulefunction phy_c45_probe_presentfunction get_phy_c45_devs_in_pkgfunction get_phy_c45_idsfunction get_phy_c22_idfunction fwnode_get_phy_idfunction get_phy_c22_idfunction phy_device_registerfunction phy_device_registerfunction phy_get_c45_idsfunction statusfunction phy_connect_directfunction voidfunction phy_disconnectfunction PHYsfunction phy_init_hwfunction phy_attached_infofunction phy_attached_printfunction phy_sysfs_create_linksfunction phy_standalone_showfunction phy_sfp_connect_phyfunction phy_sfp_disconnect_phyfunction phy_sfp_attach
Annotated Snippet
struct device_driver *drv = phydev->mdio.dev.driver;
struct phy_driver *phydrv = to_phy_driver(drv);
struct net_device *netdev = phydev->attached_dev;
if (!drv || !phydrv->suspend)
return false;
/* If the PHY on the mido bus is not attached but has WOL enabled
* we cannot suspend the PHY.
*/
if (!netdev && phy_may_wakeup(phydev))
return false;
/* PHY not attached? May suspend if the PHY has not already been
* suspended as part of a prior call to phy_disconnect() ->
* phy_detach() -> phy_suspend() because the parent netdev might be the
* MDIO bus driver and clock gated at this point.
*/
if (!netdev)
goto out;
if (netdev->ethtool->wol_enabled)
return false;
/* As long as not all affected network drivers support the
* wol_enabled flag, let's check for hints that WoL is enabled.
* Don't suspend PHY if the attached netdev parent may wake up.
* The parent may point to a PCI device, as in tg3 driver.
*/
if (netdev->dev.parent && device_may_wakeup(netdev->dev.parent))
return false;
/* Also don't suspend PHY if the netdev itself may wakeup. This
* is the case for devices w/o underlaying pwr. mgmt. aware bus,
* e.g. SoC devices.
*/
if (device_may_wakeup(&netdev->dev))
return false;
out:
return !phydev->suspended;
}
static __maybe_unused int mdio_bus_phy_suspend(struct device *dev)
{
struct phy_device *phydev = to_phy_device(dev);
if (phydev->mac_managed_pm)
return 0;
/* Wakeup interrupts may occur during the system sleep transition when
* the PHY is inaccessible. Set flag to postpone handling until the PHY
* has resumed. Wait for concurrent interrupt handler to complete.
*/
if (phy_interrupt_is_valid(phydev)) {
phydev->irq_suspended = 1;
synchronize_irq(phydev->irq);
}
/* We must stop the state machine manually, otherwise it stops out of
* control, possibly with the phydev->lock held. Upon resume, netdev
* may call phy routines that try to grab the same lock, and that may
* lead to a deadlock.
*/
if (phy_uses_state_machine(phydev))
phy_stop_machine(phydev);
if (!mdio_bus_phy_may_suspend(phydev))
return 0;
phydev->suspended_by_mdio_bus = 1;
return phy_suspend(phydev);
}
static __maybe_unused int mdio_bus_phy_resume(struct device *dev)
{
struct phy_device *phydev = to_phy_device(dev);
int ret;
if (phydev->mac_managed_pm)
return 0;
if (!phydev->suspended_by_mdio_bus)
goto no_resume;
phydev->suspended_by_mdio_bus = 0;
/* If we managed to get here with the PHY state machine in a state
* neither PHY_HALTED, PHY_READY nor PHY_UP, this is an indication
Annotation
- Immediate include surface: `linux/acpi.h`, `linux/bitmap.h`, `linux/delay.h`, `linux/errno.h`, `linux/etherdevice.h`, `linux/ethtool.h`, `linux/init.h`, `linux/interrupt.h`.
- Detected declarations: `struct phy_fixup`, `function features_init`, `function phy_device_free`, `function phy_mdio_device_free`, `function phy_device_release`, `function phy_mdio_device_remove`, `function phy_drv_wol_enabled`, `function phy_may_wakeup`, `function phy_link_change`, `function phy_start`.
- Atlas domain: Driver Families / drivers/net.
- Implementation status: pattern implementation candidate.
- Synchronization appears in or near this file; preserve lock ordering, sleepability, and interrupt-context constraints.
- IRQ or DMA behavior appears here, which is relevant to the selected PCIe/NVMe device path.
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.