usb_driver_claim_interface(9) [centos man page]

USB_DRIVER_CLAIM_INT(9) 					   USB Core APIs					   USB_DRIVER_CLAIM_INT(9)

NAME

       usb_driver_claim_interface - bind a driver to an interface

SYNOPSIS

       int usb_driver_claim_interface(struct usb_driver * driver, struct usb_interface * iface, void * priv);

ARGUMENTS

       driver
	   the driver to be bound

       iface
	   the interface to which it will be bound; must be in the usb device's active configuration

       priv
	   driver data associated with that interface

DESCRIPTION

       This is used by usb device drivers that need to claim more than one interface on a device when probing (audio and acm are current
       examples). No device driver should directly modify internal usb_interface or usb_device structure members.

       Few drivers should need to use this routine, since the most natural way to bind to an interface is to return the private data from the
       driver's probe method.

       Callers must own the device lock, so driver probe entries don't need extra locking, but other call contexts may need to explicitly claim
       that lock.

RETURN

       0 on success.

COPYRIGHT

Kernel Hackers Manual 3.10					     June 2014						   USB_DRIVER_CLAIM_INT(9)

USB_QUEUE_RESET_DEVI(9) 					   USB Core APIs					   USB_QUEUE_RESET_DEVI(9)

NAME

       usb_queue_reset_device - Reset a USB device from an atomic context

SYNOPSIS

       void usb_queue_reset_device(struct usb_interface * iface);

ARGUMENTS

       iface
	   USB interface belonging to the device to reset

DESCRIPTION

       This function can be used to reset a USB device from an atomic context, where usb_reset_device won't work (as it blocks).

       Doing a reset via this method is functionally equivalent to calling usb_reset_device, except for the fact that it is delayed to a
       workqueue. This means that any drivers bound to other interfaces might be unbound, as well as users from usbfs in user space.

CORNER CASES

       - Scheduling two resets at the same time from two different drivers attached to two different interfaces of the same device is possible;
       depending on how the driver attached to each interface handles ->pre_reset, the second reset might happen or not.

       - If a driver is unbound and it had a pending reset, the reset will be cancelled.

       - This function can be called during .probe or .disconnect times. On return from .disconnect, any pending resets will be cancelled.

       There is no no need to lock/unlock the reset_ws as schedule_work does its own.

NOTE

       We don't do any reference count tracking because it is not needed. The lifecycle of the work_struct is tied to the usb_interface. Before
       destroying the interface we cancel the work_struct, so the fact that work_struct is queued and or running means the interface (and thus,
       the device) exist and are referenced.

COPYRIGHT

Kernel Hackers Manual 2.6.					     July 2010						   USB_QUEUE_RESET_DEVI(9)