- centralize pcmcia function allocation and free'ing.
- free the cfe too, not just the pf in the multifunction card case.
- don't free pointers while walking the list, because free() will
fill the memory with deadbeef, thus killing list walking.
- implement SIMPLEQ_REMOVE(head, elm, type, field). whilst it's O(n),
this mirrors the functionality of SLIST_REMOVE() (the other
singly-linked list type) and FreeBSD's STAILQ_REMOVE()
- remove the unnecessary elm arg from SIMPLEQ_REMOVE_HEAD().
this mirrors the functionality of SLIST_REMOVE_HEAD() (the other
singly-linked list type) and FreeBSD's STAILQ_REMOVE_HEAD()
- remove notes about SIMPLEQ not supporting arbitrary element removal
- use SIMPLEQ_FOREACH() instead of home-grown for loops
- use SIMPLEQ_EMPTY() appropriately
- use SIMPLEQ_*() instead of accessing sqh_first,sqh_last,sqe_next directly
- reorder manual page; be consistent about how the types are listed
- other minor cleanups
of my Xircom RealPort Ethernet 10/100 + Modem (REM56G) work.
The modem part is still not usable (this would need some PCMCIA magic that
I don't know how to do; see my message to tech-kern on Oct 07).
Change to pcmcia_cis.c from OpenBSD.
I checked that this doesn't break a 3com 3C562D (ethernet+modem) which I
also have.
I have a weird PC-card-style appliance (I'm not sure I may call it a PC card)
whose ``CIS'' reads zeros forever, which caused kernel panic.
For your interest, it is a cooling fan to be inserted to a PC card slot.
places into the CIS reading code.
The card in question has IO8 only enabled in its CIS info and is apparently
not able to keep up with quick reads. It words fine in a pcmcia slot but
panics(!) the kernel in a TI 1250 cardbus slot. This may be a failure of
the pci cardbus code when initializing this bridge. When finding (and
fixing) that, we should back this change out.
The card I am testing with is not broken, I have multiple versions of it
(AVM Fritz! pcmcia ISDN card), all work fine on windows and all cause
us to panic because of bogus CIS info read.
XXX - panicing because of bogus CIS data is probably another error.
flame if presented with bad CIS data (e.g. because of a memory space
conflict):
* more sanity checking on LONGLINK_MFC CIS tuples (exact length check, sanity
check on size vs. size of array we allocated for them), to avoid various
missteps which could cause this code to complete trash the kernel stack.
* clear the entire contents of the state structure before processing, so
things like uninitted pointers will actually have a known value!
* be more careful with CISTPL_CFTABLE_ENTRY: check to see that the current
state's default_entry isn't NULL before dereferencing it.
both 16bit id values found in card CIS and special value to indicate
that no value found in CIS. Use that special value for the card that
doesn't have id values. Test that value in ne2000_match().
