CIS, weren't actually used anywhere (other than the generic PC Card
code when certain variables are defined). They aren't used in NetBSD
either. Make things simpler by removing them. Change PLANEX_2 to
PLANEX and tweak wi and owi to use that instead. The PLANEX id seems
to actually be pci ID assigned to planex, not its pcmcia id. Ooops.
I don't know if this is a reporting error from where this entry came
from, or if it is a mistake on PLANEX's part. I suspect the latter,
as ACTIONTEC and NEWMEDIA made the same mistake (although new media
may be because it uses an advansys chip inside). Make a note of this
in the file. The 0xc entires may be JEITA assigned, so note that as
well.
# This leaves just 3 entries that are totally unknown: airvast, archos
# and edimax although the arivast number is the same assigned to
# avertec in usb...
thought. I'm unsure why I thought this was the case, but it
definitely isn't for this card. If another card with the other ID
makes an appearance, then we'll add a second entry for it.
# With this change my Olicom OC2220 is now working again, since I make
# this commit with that device. :-)
versions of the Racore PC Card Ethernet card. Rearrange to reflect
this reality. This ejects IODATA from 0x1bf, which belongs to Racore.
Thanks to Wilko for providing me with a dumpcis for the DEPCM card.
Also, added Nextcom Nexthawk card from NetBSD
NetBSD went this route a while ago. FreeBSD originally tried this to
cope with multifunction cards. However, it turns out that we're
better off not worrying about the function number, and instead worry
about the function type for the function. This has worked well in
NetBSD, and all FreeBSD's relevant drivers have been converted.
# I'll rework the macros that specify them shortly, as soon as I can
# come up with a good, compatible way to deal...
as type 0, rather than the usualy type 4. Assume that this format is
from an old standard and go with it. The Fujitsu FMV-186A and Silicom
Ethernet cards I have both have tuples with this format, and they are
both pretty old cards.
# if somebody knows for sure, please let me know.
for the vast majority of our cards. However, they are critically
needed to distinguish different fe based PC Cards (the FMV-182 from
the 182A) which need to be treated differently (the ethernet address
is loaded not from the standard CIS-based ethernet tuples, but from
differing locations in attribute space based on the version string in
CIS3. This should have no impact for other users of this function.
card, and works with that driver. However, Eagle is using Fujitsu's
vendor number and a product code of 4, which seems a little odd.
Still, there's no conflicts...
prodstr may be NULL when fetched. For the default device description,
guard against this and return the numeric IDs instead when this
happens. For the matching routines, and consider NULL to not match
those entries that aren't NULL w/o calling strcmp.
Early patches by: Anders Hanssen
(1) Align to 64k for the CIS. Some cards don't like it when we aren't
aligned to a 64k boundary. I can't find anything in the standard
that requires this, but I have 1/2 dozen cards that won't work at
all unless I enable this.
(2) Sleep 1s before scanning the CIS. This may be a nop, but has little
harm.
(3) The CIS can be up to 4k in some weird, odd-ball edge cases. Since we
have limiters for when that's not the case, it does no harm to increase
it to 4k.
#1 was submitted, in a different form, by Carlos Velasco.
Xircom had an unfortunate habit of re-using PCMCIA IDs for quite different
cards - the xe driver knows about this and uses the first byte of 'extra'
PCMCIA ID info to identify cards with ambiguous IDs.
Reviewed by: imp (mentor)
is really EtherExpress or EEPro or what, but it does appear in a
couple of ethernet cards that have appeared recently on ebay. Silicom
appears to make these cards, and they have the 82595TX chipset in
them, and sometimes uarts. The ex driver needs some work to support
these cards, but I thought I'd get the device into pccarddevs.
o Fix MFC cards. We were bogusly setting CCR_IOBASE[01] and CCR_IOLIMIT.
now when we activate the resource, we adjust these for MFC cards, per the
spec.
o Change type of pf_mfc_* to be bus_addr_t, which is more correct than
long.
This makes my 3C362D/3C363D and 3CXEM556 cards work! Woo Hoo!
o minor optimization of cardbus_cis processing. Remove a bunch of generic
entries that are handled by generic.
o no longer need the card_get_type stuff.
routine of its own, and allows us to move the indentation back two
layers making the code more readable.
delete a prototype that should have been killed years ago in pccardvar.h.
# adding quirks here is way harder than it needs to be. :-(
1.186: onoe; Sony's PEGA-WL110 CF WLAN (which strangely has fujitsu's
vendor id)
1.185: ichiro; Quatech Inc, PCMCIA Enhanced Parallel Port Card
Also:
o update $NetBSD$
o minor tweaks to FUJITSU. We've tried to keep the CIS only entries seprate
from vendor id/product id.
such a card is ejected, we'd panic. Instead, just ignore it.
I should also add a sanity check in the FUNCID code as well, but this
isn't wrong since the check is cheap and happens infrequently.
compatibility routine, go ahead and accept that as 'success'. A
properly written compatible driver should return < 0 for both the
compat match and compat probe routines, so this will wind up doing the
right thing.
vendors that list the vendor ID in the proper byte order. The second
section is for vendors that get it backwards. The third is for what
appear to be 'random' ones (although 0xcxxx appears to be coherent
enough that maybe somebody else is assigning those numbers).
are all bogus, and the cards that don't decode things quite right
often have hundreds of them. This will fix starvation of small dmesg
buffers and allow better debugging to happen. I thought about adding
an override, but there is such a thing as too many knobs. :-)
to what is in NetBSD. I have a few cards that tickles this bug, and
this just keeps us from panicing. It doesn't actually fix the problem
(that will happen once I figure out why some cards hate the address
their CIS is mapped to high memory).
has the same product id, but different vendor id. It also appears
that the MELCO's id should be 0x18a instead of 0x8a01. Fix this.
Submitted by: Shizuka Kudo-san
how we registered pccard_intr, it is MPSAFE. However, since we
register the pccard_intr handler with the flags of the ISR we call,
that is the gating factor. We need do nothing specific here.
Prompted by: seeing pccard_intr in a panic.
1.182; christos
A cardflash NE2000 from Michael Francini
1.181; perry
support Corega PCCL-11 -- from Christopher SEKIYA in PR 20932
1.180; ichiro
add product TOSHIBA PA2673U CBIDE2 (IODATA OEM)
1.179; kanaoka
Add SMC 8041TX 10/100 Ether PC Card.
0 in a problem that is being discussed. That means that the test for
product != 0 may cause problems. Looking at pccarddevs (which i
should have done earlier) we see:
product BONDWELL B236 0x0000 Game Card Joystick
product CONTEC CNETPC 0x0000 Contec C-NET(PC)C
product IBM MICRODRIVE 0x0000 IBM Microdrive
product RAYTHEON WLAN 0x0000 WLAN Adapter
product SOCKET EA_ETHER 0x0000 Socket Communications EA
product TDK LAK_CD011WL 0x0000 TDK LAK-CD011WL
so use only the vendor field for the end sentinel.
