count there is (for SCSI, adapt_refcnt) to 1 and call the appropriate
"delref" function afterwards to disable the controller. This is a bit
simpler.
In a couple of cases, just remove the state machine, because it wasn't
really necessary.
* Remove the "expected function" value. This was just causing problems with
multifunction cards. Differentiating the functions is better done by
checking the function type (which we now do in ep and sm).
* Add support for matching CIS strings. This necessitated changing the calling
pattern a little too.
Use this enhanced version rather than driver-specific versions that do the
same thing.
Also, remove the last vestiges of PCMCIA_STR_*.
XXX Note: This eliminates some register writes that were done in the "init"
routine during attach. If these are necessary, they need to do done somewhere
else, quite possibly the enable routine.
"While I'm here..."
All that grotesque code allegedly for the 88190 and 88790 is actually just
mapping the CCR and writing to it. So, enable the device normally and use
pcmcia_ccr_{read,write}() rather than doing this crap ourselves.
force it to 0 when a card is detached, possibly disabling the socket in the
process.
Add several new functions:
* pcmcia_config_alloc(pf, cfe)
Tries to allocate all the I/O and memory spaces in a config entry.
* pcmcia_config_free(pf)
Frees all the I/O and memory spaces for the active configuration.
* pcmcia_config_map(pf)
Maps all the allocated I/O and memory spaces for the active configuration.
* pcmcia_config_unmap(pf)
Unmaps all the allocated I/O and memory spaces for the active configuration.
And two higher-level functions:
* pcmcia_function_configure(pf, validator)
Tries to find a CIS config entry that it can allocate the spaces for. Each
entry is verified by calling the "validator" function -- which can also do
card- and driver-specific fixups. If successful, the regions are all mapped.
* pcmcia_function_unconfigure(pf)
Equivalent to calling both pcmcia_config_unmap() and pcmcia_config_free().
Most drivers are expected to use the latter two functions, which will greatly
reduce the amount of crufty code.
underlying implementation DTRT. This has the side effect of causing us to
ignore the INTR and INTRACK bits in the CCR -- but this seems for the best
anyway, since they are not reliably implemented. (I note that Linux doesn't
bother either.)
with the function enabled. If this happens, issue a warning. (This is only
really important for multifunction cards.)
This allows me to get rid of a bunch of extra code.
* Don't call handlers for functions that are not enabled.
* Always call the handler if the function doesn't support the STATUS register.
While I'm here, divide the CCR numbers by 2.
case (ne@pcmcia) where we were using these to create a subregion, it is better
handled by calling bus_space_subregion().
Now there is a 1:1 mapping between I/O spaces in the config table and windows
mapped in the function. Rework the multifunction mapping code to take
advantage of this by using both I/O base addresses if necessary.
* Don't splnet() in xi_init() -- the callers do that.
* Don't do the enable call in xi_init() -- it should be done only in a process
context so it can sleep.
* Call xi_start() at the end of xi_init() to restart output.
* If the interface is already up, we only need to call xi_set_address() to
change state on SIOCSIFFLAGS.
devices) and a "xi" backend.
My CE2 and CEM2 cards are now probed correctly. However, there are still
some problems with one model of the CE2, and the CEM2 doesn't seem to get
any modem interrupts.
While I'm at it, fix several bugs:
* The tuple scan for the MAC address was broken in multiple ways.
* xi_intr() did not deal well with a shared interrupt.
* We were setting the wrong page number to look at the receive status. (How
did this work???)
* Remove the xi_full_reset() from xi_reset(). Move the parts of
xi_full_reset() needed to undo the effect of xi_stop() into xi_init(). This
allows a stop/init pair to DTRT, and much quicker, as used by various
ioctl()s.
* Set the TRS register before reading the TSO register, as the Linux driver
does. While I'm at it, fix the name.
* Fix numerous problems with xi_set_address(). "Where do I begin?" There's a
chance that multicast works now, but I haven't tested it.
* Explicitly clear the MSR register, and also force SELECT_MII to 0 if we
didn't find any PHYs.
* Clean up some cruft that appears to be bogus.
Probably needs more work, but it's a start.
functions taking a pcmcia* device structure.
XXX This is a method of last resort for dealing with stupid/insane cards that
we need to probe harder before we can choose a config entry. It should not be
used by most drivers.
work by:
* adding another product to the table,
* checking the function type (to reject the serial port),
* trying harder to find the MAC address in the CIS strings (it may occur in
one of two different places).
Also, PCMCIA_STR_* elimination.
* The DEPCM-XX cards don't need to be recognized by OUI or string -- they
work just fine with the IO-DATA PC-LAT/E attachment, and are probable OEM.
So, remove the DEPCM case.
* PCMCIA_STR_* elimination.
* The Megahertz EM3336 is not always an X-Jack device, so take the "XJ" out
of the product number.
mycroft