The translation is temporarily closed for contributions due to maintenance, please come back later.
product ADDTRON AWP100 { "Addtron", "AWP-100&spWireless&spPCMCIA", "Version&sp01.02", NULL }
product ALLIEDTELESIS WR211PCM { "Allied&spTelesis&spK.K.", "WR211PCM", NULL, NULL } Allied Telesis WR211PCM
The familiar <literal>product</literal> keyword is followed by the vendor name and the card name, just as in the second section of the file. Here the format deviates from that used earlier. There is a {} grouping, followed by a number of strings. These strings correspond to the vendor, product, and extra information that is defined in a CIS_INFO tuple. These strings are filtered by the program that generates <filename>pccarddevs.h</filename> to replace &amp;sp with a real space. NULL strings mean that the corresponding part of the entry should be ignored. The example shown here contains a bad entry. It should not contain the version number unless that is critical for the operation of the card. Sometimes vendors will have many different versions of the card in the field that all work, in which case that information only makes it harder for someone with a similar card to use it with FreeBSD. Sometimes it is necessary when a vendor wishes to sell many different parts under the same brand due to market considerations (availability, price, and so forth). Then it can be critical to disambiguating the card in those rare cases where the vendor kept the same manufacturer/product pair. Regular expression matching is not available at this time.
static const struct pccard_product wi_pccard_products[] = {
{ NULL }

static int
device_t dev;
const struct pccard_product *pp;

if ((pp = pccard_product_lookup(dev, wi_pccard_products,
sizeof(wi_pccard_products[0]), NULL)) != NULL) {
if (pp-&gt;pp_name != NULL)
device_set_desc(dev, pp-&gt;pp_name);
return (0);
return (ENXIO);
Here we have a simple pccard probe routine that matches a few devices. As stated above, the name may vary (if it is not <function>foo_pccard_probe()</function> it will be <function>foo_pccard_match()</function>). The function <function>pccard_product_lookup()</function> is a generalized function that walks the table and returns a pointer to the first entry that it matches. Some drivers may use this mechanism to convey additional information about some cards to the rest of the driver, so there may be some variance in the table. The only requirement is that each row of the table must have a <function>struct</function> <varname remap="structname">pccard_product</varname> as the first element.
Looking at the table <varname remap="structname">wi_pccard_products</varname>, one notices that all the entries are of the form <function>PCMCIA_CARD(<replaceable>foo</replaceable>, <replaceable>bar</replaceable>, <replaceable>baz</replaceable>)</function>. The <replaceable>foo</replaceable> part is the manufacturer ID from <filename>pccarddevs</filename>. The <replaceable>bar</replaceable> part is the product ID. <replaceable>baz</replaceable> is the expected function number for this card. Many pccards can have multiple functions, and some way to disambiguate function 1 from function 0 is needed. You may see <literal>PCMCIA_CARD_D</literal>, which includes the device description from <filename>pccarddevs</filename>. You may also see <literal>PCMCIA_CARD2</literal> and <literal>PCMCIA_CARD2_D</literal> which are used when you need to match both CIS strings and manufacturer numbers, in the <quote>use the default description</quote> and <quote>take the description from pccarddevs</quote> flavors.
To add a new device, one must first obtain the identification information from the device. The easiest way to do this is to insert the device into a PC Card or CF slot and issue <command>devinfo -v</command>. Sample output:
cbb1 pnpinfo vendor=0x104c device=0xac51 subvendor=0x1265 subdevice=0x0300 class=0x060700 at slot=10 function=1
unknown pnpinfo manufacturer=0x026f product=0x030c cisvendor="BUFFALO" cisproduct="WLI2-CF-S11" function_type=6 at function=0
<literal>manufacturer</literal> and <literal>product</literal> are the numeric IDs for this product, while <literal>cisvendor</literal> and <literal>cisproduct</literal> are the product description strings from the CIS.
vendor BUFFALO 0x026f BUFFALO (Melco Corporation)
product BUFFALO WLI_PCM_S11 0x0305 BUFFALO AirStation 11Mbps WLAN
product BUFFALO LPC3_CLT 0x030a BUFFALO LPC3-CLT Ethernet Adapter
product BUFFALO WLI_CF_S11G 0x030b BUFFALO AirStation 11Mbps CF WLAN
To add the device, we can just add this entry to <filename>pccarddevs</filename>:
product BUFFALO WLI2_CF_S11G 0x030c BUFFALO AirStation ultra 802.11b CF
static const struct pccard_product wi_pccard_products[] = {
{ NULL }
Note that I have included a '<literal>+</literal>' in the line before the line that I added, but that is simply to highlight the line. Do not add it to the actual driver. Once you have added the line, you can recompile your kernel or module and test it. If the device is recognized and works, please submit a patch. If it does not work, please figure out what is needed to make it work and submit a patch. If the device is not recognized at all, you have done something wrong and should recheck each step.
If you are a FreeBSD src committer, and everything appears to be working, then you can commit the changes to the tree. However, there are some minor tricky things to be considered. <filename>pccarddevs</filename> must be committed to the tree first. Then <filename>pccarddevs.h</filename> must be regenerated and committed as a second step, ensuring that the right $FreeBSD$ tag is in the latter file. Finally, commit the additions to the driver.
Please do not send entries for new devices to the author directly. Instead, submit them as a PR and send the author the PR number for his records. This ensures that entries are not lost. When submitting a PR, it is unnecessary to include the <filename>pccardevs.h</filename> diffs in the patch, since those will be regenerated. It is necessary to include a description of the device, as well as the patches to the client driver. If you do not know the name, use OEM99 as the name, and the author will adjust OEM99 accordingly after investigation. Committers should not commit OEM99, but instead find the highest OEM entry and commit one more than that.
<year>1996</year> <holder>Addison-Wesley Publishing Company, Inc.</holder>
Addison-Wesley Publishing Company, Inc.
The Design and Implementation of the 4.4 BSD Operating System