usb_match_id(9) [centos man page]

USB_MATCH_ID(9) 						   USB Core APIs						   USB_MATCH_ID(9)

NAME

       usb_match_id - find first usb_device_id matching device or interface

SYNOPSIS

       const struct usb_device_id * usb_match_id(struct usb_interface * interface, const struct usb_device_id * id);

ARGUMENTS

       interface
	   the interface of interest

       id
	   array of usb_device_id structures, terminated by zero entry

DESCRIPTION

       usb_match_id searches an array of usb_device_id's and returns the first one matching the device or interface, or null. This is used when
       binding (or rebinding) a driver to an interface. Most USB device drivers will use this indirectly, through the usb core, but some layered
       driver frameworks use it directly. These device tables are exported with MODULE_DEVICE_TABLE, through modutils, to support the driver
       loading functionality of USB hotplugging.

RETURN

       The first matching usb_device_id, or NULL.

WHAT MATCHES

       The "match_flags" element in a usb_device_id controls which members are used. If the corresponding bit is set, the value in the device_id
       must match its corresponding member in the device or interface descriptor, or else the device_id does not match.

       "driver_info" is normally used only by device drivers, but you can create a wildcard "matches anything" usb_device_id as a driver's
       "modules.usbmap" entry if you provide an id with only a nonzero "driver_info" field. If you do this, the USB device driver's probe routine
       should use additional intelligence to decide whether to bind to the specified interface.

WHAT MAKES GOOD USB_DEVICE_ID TABLES
       The match algorithm is very simple, so that intelligence in driver selection must come from smart driver id records. Unless you have good
       reasons to use another selection policy, provide match elements only in related groups, and order match specifiers from specific to
       general. Use the macros provided for that purpose if you can.

       The most specific match specifiers use device descriptor data. These are commonly used with product-specific matches; the USB_DEVICE macro
       lets you provide vendor and product IDs, and you can also match against ranges of product revisions. These are widely used for devices with
       application or vendor specific bDeviceClass values.

       Matches based on device class/subclass/protocol specifications are slightly more general; use the USB_DEVICE_INFO macro, or its siblings.
       These are used with single-function devices where bDeviceClass doesn't specify that each interface has its own class.

       Matches based on interface class/subclass/protocol are the most general; they let drivers bind to any interface on a multiple-function
       device. Use the USB_INTERFACE_INFO macro, or its siblings, to match class-per-interface style devices (as recorded in bInterfaceClass).

       Note that an entry created by USB_INTERFACE_INFO won't match any interface if the device class is set to Vendor-Specific. This is
       deliberate; according to the USB spec the meanings of the interface class/subclass/protocol for these devices are also vendor-specific, and
       hence matching against a standard product class wouldn't work anyway. If you really want to use an interface-based match for such a device,
       create a match record that also specifies the vendor ID. (Unforunately there isn't a standard macro for creating records like this.)

       Within those groups, remember that not all combinations are meaningful. For example, don't give a product version range without vendor and
       product IDs; or specify a protocol without its associated class and subclass.

COPYRIGHT

Kernel Hackers Manual 3.10					     June 2014							   USB_MATCH_ID(9)

STRUCT 
USB_DRIVER(9)					  Host-Side Data Types and Macro				      STRUCT USB_DRIVER(9)

NAME

       struct_usb_driver - identifies USB interface driver to usbcore

SYNOPSIS

       struct usb_driver {
	 const char * name;
	 int (* probe) (struct usb_interface *intf,const struct usb_device_id *id);
	 void (* disconnect) (struct usb_interface *intf);
	 int (* ioctl) (struct usb_interface *intf, unsigned int code,void *buf);
	 int (* suspend) (struct usb_interface *intf, pm_message_t message);
	 int (* resume) (struct usb_interface *intf);
	 int (* reset_resume) (struct usb_interface *intf);
	 int (* pre_reset) (struct usb_interface *intf);
	 int (* post_reset) (struct usb_interface *intf);
	 const struct usb_device_id * id_table;
	 struct usb_dynids dynids;
	 struct usbdrv_wrap drvwrap;
	 unsigned int no_dynamic_id:1;
	 unsigned int supports_autosuspend:1;
	 unsigned int soft_unbind:1;
       };

MEMBERS

       name
	   The driver name should be unique among USB drivers, and should normally be the same as the module name.

       probe
	   Called to see if the driver is willing to manage a particular interface on a device. If it is, probe returns zero and uses
	   usb_set_intfdata to associate driver-specific data with the interface. It may also use usb_set_interface to specify the appropriate
	   altsetting. If unwilling to manage the interface, return -ENODEV, if genuine IO errors occured, an appropriate negative errno value.

       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.

       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.

       suspend
	   Called when the device is going to be suspended by the system.

       resume
	   Called when the device is being resumed by the system.

       reset_resume
	   Called when the suspended device has been reset instead of being resumed.

       pre_reset
	   Called by usb_reset_device when the device is about to be reset.

       post_reset
	   Called by usb_reset_device after the device has been reset

       id_table
	   USB drivers use ID table to support hotplugging. Export this with MODULE_DEVICE_TABLE(usb,...). This must be set or your driver's probe
	   function will never get called.

       dynids
	   used internally to hold the list of dynamically added device ids for this driver.

       drvwrap
	   Driver-model core structure wrapper.

       no_dynamic_id
	   if set to 1, the USB core will not allow dynamic ids to be added to this driver by preventing the sysfs file from being created.

       supports_autosuspend
	   if set to 0, the USB core will not allow autosuspend for interfaces bound to this driver.

       soft_unbind
	   if set to 1, the USB core will not kill URBs and disable endpoints before calling the driver's disconnect method.

DESCRIPTION

       USB interface drivers must provide a name, probe and disconnect methods, and an id_table. Other driver fields are optional.

       The id_table is used in hotplugging. It holds a set of descriptors, and specialized data may be associated with each entry. That table is
       used by both user and kernel mode hotplugging support.

       The probe and disconnect methods are called in a context where they can sleep, but they should avoid abusing the privilege. Most work to
       connect to a device should be done when the device is opened, and undone at the last close. The disconnect code needs to address
       concurrency issues with respect to open and close methods, as well as forcing all pending I/O requests to complete (by unlinking them as
       necessary, and blocking until the unlinks complete).

COPYRIGHT

Kernel Hackers Manual 2.6.					     July 2010						      STRUCT USB_DRIVER(9)