usb_sg_init(9)

πŸ“¦ version 7.3.1, in nixpkgs unstable

πŸ’« usb_sg_init β€” the Kernel API Manual glow-up πŸ’«

okay so bestie, welcome to usb_sg_init(9) from the Kernel API Manual β€” this is the function that initializes scatterlist-based bulk/interrupt I/O requests and honestly? it's kind of the moment. πŸŽ€


✨ SYNOPSIS ✨

int usb_sg_init (struct usb_sg_request *io , struct usb_device *dev ,
unsigned pipe , unsigned period , struct scatterlist *sg , int nents ,
size_t length , gfp_t mem_flags );

like yes that's a lot of parameters, breathe, we're gonna go through every single one πŸ’…


πŸ¦‹ ARGUMENTS πŸ¦‹

  • io β€” the request block that's being initialized. real talk: until usb_sg_wait returns, you gotta treat this as a pointer to an opaque block of memory. no peeking, no cap πŸ‘€
  • dev β€” the usb device that's gonna send or receive the data. the main character of this whole operation, fr
  • pipe β€” the endpoint "pipe" used to transfer the data. the lil delivery chute πŸ’Œ
  • period β€” the polling rate for interrupt endpoints, in frames or (for high speed endpoints) microframes; it's ignored for bulk, so don't stress about it if you're doing bulk i/o, bestie 🫢
  • sg β€” the scatterlist entries. this is the whole point of the function honestly
  • nents β€” how many entries are in that scatterlist. gotta know the count, iykyk
  • length β€” how many bytes to send from the scatterlist, or zero to send every byte identified in the list. zero = send it all, iconic behavior 🌈
  • mem_flags β€” the SLAB_* flags affecting memory allocations in this call. memory allocation vibes set here ✨

πŸ’– DESCRIPTION πŸ’–

so this initializes a scatter/gather request, allocating resources such as I/O mappings and urb memory (except maybe memory used by USB controller drivers). it's giving "getting everything ready for you before the real work starts" πŸ’…

the request must be issued using usb_sg_wait, which waits for the I/O to complete (or to be canceled) and then cleans up all resources allocated by usb_sg_init. so like, usb_sg_wait is the responsible friend who cleans up after the party 🧹

the request may be canceled with usb_sg_cancel, either before or after usb_sg_wait is called. flexible queen behavior honestly πŸ‘‘


⭐ RETURN ⭐

zero for success, else a negative errno value. simple as that, no notes 😌


πŸ”₯ SEE ALSO πŸ”₯

kernel file ./drivers/usb/core/message.c plus the whole friend group:

like, the whole squad showed up for this one πŸ«‚πŸ’œ


bestie reminder: usb_sg_init does not clean up after itself β€” that's on usb_sg_wait. don't leave your resources hanging, that's not the vibe πŸ™ˆ

and that's the tea! πŸ“ this page lives in ./drivers/usb/core, dated October 2026, and we out here shipping usb_sg_init(9) into your brain. slay, go write some scatter/gather i/o, you're doing amazing βœ¨πŸŽ€πŸ’–

πŸ“¦ where this page comes from