usb_set_device_state(9)

πŸ“¦ version 7.3.1, in nixpkgs unstable

πŸ’… usb_set_device_state(9) πŸ’…

okay bestie, welcome to the Kernel API Manual β€” yes we're in the kernel today, and yes this function is lowkey iconic. here's the whole vibe check on usb_set_device_state, a usbcore/hcds situation that changes a device's current state πŸ¦‹


✨ NAME ✨

usb_set_device_state β€” change a device's current state (usbcore, hcds) πŸ‘‘


πŸŽ€ SYNOPSIS πŸŽ€

void usb_set_device_state (struct usb_device *udev , enum
usb_device_state new_state );

🌸 ARGUMENTS 🌸

  • udev β€” pointer to the device whose state should be changed. like, this one, right here 🫢
  • new_state β€” the new state value to be stored. the fresh fit it's gonna be wearing πŸ’…

🌈 DESCRIPTION 🌈

okay so this is the part where you gotta pay attention, because it's giving "safety goggles on" energy 😭

udev->state is not fully protected by the device lock. like, at all. no cap. even though most transitions are made only while holding the lock, the state can change to USB_STATE_NOTATTACHED at almost any time ⏰ β€” and that's on purpose! it's so devices can be marked as disconnected as soon as possible, without having to wait for any semaphores to be released. iconic efficiency, honestly ✨

but the consequence?? as a result, all changes to any device's state must be protected by the device_state_lock spinlock πŸ”’. every single one. periodt.

once a device has been added to the device tree, all changes to its state should be made using this routine. the state should not be set directly. don't do it. i'm literally begging πŸ™ˆ

here's the actual logic, bestie:

  • if udev->state is already USB_STATE_NOTATTACHED then no change is made β€” nothing happens, we move on πŸ’€
  • otherwise udev->state is set to new_state β€” slay πŸ’–
  • and if new_state is USB_STATE_NOTATTACHED, then all of udev's descendants' states are also set to USB_STATE_NOTATTACHED β€” the whole family gets the news at once, rip 🫑
no cap: setting state directly instead of going through this routine after the device is in the device tree is a don't. the lock is not optional. the whole descendant-update cascade is not optional either πŸ”₯

🧚 SEE ALSO 🧚

kernel file ./drivers/usb/core/hub.c and its little friend group πŸ’œ


and that's the page!! πŸŽ‰ brought to you by ./drivers/usb/core, dated October 2026, and yeah β€” usb_set_device_state(9) is the main character here, obviously πŸ‘‘πŸ’– go forth and guard that state with the spinlock, bestie πŸ¦‹πŸŒΈ

πŸ“¦ where this page comes from