usb_udc_vbus_handler(9)

πŸ“¦ version 7.3.1, in nixpkgs unstable

✨ NAME ✨

okay so bestie, welcome to the page for usb_udc_vbus_handler(9) from the Kernel API Manual 🫢 This is the function that updates the udc core vbus status, and try to connect or disconnect gadget. That's the name-section tea β˜•.

πŸ“œ SYNOPSIS πŸ“œ

void usb_udc_vbus_handler (struct usb_gadget *gadget , bool status );

yep, it returns void β€” nothing comes back out, bestie πŸ’….

πŸŽ€ ARGUMENTS πŸŽ€

  • gadget β€” the gadget where the vbus change occurs. That's the one getting the vbus update.
  • status β€” the vbus status. That's it, that's the argument 🌸.

πŸ’… DESCRIPTION πŸ’…

The udc driver calls it when it wants to connect or disconnect the gadget according to vbus status. Simple vibe on the surface, right? ✨

Now the important context check, because this is where people get got πŸ’€ This function can be invoked from interrupt context by irq handlers of the gadget drivers. However, usb_udc_connect_control has to run in non-atomic context due to the following:

  1. Some of the gadget driver implementations expect the ->pullup callback to be invoked in non-atomic context.
  2. usb_gadget_disconnect acquires udc_lock, which is a mutex.

Hence, the invocation of usb_udc_connect_control is offloaded to a workqueue. So yeah: interrupt context for this function? fine. usb_udc_connect_control in atomic context? absolutely not, bestie 😭 context rules ate here.

🌈 SEE ALSO 🌈

go read these too, iykyk πŸ‘‘:

mwah πŸ’‹ that's the page! source/version: ./drivers/usb/gadget/udc Β· date: October 2026 Β· page: usb_udc_vbus_handler(9) 🫢

πŸ“¦ where this page comes from