usb_autopm_g...erface_async(9)

📦 version 7.3.1, in nixpkgs unstable

👑 usb_autopm_get_interface_async — like, the manual page bestie 💅

okay so picture this: it's the Kernel API Manual and we're about to learn usb_autopm_get_interface_async together. grab a strawberry 🍓, sit down, this one's actually short and kinda iconic.

✨ NAME ✨

usb_autopm_get_interface_async — bestie, it bumps up a USB interface's PM-usage counter. that's the whole job. she's a counter girlie 💖

🌸 SYNOPSIS 🌸

int usb_autopm_get_interface_async (struct usb_interface *intf );

literally one argument, we love a low-maintenance function 🫶

🎀 ARGUMENTS 🎀

  • intf — the usb_interface whose counter we're about to increment. yes. that one. the one you're pointing at. give her a +1 💅

🦋 DESCRIPTION 🦋

okay so lowkey this routine does much the same thing as usb_autopm_get_interface: it increments intf's usage counter, and if the device is suspended it queues an autoresume request. same vibe, mostly.

but here's the differences part, and this is important so don't scroll:

  • it does not perform any synchronization — nope, none, zero. callers should hold a private lock and handle all the synchronization issues themselves. that's a you problem now, bestie 😭 own it.
  • it does not autoresume the device directly — it only queues a request. so after a successful call, the device may not yet be resumed. like, she's thinking about it. she hasn't committed. 🙈

also she's flexible: this routine can run in atomic context. slay 🔥

⭐ RETURN ⭐

  • 0 on success 💖
  • a negative error code otherwise 💀

🌈 SEE ALSO 🌈

kernel file ./drivers/usb/core/driver.c — and the whole squad:

ngl the biggest takeaway: no synchronization, no direct autoresume, and she'll happily run in atomic context. if you forget the private lock that's on you, not on her 🧚

and that's the whole page, fr fr. this was usb_autopm_get_interface_async(9), living in ./drivers/usb/core, dated October 2026 — mwah, go touch some USB devices 💜🎀

📦 where this page comes from