functions taking a pcmcia* device structure.
XXX This is a method of last resort for dealing with stupid/insane cards that
we need to probe harder before we can choose a config entry. It should not be
used by most drivers.
work by:
* adding another product to the table,
* checking the function type (to reject the serial port),
* trying harder to find the MAC address in the CIS strings (it may occur in
one of two different places).
Also, PCMCIA_STR_* elimination.
* The DEPCM-XX cards don't need to be recognized by OUI or string -- they
work just fine with the IO-DATA PC-LAT/E attachment, and are probable OEM.
So, remove the DEPCM case.
* PCMCIA_STR_* elimination.
* The Megahertz EM3336 is not always an X-Jack device, so take the "XJ" out
of the product number.
* Change PCMCIA_CIS_* values that are empty to PCMCIA_CIS_INVALID.
* Use wildcard OUIs in a few more places.
* Steal a method for differentiating the AX88[17]90 from the Linux driver.
* Remove the ZoNet card entry; it's now a duplicate of the Compex entry.
1) Remove all the PCMCIA_STR_* values, and instead print the actual CIS
info. This is infinitely more helpful.
2) For some of the OEM cards, collapse multiple table entries into one
entry that doesn't compare the OUI.
It's a start.
XXX
The way this table is done is kind of dumb. There's really every little point
in matching anything beyond vendor/product IDs in most cases, unless we
specifically need to do some hackery to find the MAC address. In many cases 4
or 5 manufacturers well have the same vendor/product IDs, but different OUIs
and possibly different strings. In these cases, we rarely need to look at the
OUI or the strings to DTRT.
mycroft