implement the hackish/stupid test for the AX88190 by just checking whether
the IOBASE is available in the CCR.
This is unspeakably wrong, but it leaves the code doing ~the same thing it
did before.
"While I'm here..."
All that grotesque code allegedly for the 88190 and 88790 is actually just
mapping the CCR and writing to it. So, enable the device normally and use
pcmcia_ccr_{read,write}() rather than doing this crap ourselves.
case (ne@pcmcia) where we were using these to create a subregion, it is better
handled by calling bus_space_subregion().
Now there is a 1:1 mapping between I/O spaces in the config table and windows
mapped in the function. Rework the multifunction mapping code to take
advantage of this by using both I/O base addresses if necessary.
* 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.
make the `unmatched vendor code' error message slightly more verbose to
make things easier next time this kind of issue arises.
Reported and tested by Pierre-Philipp Braun.
peter