1. Identify what is meant to wake

Wake-on-LAN should be described as a chain of functions rather than a general Ethernet capability. TI explains that the DP83822 detects particular frames and notifies a connected controller, allowing devices above the physical layer to remain in a low-power state until qualifying traffic arrives. The distinction identifies which part of the wake operation belongs to the PHY description.

State what the application expects to leave the low-power state and what indication it expects from the PHY. A requirement about notification to a controller is narrower than a claim that the complete host resumes successfully. Keeping that boundary explicit makes it possible to compare the PHY feature without silently assigning the remaining host behaviour to the component.

Ethernet speed and the MAC-facing interface remain separate selection fields. A matching speed does not establish the required wake function, and a matching MAC interface does not describe the qualifying traffic. The related interface guide addresses the connection between PHY and MAC. The wake review instead follows the documented event from received frame to the indication delivered beyond the PHY.

2. Specify the supported qualifying frame

TI lists Magic Packet, Magic Packet with Secure-ON and Custom Pattern Match among the DP83822's supported wake-frame types. Preserve which documented criterion the application requires. The phrase supports Wake-on-LAN is less precise because it leaves the recognition requirement unnamed. Matching a broad feature label cannot establish that the requested frame condition is the one a candidate implements.

The description also includes CRC checking to prevent invalid frames from triggering a wake event. This adds a qualification stage to the functional chain: a received frame and an accepted wake event are not identical descriptions. Retain that stated gate rather than treating the presence of traffic as sufficient evidence that a wake indication should occur.

A frame-type description is not a packet-generation procedure. The application still needs its own applicable configuration and network evidence. This guide does not reproduce packet bytes, addresses or pattern values, and Secure-ON wording is not promoted into a general security guarantee. The selection decision concerns the documented recognition function and its scope, not an invented working frame for the reader's equipment.

3. Separate notification from host resume

After detection, the event must be communicated. TI describes register-status change, GPIO indication and an interrupt flag as notification mechanisms in the DP83822 discussion. These are ways to report the qualifying event to a connected controller. Keep the required mechanism visible when comparing candidates rather than treating every notification option as the same interface.

A status indication answers whether the PHY has reported its event; successful host resume answers a later system question. The distinction matters when interpreting available evidence. A product description of packet detection cannot demonstrate that the board connects the required notification path, that the host uses it, or that the intended system state changes in response.

Identify the notification requirement at the functional level before seeking implementation evidence. This allows a reviewer to ask the exact question about the candidate and board without assigning a physical GPIO position or prescribing register writes from an overview. The component's capability and the application's use of that capability must remain attributable to their own documentation.

4. Preserve configuration and power dependencies

A wake function needs the relevant detection and notification path available in the intended low-power situation. TI describes higher-layer devices remaining in low power while the PHY recognises qualifying frames. That description does not establish the same result when the detection path has no power. Preserve which part of the application remains able to perform the documented function.

Configuration and status are also part of the named device's wake discussion. A feature being available in the datasheet does not document that an unidentified board has selected the required behaviour. The application comparison should identify the expected recognition criterion and notification mechanism together, with its actual configuration basis assessed separately. No register address or setup sequence is specified here.

Keep power delivery itself distinct from wake detection. The PoE powered-device role concerns a different part of an Ethernet application and does not supply this wake configuration. A complete sourcing requirement can therefore preserve frame qualification, event reporting and the relevant power-state context as separate linked decisions, without claiming a tested host resume or an accepted replacement for the board.

Sources and further reading

TI DP83822 product text and SNLS505H sections 7.3.2/7.3.2.3 were reread on 15 October 2026. The guide uses only frame-qualification, CRC-gate and notification concepts; packet bytes, register settings, physical GPIO mapping and host-resume results are excluded.