160 lines · plain
1USB core callbacks2~~~~~~~~~~~~~~~~~~3 4What callbacks will usbcore do?5===============================6 7Usbcore will call into a driver through callbacks defined in the driver8structure and through the completion handler of URBs a driver submits.9Only the former are in the scope of this document. These two kinds of10callbacks are completely independent of each other. Information on the11completion callback can be found in :ref:`usb-urb`.12 13The callbacks defined in the driver structure are:14 151. Hotplugging callbacks:16 17 - @probe:18 Called to see if the driver is willing to manage a particular19 interface on a device.20 21 - @disconnect:22 Called when the interface is no longer accessible, usually23 because its device has been (or is being) disconnected or the24 driver module is being unloaded.25 262. Odd backdoor through usbfs:27 28 - @ioctl:29 Used for drivers that want to talk to userspace through30 the "usbfs" filesystem. This lets devices provide ways to31 expose information to user space regardless of where they32 do (or don't) show up otherwise in the filesystem.33 343. Power management (PM) callbacks:35 36 - @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 instead44 of being resumed.45 464. Device level operations:47 48 - @pre_reset:49 Called when the device is about to be reset.50 51 - @post_reset:52 Called after the device has been reset53 54The ioctl interface (2) should be used only if you have a very good55reason. Sysfs is preferred these days. The PM callbacks are covered56separately in :ref:`usb-power-management`.57 58Calling conventions59===================60 61All callbacks are mutually exclusive. There's no need for locking62against other USB callbacks. All callbacks are called from a task63context. You may sleep. However, it is important that all sleeps have a64small fixed upper limit in time. In particular you must not call out to65user space and await results.66 67Hotplugging callbacks68=====================69 70These callbacks are intended to associate and disassociate a driver with71an interface. A driver's bond to an interface is exclusive.72 73The probe() callback74--------------------75 76::77 78 int (*probe) (struct usb_interface *intf,79 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 a83genuine error occurred during initialisation which prevented a driver84from accepting a device that would else have been accepted.85You are strongly encouraged to use usbcore's facility,86usb_set_intfdata(), to associate a data structure with an interface, so87that you know which internal state and identity you associate with a88particular interface. The device will not be suspended and you may do IO89to the interface you are called for and endpoint 0 of the device. Device90initialisation that doesn't take too long is a good idea here.91 92The disconnect() callback93-------------------------94 95::96 97 void (*disconnect) (struct usb_interface *intf);98 99This callback is a signal to break any connection with an interface.100You are not allowed any IO to a device after returning from this101callback. You also may not do any other operation that may interfere102with another driver bound to the interface, eg. a power management103operation. Outstanding operations on the device must be completed or104aborted before this callback may return.105 106If you are called due to a physical disconnection, all your URBs will be107killed by usbcore. Note that in this case disconnect will be called some108time after the physical disconnection. Thus your driver must be prepared109to deal with failing IO even prior to the callback.110 111Device level callbacks112======================113 114pre_reset115---------116 117::118 119 int (*pre_reset)(struct usb_interface *intf);120 121A driver or user space is triggering a reset on the device which122contains the interface passed as an argument. Cease IO, wait for all123outstanding URBs to complete, and save any device state you need to124restore. No more URBs may be submitted until the post_reset method125is called.126 127If you need to allocate memory here, use GFP_NOIO or GFP_ATOMIC, if you128are in atomic context.129 130post_reset131----------132 133::134 135 int (*post_reset)(struct usb_interface *intf);136 137The reset has completed. Restore any saved device state and begin138using the device again.139 140If you need to allocate memory here, use GFP_NOIO or GFP_ATOMIC, if you141are in atomic context.142 143Call sequences144==============145 146No callbacks other than probe will be invoked for an interface147that isn't bound to your driver.148 149Probe will never be called for an interface bound to a driver.150Hence following a successful probe, disconnect will be called151before there is another probe for the same interface.152 153Once your driver is bound to an interface, disconnect can be154called at any time except in between pre_reset and post_reset.155pre_reset is always followed by post_reset, even if the reset156failed or the device has been unplugged.157 158suspend is always followed by one of: resume, reset_resume, or159disconnect.160