readme-2.4

pcmcia source code

		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.4test9-pre* kernels.

The kernel PCMCIA code has the same functionality as the driver side
of the pcmcia-cs package.  It does not eliminate the need to install
the pcmcia-cs package, since it requires the same user tools (cardmgr,
cardctl, /etc/pcmcia/* files).  For now, the drivers in pcmcia-cs can
still be built for 2.4 kernels, so you have a choice of using either
the in-kernel PCMCIA drivers, or the drivers included in pcmcia-cs.

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.  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.

In the standalone pcmcia-cs drivers, the i82365 module supports both
ISA-to-PCMCIA, PCI-to-PCMCIA, and PCI-to-CardBus bridges.  The CardBus
socket driver in the 2.4 tree is the "yenta_socket" driver.  It is
selected by the CONFIG_CARDBUS option.  In your PCMCIA startup
options, this driver should be specified in place of the i82365
driver.  The kernel version of the i82365 driver, selected by
CONFIG_I82365, only supports ISA-to-PCMCIA bridges.  PCI-to-PCMCIA
bridges that are not CardBus capable, like the Cirrus PD6729, are not
supported at all by the kernel PCMCIA drivers.

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 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

Xircom CardBus cards are supported by a separate driver ('Xircom
Tulip-like CardBus', xircom_tulip_cb, CONFIG_PCMCIA_XIRTULIP).  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 new 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 Someone changed the name of the "ide_cs" driver in the 2.4 tree to
  "ide-cs".  To deal with this annoyance, edit /etc/pcmcia/config and
  change every instance of "ide_cs" to "ide-cs".  Yes this means that
  the same config file won't work for 2.2 kernels.  No you cannot just
  rename the module or add an alias to /etc/modules.conf; the string
  is also embedded in the module.
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 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 is rarely a
  serious issue.
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 mainly bug fixes.

Q: Which should I use / which is better?  The kernel PCMCIA, or the
   standalone PCMCIA?
A: It rarely matters.  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 be really picky about 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 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 install" 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.