Documentation/driver-api/usb/callbacks.rst
Source file repositories/reference/linux-study-clean/Documentation/driver-api/usb/callbacks.rst
File Facts
- System
- Linux kernel
- Corpus path
Documentation/driver-api/usb/callbacks.rst- Extension
.rst- Size
- 5110 bytes
- Lines
- 160
- Domain
- Support Tooling And Documentation
- Bucket
- Documentation
- Inferred role
- Support Tooling And Documentation: documentation
- Status
- atlas-only
Why This File Exists
Repository support layer: documentation, build tooling, samples, user-space helper tools, generated initramfs support, licenses, and validation utilities.
- Repository support layer: documentation, build tooling, samples, user-space helper tools, generated initramfs support, licenses, and validation utilities.
- Defines or uses C structs; map object ownership, embedded links, reference counts, and lock ownership.
Dependency Surface
- No C-style include directives detected by the generator.
Detected Declarations
- No top-level syscall, struct, function, initcall, or export declaration detected by the generator.
Annotated Snippet
USB core callbacks
~~~~~~~~~~~~~~~~~~
What callbacks will usbcore do?
===============================
Usbcore will call into a driver through callbacks defined in the driver
structure and through the completion handler of URBs a driver submits.
Only the former are in the scope of this document. These two kinds of
callbacks are completely independent of each other. Information on the
completion callback can be found in :ref:`usb-urb`.
The callbacks defined in the driver structure are:
1. Hotplugging callbacks:
- @probe:
Called to see if the driver is willing to manage a particular
interface on a device.
- @disconnect:
Called when the interface is no longer accessible, usually
because its device has been (or is being) disconnected or the
driver module is being unloaded.
2. Odd backdoor through usbfs:
- @ioctl:
Used for drivers that want to talk to userspace through
the "usbfs" filesystem. This lets devices provide ways to
expose information to user space regardless of where they
do (or don't) show up otherwise in the filesystem.
3. Power management (PM) callbacks:
- @suspend:
Called when the device is going to be suspended.
- @resume:
Called when the device is being resumed.
- @reset_resume:
Called when the suspended device has been reset instead
of being resumed.
4. Device level operations:
- @pre_reset:
Called when the device is about to be reset.
- @post_reset:
Called after the device has been reset
The ioctl interface (2) should be used only if you have a very good
reason. Sysfs is preferred these days. The PM callbacks are covered
separately in :ref:`usb-power-management`.
Calling conventions
===================
All callbacks are mutually exclusive. There's no need for locking
against other USB callbacks. All callbacks are called from a task
context. You may sleep. However, it is important that all sleeps have a
small fixed upper limit in time. In particular you must not call out to
user space and await results.
Hotplugging callbacks
=====================
These callbacks are intended to associate and disassociate a driver with
Annotation
- Atlas domain: Support Tooling And Documentation / Documentation.
- Implementation status: atlas-only.
Implementation Notes
- This generated page is the file-by-file coverage layer; curated subsystem chapters should link here when they synthesize a multi-file control flow.
- Core OS pages should be promoted from atlas-only to deep-reviewed when they explain data structures, invariants, locking, lifecycle, and C implementation snippets.
- Driver-family pages are intentionally pattern-oriented unless they are part of the selected PCIe/NVMe representative device path.