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().
toshii