scan the CIS for interesting tuples. 95% of what can be obtained from
the CIS is harvested by the pccard layer and presented to the user in
standard function calls. However, there are special needs at times
where the standard stuff doesn't suffice. This is for those special
cases.
CARD_SCAN_CIS(device_get_parent(dev), function, argp)
scans the CIS of the card, passing each tuple to function with
the tuple and argp as its arguments. Returning 0 continues the scan,
while returning 1 terminates the scan. The value of the last
invocation of function is returned from this function.
int (*pccard_scan_t)(struct pccard_tuple *tuple, void *argp)
function called for each tuple. Elements of the CIS tuple can be
read with pccard_tuple_read_{1,2,3,4,n}(). You are reading
the actual tuple memory each time, in case your card has
registers in the CIS.
# I suppose these things should be documented in pccard(4) or something like
# that.
# I plan on unifying cardbus CIS support in a similar way.
Approved by: re (scottl)
Provide a backwards compatible way to have the extra macro by defining
PCCARD_API_LEVEL 5 before including pccarddevs for driver writers that
want/need to have the same driver on 5 and 6 with pccard attachments.
Approved by: re (dwhite)
problems here, it became clear we were being too complex.
o Don't keep track of resources in two places
o Use resource_list_purge instead of rolling our own
o Just reassign the ownership of the resource, rather than freeing it
and reallocating it.
o Fix compile problems when sizeof(u_long) != sizeof(int)
this code:
o rid is stored in the resource, so don't bother keeping track of it here.
o Implement memory space
o Don't try to activate 'memory card' CFEs. This is type memory, as opposed
to the memory resource.
resource_list_find. Check to make sure that rle is not NULL and panic
if it is (but it appears that resource_list_add already panics, so I'm
not entirely sure it is necessary now).
Add a test to make sure we have a interrupt resource when we're
disabling it. This is also a cannot happen, but the extra care
shoudln't hurt.
Found by: Coventry tool via sam@
last in the list rather than first.
This makes the resouces print in the 4.x order rather than the 5.x order
(eg fdc0 at 0x3f0-0x3f5,0x3f7 is 4.x, but 0x3f7,0x3f0-0x3f5 is 5.x). This
also means that the pci code will once again print the resources in BAR
ascending order.
chipset. Add support for this card. Office Max has them on sale and
I was surprised that we didn't have it in our supported list when I
plugged it in...
are equal to PCCARD_TPCE_FS_MEMSPACE_NONE, memspace will be zero, so
testing for this case inside of the if statement results in dead code.
We'd fail to set a value to zero that's already zero (since it is
initialized to 0 indirectly) with this code being there. Well, except
in the very rare case that we have a card that has a defualt entry
that includes a memory space followed by one that has no memory space
(these are extremely rare, I don't recall ever having seen one :-).
Fix this by setting num_memspace to 0 in a more appropriate place.
Submitted by: Coverity Prevent analysis tool
with the latest changes. They actually have valid ROM data at location
0 of memory, just like a real NE-2000 ISA card. Use this data, if
the ROM passes a few basic tests, as an additional source for the MAC
address. Prefer the CIS over this source, but have it take precidence
over falling back to reading the attribtue memory.
o Minor cleanup of a few devices that we match on based on CIS string.
bridge between OLDCARD and NEWCARD for drivers to inquire after the
function number (eg, 0, 1, 2). Nobody ever used it, so retire it
with honors. NEWCARD never implemented it, and the same information
can be obtained by the pccard_get_function_number().
MFC After: 3 days
same as the LINKSYS COMBO_ECARD (which also seems to be the same as
another linksys product that also has a modem, but I can't find that
one at the moment). Remove the PCM100, since it is now no longer
used.
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).
