cards stopped working. Specifically the AVM B1 PCMCIA Card no longer
detected. Its CIS chain read back as all FF's. Putting the delay
back solves those problems. I've opted to put in a much shorter delay
because as far as I can tell, no delay is really needed here. We'll
see how well this works in practice.
Reduce the size of ed a little by removing some CIS based entries (others
likely can be removed too):
o The D-Link DFE-670TXD doesn't need its own entry based on strings.
o The Xircom CompactCard appears to be a TDK design, so list it there by ID
and remove the strings.
Increase the size of ed a little:
o Add support for the Addtron AE-660CT and Addtron AE-660. This is a very
generic NE-2000 clone (so generic that its CIS tags say NE-2000 generic
card!).
o Note that the first 255 locations are reserved for JEDEC Ids from
publication 106 (current revision Q, each one verified with
JEDEC and the PMCICA).
o Move ADAPTEC2 to the right section.
o Sort TOSHIBA2 numerically.
o Add Agere Hermes II and II.5 PC Cards (from zipit web page), TDK
GlobalNetworker 3410 (from dmesg for my card) and another alternate
PANASONIC KXLC0005_2 (from pcmcia-cs id lists).
problems we were having properly mapping the CIS attr space on some
cards. Those problems have been solved other ways, so this kludge is
no longer necessary. Remove it and have pccards come up a whole
second faster.
o Use pf more consistantly for pccard_function.
o Make sure we quote the strings properly (maybe this function belongs in
subr_bus.c)
o Tweak a comment to be more accurate after code changed.
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@
