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)
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.
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...
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.
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
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.
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.
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.
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.
o Always release the resources on device detach.
o Attach resources the same with driver added as we do we do in the insert
case (maybe this should be a routine).
o signal the wakeup of the thread on resume instead of trying to force an
interrupt.
o Minor debug hacks.
o use 0xffffffff instead of -1 for uint32_t items.
o Don't complain when we're asked to detach no cards. This is normal.
o Eliminate the now worthless second parameter to card_detach_card.
o minor style(9)isms
Some of these patches may be from: iwasaki-san, jhb, iadowse
the card.
o Add comments about how we're doing the CIS activation.
o Add location and pnp info functions.
o Add better code to hopefully deal with ata cards better (and other drivers
that allocate resources that we didn't preallocate from the CIS). OLDCARD
used to allow it, but NEWCARD was pickier. I'm not 100% sure this works,
but it doesn't break anything.
reprobe code working. This bogusness was thrust upon me.
o Don't delete the device if no drivers attach. I had thrust this bogusness
upon others.
These two changes make kldload of a pccard driver work again.
In this installment, we learn that it is bad to access registers that
are only defined for mfc cards in the interrupt handler when we do not
in fact have a mfc card. For MFC cards, we'll only call the ISR if
the this card interrupted bit is set. For non mfc cards (which are
basically 90% of pccards in use), we always call the ISR and avoid
touching the suspect registers. We always pacify the bit in the MFC
case on the off chance that will help in the itnerrupt handler not
being registed.
Don't set the CCR_OPTION register when registering/deregistering
interrupts unless the card is a MFC card. This makes a lot of cards
work that didn't work before. These bits are only defined for MFC
cards.
Remove COOKIE_FOR_WARNER kludges that phk introduced.
Add more debug info.
Annoy the purists by committing two minor style nits at the same time.
Many thanks to phk. He tracked this problem down to what was screwing
things up, so fixing it became trivially easy once the problem was
understood.
