Home Man
Today's Posts

Linux & Unix Commands - Search Man Pages

RedHat 9 (Linux i386) - man page for pcmcia (redhat section 5)

PCMCIA(5)			       File Formats Manual				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  initialize
       device drivers, and describes specific PCMCIA cards.

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 specifically asks for that resource, or no other suit-
       able resources are available.

       There are three resource types: port, memory, and irq. By default, Card	Services  assumes
       that  it  can  use  any interrupt 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 avail-
       able 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 allocated by another kernel device
       driver.	The include/exclude/reserve mechanism just provides a  way  of	controlling  what
       resources it will try to use, to accomodate devices that are not registered with the Linux
       resource manager.

Device driver descriptions
       All Card Services client drivers are identified by a 32-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 subdirectory and will be loaded with a specific parameter set-
       ting.  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 particular kernel module, outside  of
       a  device  driver declaration.  This is convenient for keeping local configuration options
       in a file separate from the main card configuration 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 six identification 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 pci method matches a CardBus card using its PCI device ID's, 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.  The
       manfid and version methods can be combined to provide more discrimination; the other meth-
       ods cannot be combined.	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.  The pci method has the  same  form,
       with pci replacing manfid.

	      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  corre-
       sponds  to a serial port card.  The function ID can either be a number, or one of the fol-
       lowing  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 Services should use a replacement
       for the configuration information found on a card.  This can be useful if a card's config-
       uration information is particularly incomplete 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 particular 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 memory regions.

       A  memory region definition begins with the region keyword and a descriptive string.  This
       is followed by an identification 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 iden-
       tification 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 - dahinds@users.sourceforge.net


pcmcia-cs			       2001/06/20 04:28:08				PCMCIA(5)

All times are GMT -4. The time now is 01:47 AM.

Unix & Linux Forums Content Copyrightę1993-2018. All Rights Reserved.
Show Password