STRUCT USB_SG_REQUEST(9)

πŸ“¦ version 7.3.1, in nixpkgs unstable

✨ struct usb_sg_request(9) ✨

Okay bestie, welcome to the Kernel API Manual πŸ’… this one's about struct usb_sg_request and it's genuinely giving "scatter/gather I/O support" β€” like, that's the whole gig, no cap.


πŸŽ€ NAME πŸŽ€

struct usb_sg_request β€” literally support for scatter/gather I/O 🌸


πŸ¦‹ SYNOPSIS πŸ¦‹

struct usb_sg_request {
    int status;
    size_t bytes;
 };

That's the whole struct, bestie. Two members. Tiny. Iconic. πŸ‘‘


🌟 Members 🌟

  • status β€” zero means slay (success πŸ’–), anything else is a negative errno, so like… not slay 😭
  • bytes β€” counts the bytes that actually got transferred, fr fr πŸ“

πŸ’œ Description πŸ’œ

So here's the vibe: these requests get initialized using usb_sg_init, and after that they're used as request handles passed to usb_sg_wait or usb_sg_cancel. That's their whole main character arc ✨

Most members of the request object aren't for driver access β€” like, they're not yours to touch, bestie, hands off πŸ™ˆ

The status and bytecount values are valid only after usb_sg_wait returns. Read that again. Only after. Don't be out here reading them early, that's not the vibe πŸ’€

If the status is zero, then the bytecount matches the total from the request 🎯

Heads up 🫢 after an error completion, drivers may need to clear a halt condition on the endpoint. Not optional energy, just so you know.

🌈 SEE ALSO 🌈

Kernel file ./include/linux/usb.h β€” plus the whole friend group:


That's the whole page, bestie, you ate it up πŸ’…πŸ«Ά this one lives in ./include/linux and it's dated October 2026 β€” mwah, go read your USB headers, ily, bye! πŸŒΈπŸ’–βœ¨

πŸ“¦ where this page comes from