PCMCIA(5)                                               PCMCIA(5)

       /etc/pcmcia/config - PCMCIA card configuration database

       The  PCMCIA  card configuration file is read by cardmgr(8)
       at startup time.  It defines what resources are  available
       for  use  by Card Services, describes how to load and ini-
       tialize device  drivers,  and  describes  specific  PCMCIA

Resource descriptions
       There  are  three  kinds  of  resource  entries:  include,
       exclude, and reserve.  Including a resource  enables  Card
       Services  to  allocate  that  resource for client drivers.
       Part of a resource that is under Card Services control can
       be  excluded  if a specific device in the system uses that
       resource.  And, a resource can be  reserved,  so  that  it
       will  only be assigned to a client if that client specifi-
       cally  asks  for  that  resource,  or  no  other  suitable
       resources are available.

       There are three resource types: port, memory, and irq.  By
       default, Card Services assumes that it can use any  inter-
       rupt that is not bound by another device driver.  However,
       it makes no assumptions about IO port and address  ranges,
       because  some Linux drivers do not register their resource
       usage.  So, port and memory ranges must be explicitly made
       available for use by PCMCIA devices.

       So, here is a portion of a config file:

              include port 0x300-0x3ff, memory 0xd0000-0xdffff
              reserve irq 3
              exclude irq 4, port 0x3f8-0x3ff

       This  says  that  Card  Services can allocate ports in the
       range 0x300 to 0x3ff, and memory in the range  0xd0000  to
       0xdffff.   It  should  not  use irq 4 or ports 0x3f8-0x3ff
       (even if they seem to be available).   And  irq  3  should
       only be allocated if a client specifically asks for it.

       Card  Services will never allocate resources already allo-
       cated   by   another   kernel    device    driver.     The
       include/exclude/reserve  mechanism  just provides a way of
       controlling what resources it will try to use, to  accomo-
       date  devices  that  are  not  registered  with  the Linux
       resource manager.

Device driver descriptions
       All Card Services  client  drivers  are  identified  by  a
       16-character  tag.   Device  entries  in  the  config file
       describe client drivers.  The only required field  is  the
       device  tag.  Additional fields can specify kernel modules
       that need to be loaded to make the device available, and a
       script to be executed to enable and disable instances of a
       device.  When an instance of a driver  is  assigned  to  a
       socket,  it  gives  cardmgr  a  device  name by which this
       device will be known by the system (for example, eth0  for
       a  net  device,  or  cua1 for a modem).  This name will be
       passed to the configuration script.  For example:

              device "pcnet_cs"
                class "network"
                module "net/8390" opts "ei_debug=4", "pcnet_cs"

       This says that the pcnet_cs device requires  two  loadable
       modules.   The first one is located in the net module sub-
       directory and will be loaded  with  a  specific  parameter
       setting.  The second module should be in the pcmcia module
       subdirectory.  The device is in the network class, so  the
       network script in the configuration directory will be used
       to start or stop the device.

       It is also possible to specify default options for a  par-
       ticular kernel module, outside of a device driver declara-
       tion.  This is convenient for keeping local  configuration
       options  in  a file separate from the main card configura-
       tion file.  For example:

              module "pcnet_cs" opts "mem_speed=600"

Card descriptions
       Card  declarations  map  PCMCIA  cards  to  their   client
       drivers.   A  card  declaration  consists of a descriptive
       name, a  method  for  identifying  the  card  when  it  is
       inserted, and driver bindings.  There are five identifica-
       tion methods: the version method matches a card using  its
       VERSION_1  id  strings,  the  manfid method matches a card
       using its MANFID tuple codes, the tuple method  matches  a
       card using any string embedded in any arbitrary CIS tuple,
       the function method matches a card using its function  ID,
       and  the  anonymous  method matches any card that does not
       have a CIS.  This last method is only intended to be  used
       for old-style Type I memory cards.  For example:

              card "Linksys Ethernet Card"
                tuple 0x40, 0x0009, "E-CARD PC Ethernet Card"
                bind "pcnet_cs"

       This  card  is  identified by a string at offset 0x0009 in
       tuple 0x40, and will  be  bound  to  the  pcnet_cs  driver
       (which  must be already declared in a driver declaration).

              card "Connectware LANdingGear Adapter"
                manfid 0x0057, 0x1004
                bind "pcnet_cs"

       This card is identified by its MANFID tuple contents.

              card "D-Link DE-650 Ethernet Card"
                version "D-Link", "DE-650"
                bind "pcnet_cs"

       This card will be identified using  its  VERSION_1  tuple,
       and will also be bound to the pcnet_cs driver.

              card "Serial port device"
                function serial_port
                bind "serial_cs"

       This  binds  the  serial_cs  driver to any card with a CIS
       function ID of 0x02, which corresponds to  a  serial  port
       card.   The  function ID can either be a number, or one of
       the   following   predefined    functions:    memory_card,
       serial_port,   parallel_port,  fixed_disk,  video_adapter,
       network_adapter, and aims_card.

       Finally, the configuration file can specify that Card Ser-
       vices  should  use  a  replacement  for  the configuration
       information found on a card.  This  can  be  useful  if  a
       card's  configuration  information  is particularly incom-
       plete or inaccurate.  The new information is read  from  a
       file as in this example:

              card "Evil broken card"
                manfid 0x1234, 0x5678
                cis "fixup.cis"
                bind "serial_cs"

Memory region definitions
       Memory region definitions are used to associate a particu-
       lar type of memory device with a Memory Technology Driver,
       or  "MTD".  An MTD is used to service memory accesses in a
       device-independent fashion.  When a  card  is  identified,
       Card  Services will attempt to load MTD's for all its mem-
       ory regions.

       A memory region definition begins with the region  keyword
       and  a descriptive string.  This is followed by an identi-
       fication method: either default to identify an MTD  to  be
       used  for  any  otherwise unclassified region, or jedec to
       identify a region based on its JEDEC identification codes.
       Thus, for example,

              region "Intel Series 2 Flash"
                jedec 0x89 0xa2
                mtd "iflash2_mtd"

       specifies that the iflash2_mtd driver will be loaded based
       on a JEDEC match.

       The reserve keyword has not actually been implemented in a
       useful way for this version of Card Services.

       David Hinds - dhinds@allegro.stanford.edu


pcmcia-cs              1998/05/04 23:28:17                      1