blob: 2b80cf54bcc3118b956a8292aeae8e3af80acf7a [file] [log] [blame]
Mauro Carvalho Chehab3b38e4f2017-04-05 10:23:04 -03001USB core callbacks
2~~~~~~~~~~~~~~~~~~
3
Oliver Neukum08177e12008-04-16 15:46:37 +02004What callbacks will usbcore do?
5===============================
6
7Usbcore will call into a driver through callbacks defined in the driver
8structure and through the completion handler of URBs a driver submits.
9Only the former are in the scope of this document. These two kinds of
10callbacks are completely independent of each other. Information on the
Mauro Carvalho Chehabe1c3e6e2017-04-05 10:23:15 -030011completion callback can be found in :ref:`usb-urb`.
Oliver Neukum08177e12008-04-16 15:46:37 +020012
13The callbacks defined in the driver structure are:
14
151. Hotplugging callbacks:
16
Mauro Carvalho Chehab3b38e4f2017-04-05 10:23:04 -030017 - @probe:
18 Called to see if the driver is willing to manage a particular
19 interface on a device.
20
21 - @disconnect:
22 Called when the interface is no longer accessible, usually
23 because its device has been (or is being) disconnected or the
24 driver module is being unloaded.
Oliver Neukum08177e12008-04-16 15:46:37 +020025
262. Odd backdoor through usbfs:
27
Mauro Carvalho Chehab3b38e4f2017-04-05 10:23:04 -030028 - @ioctl:
29 Used for drivers that want to talk to userspace through
30 the "usbfs" filesystem. This lets devices provide ways to
31 expose information to user space regardless of where they
32 do (or don't) show up otherwise in the filesystem.
Oliver Neukum08177e12008-04-16 15:46:37 +020033
343. Power management (PM) callbacks:
35
Mauro Carvalho Chehab3b38e4f2017-04-05 10:23:04 -030036 - @suspend:
37 Called when the device is going to be suspended.
38
39 - @resume:
40 Called when the device is being resumed.
41
42 - @reset_resume:
43 Called when the suspended device has been reset instead
44 of being resumed.
Oliver Neukum08177e12008-04-16 15:46:37 +020045
464. Device level operations:
47
Mauro Carvalho Chehab3b38e4f2017-04-05 10:23:04 -030048 - @pre_reset:
49 Called when the device is about to be reset.
50
51 - @post_reset:
52 Called after the device has been reset
Oliver Neukum08177e12008-04-16 15:46:37 +020053
54The ioctl interface (2) should be used only if you have a very good
55reason. Sysfs is preferred these days. The PM callbacks are covered
Mauro Carvalho Chehabe1c3e6e2017-04-05 10:23:15 -030056separately in :ref:`usb-power-management`.
Oliver Neukum08177e12008-04-16 15:46:37 +020057
58Calling conventions
59===================
60
61All callbacks are mutually exclusive. There's no need for locking
62against other USB callbacks. All callbacks are called from a task
63context. You may sleep. However, it is important that all sleeps have a
64small fixed upper limit in time. In particular you must not call out to
65user space and await results.
66
67Hotplugging callbacks
68=====================
69
70These callbacks are intended to associate and disassociate a driver with
71an interface. A driver's bond to an interface is exclusive.
72
73The probe() callback
74--------------------
75
Mauro Carvalho Chehab3b38e4f2017-04-05 10:23:04 -030076::
77
78 int (*probe) (struct usb_interface *intf,
Oliver Neukum08177e12008-04-16 15:46:37 +020079 const struct usb_device_id *id);
80
81Accept or decline an interface. If you accept the device return 0,
82otherwise -ENODEV or -ENXIO. Other error codes should be used only if a
83genuine error occurred during initialisation which prevented a driver
84from accepting a device that would else have been accepted.
Németh Márton6e221682009-06-06 19:06:36 +020085You are strongly encouraged to use usbcore's facility,
Oliver Neukum08177e12008-04-16 15:46:37 +020086usb_set_intfdata(), to associate a data structure with an interface, so
87that you know which internal state and identity you associate with a
88particular interface. The device will not be suspended and you may do IO
89to the interface you are called for and endpoint 0 of the device. Device
90initialisation that doesn't take too long is a good idea here.
91
92The disconnect() callback
93-------------------------
94
Mauro Carvalho Chehab3b38e4f2017-04-05 10:23:04 -030095::
96
97 void (*disconnect) (struct usb_interface *intf);
Oliver Neukum08177e12008-04-16 15:46:37 +020098
99This callback is a signal to break any connection with an interface.
100You are not allowed any IO to a device after returning from this
101callback. You also may not do any other operation that may interfere
102with another driver bound the interface, eg. a power management
103operation.
104If you are called due to a physical disconnection, all your URBs will be
105killed by usbcore. Note that in this case disconnect will be called some
106time after the physical disconnection. Thus your driver must be prepared
107to deal with failing IO even prior to the callback.
108
109Device level callbacks
110======================
111
112pre_reset
113---------
114
Mauro Carvalho Chehab3b38e4f2017-04-05 10:23:04 -0300115::
116
117 int (*pre_reset)(struct usb_interface *intf);
Oliver Neukum08177e12008-04-16 15:46:37 +0200118
Alan Stern6498d9d2011-04-28 10:45:24 -0400119A driver or user space is triggering a reset on the device which
120contains the interface passed as an argument. Cease IO, wait for all
121outstanding URBs to complete, and save any device state you need to
122restore. No more URBs may be submitted until the post_reset method
123is called.
Oliver Neukum08177e12008-04-16 15:46:37 +0200124
125If you need to allocate memory here, use GFP_NOIO or GFP_ATOMIC, if you
126are in atomic context.
127
128post_reset
129----------
130
Mauro Carvalho Chehab3b38e4f2017-04-05 10:23:04 -0300131::
132
133 int (*post_reset)(struct usb_interface *intf);
Oliver Neukum08177e12008-04-16 15:46:37 +0200134
135The reset has completed. Restore any saved device state and begin
136using the device again.
137
138If you need to allocate memory here, use GFP_NOIO or GFP_ATOMIC, if you
139are in atomic context.
140
141Call sequences
142==============
143
144No callbacks other than probe will be invoked for an interface
145that isn't bound to your driver.
146
147Probe will never be called for an interface bound to a driver.
148Hence following a successful probe, disconnect will be called
149before there is another probe for the same interface.
150
151Once your driver is bound to an interface, disconnect can be
152called at any time except in between pre_reset and post_reset.
153pre_reset is always followed by post_reset, even if the reset
154failed or the device has been unplugged.
155
156suspend is always followed by one of: resume, reset_resume, or
157disconnect.