phylink_rx_clk_stop_unblock(9)

πŸ“¦ version 7.3.1, in nixpkgs unstable

🌸 NAME 🌸

phylink_rx_clk_stop_unblock β€” like, the function that unblocks the PHY's ability to stop the receive clock πŸ’… (this is the "okay bestie you can breathe again" of receive-clock-stopping permissions)

So real talk, the manual name here is phylink_rx_clk_stop_unblock(9), and it lives in the Kernel API Manual, which β€” yes β€” is exactly as iconic as it sounds πŸ‘‘


✨ SYNOPSIS ✨

void phylink_rx_clk_stop_unblock (struct phylink *pl );

That's it. That's the whole vibe. No return value, no drama, just a void queen doing her one job 🫢


πŸŽ€ ARGUMENTS πŸŽ€

  • pl β€” a pointer to a struct phylink that came back from phylink_create 🌱 iykyk, don't just pass in some random pointer, she needs the real one

πŸ’– DESCRIPTION πŸ’–

okay so here's the tea β˜• β€” every single call to phylink_rx_clk_stop_block has to be balanced with a matching call to phylink_rx_clk_stop_unblock. Balanced. Like, for real. No cap.

Why? Because this is the function that restores the PHY's ability to stop the receive clock when the receive path is in EEE LPI mode ⭐ Basically phylink_rx_clk_stop_block says "nope, clock stays on," and this one says "okay bestie, you may stop it again when the situation calls for it" πŸ¦‹

Think of it as the ultimate pair β€” one blocks, one unblocks, and if you leave them unbalanced, that's giving unfinished business 😭


🌈 SEE ALSO 🌈

The main character lives right here in ./drivers/net/phy/phylink.c, and honestly the whole friend group is extensive:


πŸ’€ reminder bestie: phylink_rx_clk_stop_block and phylink_rx_clk_stop_unblock are a matched set. Unbalanced calls = not the vibe. Keep the count even, periodt.

and that's the whole page, bestie πŸ§šπŸ’œ This one's brought to you from ./drivers/net/phy, dated October 2026, and it's phylink_rx_clk_stop_unblock(9) all the way down πŸ“ Go balance those calls, ily, bye 😭✨

πŸ“¦ where this page comes from