usb_control_msg_send(9)

📦 version 7.3.1, in nixpkgs unstable

💅 usb_control_msg_send(9) — the Kernel API Manual page you've been waiting for

Okay bestie, this is usb_control_msg_send from the Kernel API Manual, and it is literally the function that builds a control "send" message, sends it off and waits for completion. No cap. Let's get into it 🫶

✨ SYNOPSIS ✨

int usb_control_msg_send (struct usb_device *dev , __u8 endpoint , __u8
request , __u8 requesttype , __u16 value , __u16 index , const void
*driver_data , __u16 size , int timeout , gfp_t memflags );

That's a whole lot of arguments and honestly? She ate. Let's meet them one by one 👑

🎀 ARGUMENTS 🎀

  • dev — pointer to the usb device to send the message to. This is your main character, the one getting the message 💌
  • endpoint — endpoint to send the message to
  • request — USB message request value
  • requesttype — USB message request type value
  • value — USB message value
  • index — USB message index value
  • driver_data — pointer to the data to send
  • size — length in bytes of the data to send
  • timeout — time in msecs to wait for the message to complete before timing out
  • memflags — the flags for memory allocation for buffers

🦋 CONTEXT 🦋

!in_interrupt ()

Read that again, bestie — not in interrupt context. That's the vibe check this function demands 🌸

💖 DESCRIPTION 💖

So what does she actually do? This function sends a control message to a specified endpoint that is not expected to fill in a response (i.e. a "send message") and waits for the message to complete, or timeout. That's it. That's the whole gig ✨

🚨 Do not use this function from within an interrupt context. Not me warning you twice. If you need an asynchronous message, or need to send a message from within interrupt context, use usb_submit_urb.

And the part everyone forgets: if a thread in your driver uses this call, make sure your disconnect method can wait for it to complete. Because — and this is the lowkey sad part 😭 — since you don't have a handle on the URB used, you can't cancel the request. Not even a little bit. Periodt.

Okay but here's the iconic part 🎀 The data pointer can be made to a reference on the stack, or anywhere else, as it will not be modified at all. Unlike usb_control_msg, this one does not have the restriction where the data pointer must be to dynamically allocated memory (i.e. memory that can be successfully DMAed to a device). Stack pointer? Fine. Random pointer? Fine. She's flexible like that 💅

🔥 RETURN 🔥

  • If successful, 0 is returned. Slay 🌟
  • Otherwise, a negative error number. Rough, but honest 💀

🌈 SEE ALSO 🌈

Kernel file ./drivers/usb/core/message.c and this absolutely stacked friend group:

That's the whole page, bestie 🧚 go forth and send your control messages responsibly 💜

xoxo, dropping this from ./drivers/usb/core, October 2026 edition — stay iconic 👑💖

📦 where this page comes from