phylink_rx_clk_stop_block(9)

πŸ“¦ version 7.3.1, in nixpkgs unstable

Okay so buckle up, because this is a function page from the Kernel API Manual, and we're gonna read it together like the group chat is watching. ✨


🌸 NAME 🌸

phylink_rx_clk_stop_block β€” literally blocks the PHY from being able to stop the receive clock in LPI. That's the whole vibe. πŸ‘‘


πŸ¦‹ SYNOPSIS πŸ¦‹

void phylink_rx_clk_stop_block (struct phylink *pl );

No return value, no drama. It's a void. It just does the thing and leaves. πŸ’…


🌈 ARGUMENTS 🌈

  • pl β€” a pointer to a struct phylink that you got back from phylink_create. Like, you can't just manifest it out of thin air, bestie, you gotta have it handed to you legit. 🫢

πŸ’œ DESCRIPTION πŸ’œ

So here's what's happening: this disables the PHY's ability to stop the receive clock while the receive path is in EEE LPI state.

Read that again. Take it in. The PHY wanted to be cute and gate off the clock during low-power idle, and this function says not today. 🚫⏰

And it stays that way until the number of calls to phylink_rx_clk_stop_block are balanced by calls to phylink_rx_clk_stop_unblock.

Important bestie note: it's a balance situation. Block and unblock have to match up, like a friendship where both people text back. If you block three times, you need three unblocks to get back to normal. Not two. Not four. Three. Iykyk. 😭✨

🧚 SEE ALSO 🧚

Like the most iconic crossover event ever β€” every one of these is invited to the party:


And that's the whole page, bestie β€” go forth and keep those block/unblock counts balanced. 🌟

Sign-off time 🫢: this cutie lives in ./drivers/net/phy, dated October 2026, and answers to the name phylink_rx_clk_stop_block(9). Main character energy fr fr. πŸ’–πŸŽ€

πŸ“¦ where this page comes from