Sophie

Sophie

distrib > CentOS > 6 > i386 > by-pkgid > 2c51d8eb79f8810ada971ee8c30ce1e5 > files > 3874

kernel-doc-2.6.32-71.14.1.el6.noarch.rpm

<?xml version="1.0" encoding="ANSI_X3.4-1968" standalone="no"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=ANSI_X3.4-1968" /><title>usb_match_id</title><meta name="generator" content="DocBook XSL Stylesheets V1.75.2" /><link rel="home" href="index.html" title="The Linux-USB Host Side API" /><link rel="up" href="ch05.html" title="Chapter&#160;5.&#160;USB Core APIs" /><link rel="prev" href="re76.html" title="usb_driver_release_interface" /><link rel="next" href="re78.html" title="usb_register_device_driver" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center"><span>usb_match_id</span></th></tr><tr><td width="20%" align="left"><a accesskey="p" href="re76.html">Prev</a>&#160;</td><th width="60%" align="center">Chapter&#160;5.&#160;USB Core APIs</th><td width="20%" align="right">&#160;<a accesskey="n" href="re78.html">Next</a></td></tr></table><hr /></div><div class="refentry" title="usb_match_id"><a id="API-usb-match-id"></a><div class="titlepage"></div><div class="refnamediv"><h2>Name</h2><p>usb_match_id &#8212; 
     find first usb_device_id matching device or interface
 </p></div><div class="refsynopsisdiv" title="Synopsis"><h2>Synopsis</h2><div class="funcsynopsis"><table border="0" summary="Function synopsis" cellspacing="0" cellpadding="0" class="funcprototype-table"><tr><td><code class="funcdef">const struct usb_device_id * <b class="fsfunc">usb_match_id </b>(</code></td><td>struct usb_interface * <var class="pdparam">interface</var>, </td></tr><tr><td>&#160;</td><td>const struct usb_device_id * <var class="pdparam">id</var><code>)</code>;</td></tr></table><div class="funcprototype-spacer">&#160;</div></div></div><div class="refsect1" title="Arguments"><a id="id2749574"></a><h2>Arguments</h2><div class="variablelist"><dl><dt><span class="term"><em class="parameter"><code>interface</code></em></span></dt><dd><p>
     the interface of interest
    </p></dd><dt><span class="term"><em class="parameter"><code>id</code></em></span></dt><dd><p>
     array of usb_device_id structures, terminated by zero entry
    </p></dd></dl></div></div><div class="refsect1" title="Description"><a id="id2749618"></a><h2>Description</h2><p>
   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.
</p></div><div class="refsect1" title="What Matches"><a id="id2749635"></a><h2>What Matches</h2><p>
   </p><p>

   The <span class="quote">&#8220;<span class="quote">match_flags</span>&#8221;</span> 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.
   </p><p>

   <span class="quote">&#8220;<span class="quote">driver_info</span>&#8221;</span> is normally used only by device drivers,
   but you can create a wildcard <span class="quote">&#8220;<span class="quote">matches anything</span>&#8221;</span> usb_device_id
   as a driver's <span class="quote">&#8220;<span class="quote">modules.usbmap</span>&#8221;</span> entry if you provide an id with
   only a nonzero <span class="quote">&#8220;<span class="quote">driver_info</span>&#8221;</span> field.  If you do this, the USB device
   driver's <code class="function">probe</code> routine should use additional intelligence to
   decide whether to bind to the specified interface.
</p></div><div class="refsect1" title="What Makes Good usb_device_id Tables"><a id="id2749680"></a><h2>What Makes Good usb_device_id Tables</h2><p>
   </p><p>

   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.
   </p><p>

   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.
   </p><p>

   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.
   </p><p>

   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).
   </p><p>

   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.)
   </p><p>

   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.
</p></div></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="re76.html">Prev</a>&#160;</td><td width="20%" align="center"><a accesskey="u" href="ch05.html">Up</a></td><td width="40%" align="right">&#160;<a accesskey="n" href="re78.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top"><span>usb_driver_release_interface</span>&#160;</td><td width="20%" align="center"><a accesskey="h" href="index.html">Home</a></td><td width="40%" align="right" valign="top">&#160;<span>usb_register_device_driver</span></td></tr></table></div></body></html>