| 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 Documentation/usb/URB.txt. |
| |
| 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 Documentation/usb/power-management.txt. |
| |
| 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. |