1What callbacks will usbcore do? 2=============================== 3 4Usbcore will call into a driver through callbacks defined in the driver 5structure and through the completion handler of URBs a driver submits. 6Only the former are in the scope of this document. These two kinds of 7callbacks are completely independent of each other. Information on the 8completion callback can be found in Documentation/usb/URB.txt. 9 10The callbacks defined in the driver structure are: 11 121. 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 202. 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 273. 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 344. 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 39The ioctl interface (2) should be used only if you have a very good 40reason. Sysfs is preferred these days. The PM callbacks are covered 41separately in Documentation/usb/power-management.txt. 42 43Calling conventions 44=================== 45 46All callbacks are mutually exclusive. There's no need for locking 47against other USB callbacks. All callbacks are called from a task 48context. You may sleep. However, it is important that all sleeps have a 49small fixed upper limit in time. In particular you must not call out to 50user space and await results. 51 52Hotplugging callbacks 53===================== 54 55These callbacks are intended to associate and disassociate a driver with 56an interface. A driver's bond to an interface is exclusive. 57 58The probe() callback 59-------------------- 60 61int (*probe) (struct usb_interface *intf, 62 const struct usb_device_id *id); 63 64Accept or decline an interface. If you accept the device return 0, 65otherwise -ENODEV or -ENXIO. Other error codes should be used only if a 66genuine error occurred during initialisation which prevented a driver 67from accepting a device that would else have been accepted. 68You are strongly encouraged to use usbcore's facility, 69usb_set_intfdata(), to associate a data structure with an interface, so 70that you know which internal state and identity you associate with a 71particular interface. The device will not be suspended and you may do IO 72to the interface you are called for and endpoint 0 of the device. Device 73initialisation that doesn't take too long is a good idea here. 74 75The disconnect() callback 76------------------------- 77 78void (*disconnect) (struct usb_interface *intf); 79 80This callback is a signal to break any connection with an interface. 81You are not allowed any IO to a device after returning from this 82callback. You also may not do any other operation that may interfere 83with another driver bound the interface, eg. a power management 84operation. 85If you are called due to a physical disconnection, all your URBs will be 86killed by usbcore. Note that in this case disconnect will be called some 87time after the physical disconnection. Thus your driver must be prepared 88to deal with failing IO even prior to the callback. 89 90Device level callbacks 91====================== 92 93pre_reset 94--------- 95 96int (*pre_reset)(struct usb_interface *intf); 97 98A driver or user space is triggering a reset on the device which 99contains the interface passed as an argument. Cease IO, wait for all 100outstanding URBs to complete, and save any device state you need to 101restore. No more URBs may be submitted until the post_reset method 102is called. 103 104If you need to allocate memory here, use GFP_NOIO or GFP_ATOMIC, if you 105are in atomic context. 106 107post_reset 108---------- 109 110int (*post_reset)(struct usb_interface *intf); 111 112The reset has completed. Restore any saved device state and begin 113using the device again. 114 115If you need to allocate memory here, use GFP_NOIO or GFP_ATOMIC, if you 116are in atomic context. 117 118Call sequences 119============== 120 121No callbacks other than probe will be invoked for an interface 122that isn't bound to your driver. 123 124Probe will never be called for an interface bound to a driver. 125Hence following a successful probe, disconnect will be called 126before there is another probe for the same interface. 127 128Once your driver is bound to an interface, disconnect can be 129called at any time except in between pre_reset and post_reset. 130pre_reset is always followed by post_reset, even if the reset 131failed or the device has been unplugged. 132 133suspend is always followed by one of: resume, reset_resume, or 134disconnect. 135