ssh_rtl_flush(9)

📦 version 7.3.1, in nixpkgs unstable

💅 ssh_rtl_flush(9) — the Kernel API Manual, bestie edition 🎀

okay so this is a page from the Kernel API Manual, and it's about ssh_rtl_flush, which is genuinely one of those "wait for everyone to finish before you close the door" functions. it's giving group project final submission energy fr fr. 🦋

✨ NAME ✨

ssh_rtl_flush — flush the request transport layer. that's it, that's the whole vibe check. 🫶

🌸 SYNOPSIS 🌸

int ssh_rtl_flush (struct ssh_rtl *rtl , unsigned long timeout );

like, you hand it a request transport layer and a timeout and it returns an int. iconic signature, no notes. 👑

🎀 ARGUMENTS 🎀

  • rtl — the request transport layer itself. the main character of this whole operation. ✨
  • timeout — how long the flush operation is allowed to take, measured in jiffies. yes, jiffies. not seconds, not vibes. jiffies. ⏳

💖 DESCRIPTION 💖

so here's what happens, bestie. this function queues a special flush request and waits for it to complete. that's the whole move.

and the way this works is lowkey elegant: that flush request won't complete until all the other currently queued and pending requests have completed first. it's literally at the back of the line and it refuses to be a line-cutter. 🙈 instead of a normal data packet, it submits a special flush packet — which means that when it completes, the underlying packet transport layer has been flushed too. double whammy, slay. 💅

flushing the request layer guarantees that all previously submitted requests have been fully completed before this call returns. and on top of that, flushing blocks execution of all later submitted requests until the flush is done. so nobody sneaks past while the door is closing. no cap. 🚪

now, the important little caveat: if the caller ensures that no new requests are submitted after a call to this function, then the request transport layer is guaranteed to have no remaining requests when this call returns. gorgeous, perfect, exactly what you want.

but — and this is the part where you gotta pay attention — the same guarantee does not hold for the packet layer. on the packet layer, control packets may still be queued after this call. so like, don't go assuming it's spotless over there, because it isn't. 😭

🔥 RETURN 🔥

  • 0 — success! we ate. 🍓
  • -ETIMEDOUT — the flush timed out, and it's been canceled as a result of the timeout. clock ran out, it's over. 💀
  • -ESHUTDOWN — the packet and/or request transport layer got shut down before this call happened. rude, honestly. 🌧️
  • -EINTR — may also return this if the underlying packet transmission has been interrupted. 🙃

🌈 SEE ALSO 🌈

the source of truth lives right here in the kernel file:

./drivers/platform/surface/aggregator/ssh_request_layer.c

and these absolute icons are all related, go read them too:

reminder bestie: the request-layer guarantee is real, but the packet layer can still have control packets kicking around after this returns. don't be out here trusting the wrong layer, iykyk. ⭐

and that's the page!! sign-off time: this little love letter comes from source ./drivers/platform/surface/agg..., dated October 2026, and the header/version info is ssh_rtl_flush(9) from the Kernel API Manual. mwah, go flush responsibly 🧚💜

📦 where this page comes from