| 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 | |
| an interface. A driver's bond to an interface is exclusive. | |
| The probe() callback | |
| -------------------- | |
| :: | |
| int (*probe) (struct usb_interface *intf, | |
| const struct usb_device_id *id); | |
| Accept or decline an interface. If you accept the device return 0, | |
| otherwise -ENODEV or -ENXIO. Other error codes should be used only if a | |
| genuine error occurred during initialisation which prevented a driver | |
| from accepting a device that would else have been accepted. | |
| You are strongly encouraged to use usbcore's facility, | |
| usb_set_intfdata(), to associate a data structure with an interface, so | |
| that you know which internal state and identity you associate with a | |
| particular interface. The device will not be suspended and you may do IO | |
| to the interface you are called for and endpoint 0 of the device. Device | |
| initialisation that doesn't take too long is a good idea here. | |
| The disconnect() callback | |
| ------------------------- | |
| :: | |
| void (*disconnect) (struct usb_interface *intf); | |
| This callback is a signal to break any connection with an interface. | |
| You are not allowed any IO to a device after returning from this | |
| callback. You also may not do any other operation that may interfere | |
| with another driver bound the interface, eg. a power management | |
| operation. | |
| If you are called due to a physical disconnection, all your URBs will be | |
| killed by usbcore. Note that in this case disconnect will be called some | |
| time after the physical disconnection. Thus your driver must be prepared | |
| to deal with failing IO even prior to the callback. | |
| Device level callbacks | |
| ====================== | |
| pre_reset | |
| --------- | |
| :: | |
| int (*pre_reset)(struct usb_interface *intf); | |
| A driver or user space is triggering a reset on the device which | |
| contains the interface passed as an argument. Cease IO, wait for all | |
| outstanding URBs to complete, and save any device state you need to | |
| restore. No more URBs may be submitted until the post_reset method | |
| is called. | |
| If you need to allocate memory here, use GFP_NOIO or GFP_ATOMIC, if you | |
| are in atomic context. | |
| post_reset | |
| ---------- | |
| :: | |
| int (*post_reset)(struct usb_interface *intf); | |
| The reset has completed. Restore any saved device state and begin | |
| using the device again. | |
| If you need to allocate memory here, use GFP_NOIO or GFP_ATOMIC, if you | |
| are in atomic context. | |
| Call sequences | |
| ============== | |
| No callbacks other than probe will be invoked for an interface | |
| that isn't bound to your driver. | |
| Probe will never be called for an interface bound to a driver. | |
| Hence following a successful probe, disconnect will be called | |
| before there is another probe for the same interface. | |
| Once your driver is bound to an interface, disconnect can be | |
| called at any time except in between pre_reset and post_reset. | |
| pre_reset is always followed by post_reset, even if the reset | |
| failed or the device has been unplugged. | |
| suspend is always followed by one of: resume, reset_resume, or | |
| disconnect. |