About Kernel Documentation Linux Kernel Contact Linux Resources Linux Blog

Documentation / usb / callbacks.txt




Custom Search

Based on kernel version 3.15.4. Page generated on 2014-07-07 09:04 EST.

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's facility,
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	A driver or user space is triggering a reset on the device which
99	contains the interface passed as an argument. Cease IO, wait for all
100	outstanding URBs to complete, and save any device state you need to
101	restore.  No more URBs may be submitted until the post_reset method
102	is called.
103	
104	If you need to allocate memory here, use GFP_NOIO or GFP_ATOMIC, if you
105	are in atomic context.
106	
107	post_reset
108	----------
109	
110	int (*post_reset)(struct usb_interface *intf);
111	
112	The reset has completed.  Restore any saved device state and begin
113	using the device again.
114	
115	If you need to allocate memory here, use GFP_NOIO or GFP_ATOMIC, if you
116	are in atomic context.
117	
118	Call sequences
119	==============
120	
121	No callbacks other than probe will be invoked for an interface
122	that isn't bound to your driver.
123	
124	Probe will never be called for an interface bound to a driver.
125	Hence following a successful probe, disconnect will be called
126	before there is another probe for the same interface.
127	
128	Once your driver is bound to an interface, disconnect can be
129	called at any time except in between pre_reset and post_reset.
130	pre_reset is always followed by post_reset, even if the reset
131	failed or the device has been unplugged.
132	
133	suspend is always followed by one of: resume, reset_resume, or
134	disconnect.
Hide Line Numbers
About Kernel Documentation Linux Kernel Contact Linux Resources Linux Blog

Information is copyright its respective author. All material is available from the Linux Kernel Source distributed under a GPL License. This page is provided as a free service by mjmwired.net.