usb_suspend_both(9)

πŸ“¦ version 7.3.1, in nixpkgs unstable

✨ NAME ✨

Bestie, meet usb_suspend_both(9) β€” the Kernel API Manual baddie whose whole thing is suspending a USB device and its interfaces. πŸ’…βœ¨


🌸 SYNOPSIS 🌸

int usb_suspend_both (struct usb_device *udev , pm_message_t msg );

πŸŽ€ ARGUMENTS πŸŽ€

  • udev β€” the usb_device to suspend, aka the main character here πŸ‘‘
  • msg β€” the Power Management message describing this state transition πŸ¦‹

πŸ¦‹ DESCRIPTION πŸ¦‹

Okay so this is the central routine for suspending USB devices. It calls the suspend methods for all the interface drivers in udev, and then it calls the suspend method for udev itself. Iconic behavior, no cap. πŸ’–

When the routine is called in autosuspend, if an error occurs at any stage, all the interfaces which were suspended are resumed so that they remain in the same state as the device. But when it’s called from system sleep, all error from suspend methods of interfaces and the non-root-hub device itself are simply ignored, so all suspended interfaces are only resumed to the device’s state when udev is root-hub and its suspend method returns failure. Yes, that is a lot β€” read it twice, bestie. πŸ˜­πŸ’€

Autosuspend requests originating from a child device or an interface driver may be made without the protection of udev’s device lock, but all other suspend calls will hold the lock. Usbcore will insure that method calls do not arrive during bind, unbind, or reset operations. However drivers must be prepared to handle suspend calls arriving at unpredictable times. 🫢

Process context only, bestie β€” this routine can run only in process context. πŸ§šπŸ’œ

πŸ‘‘ RETURN πŸ‘‘

0 if the suspend succeeded. Periodt. ⭐


πŸ’– SEE ALSO πŸ’–

Kernel file ./drivers/usb/core/driver.c β€” the whole squad πŸ‘―:


Byeeee πŸ’‹ β€” source/version vibes from ./drivers/usb/core, dated October 2026, and yes the manual is still usb_suspend_both(9). πŸŽ€πŸŒˆ

πŸ“¦ where this page comes from