USB core callbacks

What callbacks will usbcore do?

Usbcore will call into a driver through callbacks defined in the driverstructure and through the completion handler of URBs a driver submits.Only the former are in the scope of this document. These two kinds ofcallbacks are completely independent of each other. Information on thecompletion callback can be found inUSB Request Block (URB).

The callbacks defined in the driver structure are:

  1. Hotplugging callbacks:
  • @probe:
    Called to see if the driver is willing to manage a particularinterface on a device.
  • @disconnect:
    Called when the interface is no longer accessible, usuallybecause its device has been (or is being) disconnected or thedriver module is being unloaded.
  1. Odd backdoor through usbfs:
  • @ioctl:
    Used for drivers that want to talk to userspace throughthe “usbfs” filesystem. This lets devices provide ways toexpose information to user space regardless of where theydo (or don’t) show up otherwise in the filesystem.
  1. 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 insteadof being resumed.
  1. 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 goodreason. Sysfs is preferred these days. The PM callbacks are coveredseparately inPower Management for USB.

Calling conventions

All callbacks are mutually exclusive. There’s no need for lockingagainst other USB callbacks. All callbacks are called from a taskcontext. You may sleep. However, it is important that all sleeps have asmall fixed upper limit in time. In particular you must not call out touser space and await results.

Hotplugging callbacks

These callbacks are intended to associate and disassociate a driver withan 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 agenuine error occurred during initialisation which prevented a driverfrom 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, sothat you know which internal state and identity you associate with aparticular interface. The device will not be suspended and you may do IOto the interface you are called for and endpoint 0 of the device. Deviceinitialisation 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 thiscallback. You also may not do any other operation that may interferewith another driver bound the interface, eg. a power managementoperation.If you are called due to a physical disconnection, all your URBs will bekilled by usbcore. Note that in this case disconnect will be called sometime after the physical disconnection. Thus your driver must be preparedto 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 whichcontains the interface passed as an argument. Cease IO, wait for alloutstanding URBs to complete, and save any device state you need torestore. No more URBs may be submitted until the post_reset methodis called.

If you need to allocate memory here, use GFP_NOIO or GFP_ATOMIC, if youare in atomic context.

post_reset

int (*post_reset)(struct usb_interface *intf);

The reset has completed. Restore any saved device state and beginusing the device again.

If you need to allocate memory here, use GFP_NOIO or GFP_ATOMIC, if youare in atomic context.

Call sequences

No callbacks other than probe will be invoked for an interfacethat 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 calledbefore there is another probe for the same interface.

Once your driver is bound to an interface, disconnect can becalled at any time except in between pre_reset and post_reset.pre_reset is always followed by post_reset, even if the resetfailed or the device has been unplugged.

suspend is always followed by one of: resume, reset_resume, ordisconnect.