usb_gadget_d...nc_callbacks(9)

📦 version 7.3.1, in nixpkgs unstable

💅 usb_gadget_d...nc_callbacks(9) — a Kernel API Manual moment 💅

okay bestie, this page is short but it is doing important race-condition damage control, so pay attention. 💖

🌸 NAME 🌸

usb_gadget_disable_async_callbacks — the function that tells the usb device controller to disable asynchronous callbacks. yes, it's a mouthful, but she's worth it 💅

✨ SYNOPSIS ✨

void usb_gadget_disable_async_callbacks (struct usb_udc *udc );

🎀 ARGUMENTS 🎀

  • udc — the UDC which should disable async callbacks. that's the target, bestie 🎯

🦋 DESCRIPTION 🦋

okay so this routine is what you use when you're unbinding gadget drivers. It's literally the race-condition prevention bestie: the UDC driver doesn't know when the gadget driver's ->unbind callback runs, so unless it is told to disable asynchronous callbacks, it might issue a callback (such as ->disconnect) after the unbind has completed. and that is exactly the kind of messy timeline we are not doing 💀

After this function runs, the UDC driver must suppress all ->suspend, ->resume, ->disconnect, ->reset, and ->setup callbacks to the gadget driver until async callbacks are again enabled. A simple-minded but effective way to accomplish this is to tell the UDC hardware not to generate any more IRQs. iconic, honestly 🔥

Request completion callbacks must still be issued. However, it's okay to defer them until the request is cancelled, since the pull-up will be turned off during the time period when async callbacks are disabled. so yeah, deferring is allowed — the pull-up dips during that window 🫶

This routine will always be called in process context. periodt. ✨

💖 SEE ALSO 💖

Kernel file: ./drivers/usb/gadget/udc/core.c

the whole squad, in order, no cap:

okay that's the page, bestie 🫶 mwah 💋 this one is from the source/version ./drivers/usb/gadget/udc corner, dated October 2026, and it's the usb_gadget_d...nc_callbacks(9) entry. no cap, that's the whole footer vibe ✨

📦 where this page comes from