
		Notes about PCMCIA in the 2.4 kernel

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 in your kernel configuration.  If
CONFIG_PCMCIA is enabled, then by default, no driver 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
  axnet_cs     Asix AX88190 chipset      CONFIG_PCMCIA_AXNET
  fmvj18x_cs   Fujitsu FMV-J18x          CONFIG_PCMCIA_FMVJ18X
  nmclan_cs    New Media                 CONFIG_PCMCIA_NMCLAN
  pcnet_cs     NE2000 compatible         CONFIG_PCMCIA_PCNET
  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
  orinoco_cs   Hermes chipset 802.11     CONFIG_PCMCIA_HERMES
  wavelan_cs   AT&T/Lucent Wavelan       CONFIG_PCMCIA_WAVELAN

Character drivers:

  serial_cs    PCMCIA serial device      CONFIG_PCMCIA_SERIAL_CS

SCSI low-level drivers:

  aha152x_cs   Adaptec AHA152X           CONFIG_PCMCIA_AHA152X
  qlogic_cs    Qlogic                    CONFIG_PCMCIA_QLOGIC
  fdomain_cs   Future Domain             CONFIG_PCMCIA_FDOMAIN

Other drivers:
  ide-cs       ATA/IDE devices           CONFIG_BLK_DEV_IDECS

All CardBus drivers have been folded into their corresponding regular
PCI drivers using the new "hot plug PCI" interface.  Here is a mapping
from old CardBus drivers to new hot plug drivers:

  3c575_cb    3c59x    3c59x/3c90x/3x575 series   CONFIG_VORTEX
  tulip_cb    tulip    DECchip Tulip (dc21x4x)    CONFIG_TULIP
  epic_cb     epic100  SMC EtherPower II          CONFIG_EPIC100
  serial_cb   serial   Standard/generic serial    CONFIG_SERIAL
  apa1480_cb  aic7xxx  Adaptec AIC7xxx SCSI       CONFIG_SCSI_AIC7XXX

There are two drivers for Xircom CardBus cards:

  xircom_tulip_cb      Xircom Tulip-like CardBus   CONFIG_PCMCIA_XIRTULIP
  xircom_cb            Xircom CardBus (new driver) CONFIG_PCMCIA_XIRCOM

Hot plug PCI drivers are not managed by cardmgr; they are managed by
the "hotplug" subsystem.  See http://linux-hotplug.sourceforge.net for
information about this facility.  When cardmgr sees a card that is
owned by a hot plug PCI driver, it will ignore that card.  There will
be one beep when these cards are inserted/ejected, but they will be
identified only as a "CardBus hotplug device" in the log files.

Known problems and limitations:

o Some of the less widely used 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 built-in debugging aids at all.
o The kernel PCMCIA package cannot be configured to use PnP BIOS calls
  for resource management.  Recent kernels do have PnP BIOS support
  but the "glue" hasn't been written.
o With the introduction of the Hot Plug PCI subsystem, CardBus drivers
  now no longer act like other PCMCIA drivers; most obviously, they
  don't interact with the PCMCIA device configuration scripts.  These
  devices are configured using the "hotplug" scripts.

Answers to some common questions:

Q: Are these two versions of PCMCIA both going to continue with active
   development?
A: The kernel PCMCIA subsystem should be the focus for ongoing
   development.  The standalone pcmcia-cs drivers are still being
   maintained but the focus has shifted from adding functionality,
   towards just bug fixes.

Q: Which should I use / which is better?  The kernel PCMCIA, or the
   standalone PCMCIA?
A: The client drivers should generally behave the same.  At this
   point, most current distributions use the kernel PCMCIA subsystem,
   and I recommend sticking with that unless you have a particular
   need that is only met by the standalone drivers.

Q: What should I do as a driver developer?
A: I will not be including any significant new functionality in the
   standalone PCMCIA package.  In some cases it might still make sense
   to develop contributed drivers for the standalone package first if
   backwards compatibility with 2.2 kernels is useful.

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 install" in either the "clients" or
   "wireless" subdirectories after a normal "make config".

Q: Who is maintaining the kernel PCMCIA subsystem?
A: I am not playing a central 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.

Q: What about 2.5, 2.6, and beyond?
A: The PCMCIA subsystem in 2.5 has been extensively rewritten, thanks
   to the work of Russell King, Dominik Brodowski, and others.  There
   is a mailing list devoted to discussion of new PCMCIA development
   at http://lists.infradead.org/mailman/listinfo/linux-pcmcia.  The
   standalone pcmcia-cs modules will probably not be ported beyond 2.4
   kernels, due the number of API changes.
