usb_get_status(9)

🎀 usb_get_status — a Kernel API Manual moment, bestie 🎀

Ok so we're diving into usb_get_status(9) today and honestly? It's giving "small function, big job" energy. This is the kernel API manual, and this lil baby issues a GET_STATUS call — that's the whole NAME, periodt. 💅

---

✨ SYNOPSIS ✨

int usb_get_status (struct usb_device *dev , int recip , int type , int target , void *data );

Like, look at that signature. Five arguments. She's thorough and we respect it. 🫶

---

🦋 ARGUMENTS 🦋

• dev — the device whose status is being checked 👀 like, whose vibe are we checking exactly
• recip — USB_RECIP_*; for device, interface, or endpoint. Basically "who's the recipient of this whole situation"
• type — USB_STATUS_TYPE_*; for standard or PTM status types
• target — zero (for device), else interface or endpoint number. So 0 means "the device itself", anything else is like "no babe, that specific interface or endpoint"
• data — pointer to two bytes of bitmap data 🗺️ two whole bytes, that's the cargo

---

🌸 CONTEXT 🌸

task context, might sleep. 😴

No fr, that means you canNOT pull this in an interrupt context — she needs her nap time and that's non-negotiable.

---

💖 DESCRIPTION 💖

Returns device, interface, or endpoint status. That's the tea. ☕

Normally only of interest to see if the device is self powered, or has enabled the remote wakeup facility; or whether a bulk or interrupt endpoint is halted ("stalled"). Those are literally the main character reasons you'd ever call this, iykyk.

Bits in these status bitmaps are set using the SET_FEATURE request, and cleared using the CLEAR_FEATURE request. So set-feature and clear-feature are the ones flipping the switches, bestie, not this function. 🔥

The usb_clear_halt function should be used to clear halt ("stall") status. Like — do NOT try to DIY the un-stalling, that's not what we're here for. 🙈

This call is synchronous, and may not be used in an interrupt context. Sleepy function, sleepy rules. 💀

And the results? Returns 0 and the status value in *data (in host byte order) on success, or else the status code from the underlying usb_control_msg call. So 0 = slay, anything else = the actual error from the layer underneath. 🫡

---

👑 SEE ALSO 👑

Kernel file ./drivers/usb/core/message.c — and honestly the whole friend group:

• usb_control_msg(9)
• usb_control_msg_send(9)
• usb_control_msg_recv(9)
• usb_interrupt_msg(9)
• usb_bulk_msg(9)
• usb_bulk_msg_killable(9)
• usb_sg_init(9)
• usb_sg_wait(9)
• usb_sg_cancel(9)
• usb_get_descriptor(9)
• usb_get_string(9)
• usb_string(9)
• usb_cache_string(9)
• usb_clear_halt(9)
• usb_disable_endpoint(9)
• usb_reset_endpoint(9)
• usb_disable_interface(9)
• usb_disable_device(9)
• usb_enable_endpoint(9)
• usb_enable_interface(9)
• usb_set_interface(9)
• usb_reset_configuration(9)
• usb_set_wireless_status(9)
• usb_driver_set_configuration(9)
• cdc_parse_cdc_header(9)

---

Sign-off time, bestie 🧚 this page lives in ./drivers/usb/core, it's dated October 2026, and it's filed under usb_get_status(9) in the Kernel API Manual. That's the whole vibe, we ate, no crumbs left. 💜🎀✨