diff options
-rw-r--r-- | Documentation/usb/callbacks.txt | 132 |
1 files changed, 132 insertions, 0 deletions
diff --git a/Documentation/usb/callbacks.txt b/Documentation/usb/callbacks.txt new file mode 100644 index 000000000000..7c812411945b --- /dev/null +++ b/Documentation/usb/callbacks.txt | |||
@@ -0,0 +1,132 @@ | |||
1 | What callbacks will usbcore do? | ||
2 | =============================== | ||
3 | |||
4 | Usbcore will call into a driver through callbacks defined in the driver | ||
5 | structure and through the completion handler of URBs a driver submits. | ||
6 | Only the former are in the scope of this document. These two kinds of | ||
7 | callbacks are completely independent of each other. Information on the | ||
8 | completion callback can be found in Documentation/usb/URB.txt. | ||
9 | |||
10 | The callbacks defined in the driver structure are: | ||
11 | |||
12 | 1. Hotplugging callbacks: | ||
13 | |||
14 | * @probe: Called to see if the driver is willing to manage a particular | ||
15 | * interface on a device. | ||
16 | * @disconnect: Called when the interface is no longer accessible, usually | ||
17 | * because its device has been (or is being) disconnected or the | ||
18 | * driver module is being unloaded. | ||
19 | |||
20 | 2. Odd backdoor through usbfs: | ||
21 | |||
22 | * @ioctl: Used for drivers that want to talk to userspace through | ||
23 | * the "usbfs" filesystem. This lets devices provide ways to | ||
24 | * expose information to user space regardless of where they | ||
25 | * do (or don't) show up otherwise in the filesystem. | ||
26 | |||
27 | 3. Power management (PM) callbacks: | ||
28 | |||
29 | * @suspend: Called when the device is going to be suspended. | ||
30 | * @resume: Called when the device is being resumed. | ||
31 | * @reset_resume: Called when the suspended device has been reset instead | ||
32 | * of being resumed. | ||
33 | |||
34 | 4. Device level operations: | ||
35 | |||
36 | * @pre_reset: Called when the device is about to be reset. | ||
37 | * @post_reset: Called after the device has been reset | ||
38 | |||
39 | The ioctl interface (2) should be used only if you have a very good | ||
40 | reason. Sysfs is preferred these days. The PM callbacks are covered | ||
41 | separately in Documentation/usb/power-management.txt. | ||
42 | |||
43 | Calling conventions | ||
44 | =================== | ||
45 | |||
46 | All callbacks are mutually exclusive. There's no need for locking | ||
47 | against other USB callbacks. All callbacks are called from a task | ||
48 | context. You may sleep. However, it is important that all sleeps have a | ||
49 | small fixed upper limit in time. In particular you must not call out to | ||
50 | user space and await results. | ||
51 | |||
52 | Hotplugging callbacks | ||
53 | ===================== | ||
54 | |||
55 | These callbacks are intended to associate and disassociate a driver with | ||
56 | an interface. A driver's bond to an interface is exclusive. | ||
57 | |||
58 | The probe() callback | ||
59 | -------------------- | ||
60 | |||
61 | int (*probe) (struct usb_interface *intf, | ||
62 | const struct usb_device_id *id); | ||
63 | |||
64 | Accept or decline an interface. If you accept the device return 0, | ||
65 | otherwise -ENODEV or -ENXIO. Other error codes should be used only if a | ||
66 | genuine error occurred during initialisation which prevented a driver | ||
67 | from accepting a device that would else have been accepted. | ||
68 | You are strongly encouraged to use usbcore'sfacility, | ||
69 | usb_set_intfdata(), to associate a data structure with an interface, so | ||
70 | that you know which internal state and identity you associate with a | ||
71 | particular interface. The device will not be suspended and you may do IO | ||
72 | to the interface you are called for and endpoint 0 of the device. Device | ||
73 | initialisation that doesn't take too long is a good idea here. | ||
74 | |||
75 | The disconnect() callback | ||
76 | ------------------------- | ||
77 | |||
78 | void (*disconnect) (struct usb_interface *intf); | ||
79 | |||
80 | This callback is a signal to break any connection with an interface. | ||
81 | You are not allowed any IO to a device after returning from this | ||
82 | callback. You also may not do any other operation that may interfere | ||
83 | with another driver bound the interface, eg. a power management | ||
84 | operation. | ||
85 | If you are called due to a physical disconnection, all your URBs will be | ||
86 | killed by usbcore. Note that in this case disconnect will be called some | ||
87 | time after the physical disconnection. Thus your driver must be prepared | ||
88 | to deal with failing IO even prior to the callback. | ||
89 | |||
90 | Device level callbacks | ||
91 | ====================== | ||
92 | |||
93 | pre_reset | ||
94 | --------- | ||
95 | |||
96 | int (*pre_reset)(struct usb_interface *intf); | ||
97 | |||
98 | Another driver or user space is triggering a reset on the device which | ||
99 | contains the interface passed as an argument. Cease IO and save any | ||
100 | device state you need to restore. | ||
101 | |||
102 | If you need to allocate memory here, use GFP_NOIO or GFP_ATOMIC, if you | ||
103 | are in atomic context. | ||
104 | |||
105 | post_reset | ||
106 | ---------- | ||
107 | |||
108 | int (*post_reset)(struct usb_interface *intf); | ||
109 | |||
110 | The reset has completed. Restore any saved device state and begin | ||
111 | using the device again. | ||
112 | |||
113 | If you need to allocate memory here, use GFP_NOIO or GFP_ATOMIC, if you | ||
114 | are in atomic context. | ||
115 | |||
116 | Call sequences | ||
117 | ============== | ||
118 | |||
119 | No callbacks other than probe will be invoked for an interface | ||
120 | that isn't bound to your driver. | ||
121 | |||
122 | Probe will never be called for an interface bound to a driver. | ||
123 | Hence following a successful probe, disconnect will be called | ||
124 | before there is another probe for the same interface. | ||
125 | |||
126 | Once your driver is bound to an interface, disconnect can be | ||
127 | called at any time except in between pre_reset and post_reset. | ||
128 | pre_reset is always followed by post_reset, even if the reset | ||
129 | failed or the device has been unplugged. | ||
130 | |||
131 | suspend is always followed by one of: resume, reset_resume, or | ||
132 | disconnect. | ||