123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135 |
- What callbacks will usbcore do?
- ===============================
- Usbcore will call into a driver through callbacks defined in the driver
- structure and through the completion handler of URBs a driver submits.
- Only the former are in the scope of this document. These two kinds of
- callbacks are completely independent of each other. Information on the
- completion callback can be found in Documentation/usb/URB.txt.
- The callbacks defined in the driver structure are:
- 1. Hotplugging callbacks:
- * @probe: Called to see if the driver is willing to manage a particular
- * interface on a device.
- * @disconnect: Called when the interface is no longer accessible, usually
- * because its device has been (or is being) disconnected or the
- * driver module is being unloaded.
- 2. Odd backdoor through usbfs:
- * @ioctl: Used for drivers that want to talk to userspace through
- * the "usbfs" filesystem. This lets devices provide ways to
- * expose information to user space regardless of where they
- * do (or don't) show up otherwise in the filesystem.
- 3. Power management (PM) callbacks:
- * @suspend: Called when the device is going to be suspended.
- * @resume: Called when the device is being resumed.
- * @reset_resume: Called when the suspended device has been reset instead
- * of being resumed.
- 4. Device level operations:
- * @pre_reset: Called when the device is about to be reset.
- * @post_reset: Called after the device has been reset
- The ioctl interface (2) should be used only if you have a very good
- reason. Sysfs is preferred these days. The PM callbacks are covered
- separately in Documentation/usb/power-management.txt.
- Calling conventions
- ===================
- All callbacks are mutually exclusive. There's no need for locking
- against other USB callbacks. All callbacks are called from a task
- context. You may sleep. However, it is important that all sleeps have a
- small fixed upper limit in time. In particular you must not call out to
- user space and await results.
- Hotplugging callbacks
- =====================
- These callbacks are intended to associate and disassociate a driver with
- an interface. A driver's bond to an interface is exclusive.
- The probe() callback
- --------------------
- int (*probe) (struct usb_interface *intf,
- const struct usb_device_id *id);
- Accept or decline an interface. If you accept the device return 0,
- otherwise -ENODEV or -ENXIO. Other error codes should be used only if a
- genuine error occurred during initialisation which prevented a driver
- from accepting a device that would else have been accepted.
- You are strongly encouraged to use usbcore's facility,
- usb_set_intfdata(), to associate a data structure with an interface, so
- that you know which internal state and identity you associate with a
- particular interface. The device will not be suspended and you may do IO
- to the interface you are called for and endpoint 0 of the device. Device
- initialisation that doesn't take too long is a good idea here.
- The disconnect() callback
- -------------------------
- void (*disconnect) (struct usb_interface *intf);
- This callback is a signal to break any connection with an interface.
- You are not allowed any IO to a device after returning from this
- callback. You also may not do any other operation that may interfere
- with another driver bound the interface, eg. a power management
- operation.
- If you are called due to a physical disconnection, all your URBs will be
- killed by usbcore. Note that in this case disconnect will be called some
- time after the physical disconnection. Thus your driver must be prepared
- to deal with failing IO even prior to the callback.
- Device level callbacks
- ======================
- pre_reset
- ---------
- int (*pre_reset)(struct usb_interface *intf);
- A driver or user space is triggering a reset on the device which
- contains the interface passed as an argument. Cease IO, wait for all
- outstanding URBs to complete, and save any device state you need to
- restore. No more URBs may be submitted until the post_reset method
- is called.
- If you need to allocate memory here, use GFP_NOIO or GFP_ATOMIC, if you
- are in atomic context.
- post_reset
- ----------
- int (*post_reset)(struct usb_interface *intf);
- The reset has completed. Restore any saved device state and begin
- using the device again.
- If you need to allocate memory here, use GFP_NOIO or GFP_ATOMIC, if you
- are in atomic context.
- Call sequences
- ==============
- No callbacks other than probe will be invoked for an interface
- that isn't bound to your driver.
- Probe will never be called for an interface bound to a driver.
- Hence following a successful probe, disconnect will be called
- before there is another probe for the same interface.
- Once your driver is bound to an interface, disconnect can be
- called at any time except in between pre_reset and post_reset.
- pre_reset is always followed by post_reset, even if the reset
- failed or the device has been unplugged.
- suspend is always followed by one of: resume, reset_resume, or
- disconnect.
|