Notes about PCMCIA in the 2.4 kernel
PCMCIA kernel driver support is now included in the 2.4 linux kernel
tree. While it shares most of the same code with the standalone
PCMCIA driver package, there are some important differences. The
kernel PCMCIA support is also still evolving. This README is up to
date as of the 2.4test7-pre* kernels.
The kernel PCMCIA support does not eliminate the need to install the
pcmcia-cs package. Kernel PCMCIA still requires the same user tools
(cardmgr, cardctl, /etc/pcmcia/* files).
To use the kernel PCMCIA drivers, configure the kernel with
CONFIG_PCMCIA ("CardBus support") enabled. In this case, "CardBus"
really refers to the type of host bridge supported: both 16-bit and
CardBus card support is included. The drivers can either be built
into the kernel or built as modules. For now, only PCI-to-CardBus
bridges are supported, so there are no options for choosing bridge
drivers. PCMCIA client driver options are listed in their regular
driver categories; thus, PCMCIA network drivers are in a submenu of
network drivers, and PCMCIA serial drivers are in a submenu of
character drivers.
The CardBus socket driver in the 2.4 tree is the "yenta_socket"
driver. In your PCMCIA startup options, this driver should be
specified in place of the old i82365 driver.
When compiling the standalone PCMCIA package, the Configure script
decides whether or not to build any kernel modules by looking at the
value of the CONFIG_PCMCIA option. If CONFIG_PCMCIA is enabled, then
no kernel components are built. If CONFIG_PCMCIA is disabled, then
all the modules will be built and installed. It is safe to compile
the user tools (cardmgr, cardctl, etc) in a PCMCIA package whose
version number differs from the PCMCIA version number in the kernel
source tree. The kernel PCMCIA header files take precedence over the
ones included in the PCMCIA package, if CONFIG_PCMCIA is enabled.
The following tables show the correspondence between PCMCIA client
driver names, and kernel configuration options.
Network drivers:
3c589_cs 3Com 3c589 CONFIG_PCMCIA_3C589
3c574_cs 3Com 3c574 CONFIG_PCMCIA_3C574
fmvj18x_cs Fujitsu FMV-J18x CONFIG_PCMCIA_FMVJ18X
pcnet_cs NE2000 compatible CONFIG_PCMCIA_PCNET
nmclan_cs New Media CONFIG_PCMCIA_NMCLAN
smc91c92_cs SMC 91Cxx CONFIG_PCMCIA_SMC91C92
xirc2ps_cs Xircom 16-bit CONFIG_PCMCIA_XIRC2PS
ibmtr_cs IBM PCMCIA tokenring CONFIG_PCMCIA_IBMTR
ray_cs Aviator/Raytheon 2.4MHz CONFIG_PCMCIA_RAYCS
netwave_cs Xircom Netwave AirSurfer CONFIG_PCMCIA_NETWAVE
wavelan_cs AT&T/Lucent Wavelan CONFIG_PCMCIA_WAVELAN
Character drivers:
serial_cs PCMCIA serial device CONFIG_PCMCIA_SERIAL_CS
serial_cb CardBus serial device CONFIG_PCMCIA_SERIAL_CB
SCSI low-level drivers:
aha152x_cs Adaptec AHA152X CONFIG_PCMCIA_AHA152X
qlogic_cs Qlogic CONFIG_PCMCIA_QLOGIC
fdomain_cs Future Domain CONFIG_PCMCIA_FDOMAIN
apa1480_cb Adaptec APA1480 CardBus CONFIG_PCMCIA_APA1480
The CardBus network drivers (3c575_cb, tulip_cb, epic_cb) have been
folded into the corresponding PCI drivers using the new hot plug PCI
interface. The tulip_cb driver has been partially merged into the
tulip driver ('DECchip Tulip (dc21x4x)', CONFIG_TULIP). Xircom
CardBus cards are supported by a separate driver ('Xircom Tulip-like
CardBus', CONFIG_PCMCIA_XIRTULIP). The 3c575_cb driver is merged into
the 3c59x driver ('3C590/3c900 series (592/595/597) "Vortex/Boomerang"
support', CONFIG_VORTEX). And the epic_cb driver has been folded into
the epic100 driver ('SMC EtherPower II', CONFIG_EPIC100).
Known problems and limitations:
o ISA-to-PCMCIA and PCI-to-PCMCIA bridges are not supported. The
bridge driver interface in 2.4 is significantly different, and the
tcic and i82365 drivers have not been ported to the new interface.
o Some of the less popular client drivers, like the memory card
drivers, have not been ported into the 2.4 driver tree yet.
o The yenta_socket driver does not have the /proc interface of the
i82365 driver, so the dump_exca and dump_cardbus tools do not work.
It actually has no debugging support at all.
o The kernel PCMCIA package cannot be configured to use PnP BIOS calls
for resource management. This will not be fixed, but this is rarely
a serious issue.
o There is a somewhat serious API issue with the new "PCI hot plug"
interface used by the new tulip and 3c59x drivers. It is unable to
pass device name information to cardmgr, so the PCMCIA configuration
scripts don't work. Fixing this properly is non-trivial, because
the new API is not intended to be tightly linked to the PCMCIA card
control interface at all. A substitute for that interface, but for
PCI hot plug, has not really been sketched out yet.
Answers to some common questions:
Q: Are these two versions of PCMCIA both going to continue with active
development?
A: The way I see things now, the kernel PCMCIA subsystem will probably
be too unstable for widespread deployment, at least in the early
days of 2.4. So the standalone package will probably be widely
used for some time yet. However, the kernel PCMCIA subsystem
should eventually stabilize and be the focus of new development.
So, I think development for the standalone kernel modules will
shift away from adding functionality, towards mainly bug fixes.
Q: Which should I use / which is better? The kernel PCMCIA, or the
standalone PCMCIA?
A: It really depends. The client drivers should generally behave the
same. Some of the internals of the kernel PCMCIA system are very
different and less mature than the standalone drivers. Some legacy
hardware is currently only supported by the standalone drivers. At
this point, I'd recommend using the kernel drivers if you have a
specific need or if you are interested in helping test and debug.
If you mainly just want something that works, then the standalone
subsystem is probably a better bet at the moment.
Q: What should I do as a driver developer?
A: Again it really depends. I will probably be really picky about
including significant new functionality in the standalone PCMCIA
package; I expect that the kernel PCMCIA package will stabilize and
take over perhaps in the 2.5 kernel timeframe. It might make the
most sense to develop contributed drivers for the standalone
package first because it is a stable platform; and then port to
2.4.
Q: I'm using the kernel PCMCIA subsystem but want to use a driver that
isn't included in the kernel yet. Why can't I compile that driver
from the standalone PCMCIA package?
A: The Makefiles are set up to discourage this, mainly to prevent
people from trying combinations that don't make sense. Things in
the "modules" directory of the standalone package will not work
with the kernel PCMCIA subsystem. However, you can build client
drivers by doing a "make" in either the "clients" or "wireless"
subdirectories.
Q: Who is maintaining the kernel PCMCIA subsystem?
A: I am not playing as central a role in maintaining the kernel
modules as I have with the standalone package. I have periodically
updated some of the core modules and client drivers with fixes from
the standalone package. Linus Torvalds wrote the yenta_socket
driver more or less from scratch and he has been maintaining that
bit. Jeff Garzik has been working on the hot plug PCI adaptations
for the tulip_cb, 3c575_cb, and epic_cb drivers.
|