[PATCH 3/5] documentation: Remove drivers/char/README.ecpa

james4765_at_verizon.net
Date: 11/03/04

  • Next message: Jean Delvare: "Re: dmi_scan on x86_64"
    To: linux-kernel@vger.kernel.org
    Date:	Wed, 3 Nov 2004 09:23:01 -0600
    
    

    Remove unneeded file from drivers/char.

    Signed-off-by: James Nelson <james4765@gmail.com>

    diff -urN --exclude='*~' linux-2.6.9-original/drivers/char/README.epca linux-2.6.9/drivers/char/README.epca
    --- linux-2.6.9-original/drivers/char/README.epca 2004-10-18 17:55:20.000000000 -0400
    +++ linux-2.6.9/drivers/char/README.epca 1969-12-31 19:00:00.000000000 -0500
    @@ -1,532 +0,0 @@
    -user.doc
    -Digi International driver package for the PC/Xe, PC/Xi, PC/Xr, PC/Xem as well
    -the EISA and PCI variants of these boards where applicable.
    -Copyright (C) 1996 Digi International. Written by Ronnie Sanford digilnux@dgii.com
    -
    - This program is free software; you can redistribute it and/or modify it
    - under the terms of the GNU General Public License as published by the
    - Free Software Foundation; either version 2 of the License, or (At your
    - option) any later version.
    -
    - This program is distributed in the hope that it will be useful, but
    - WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY
    - or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License
    - for more details.
    -
    - You should have received a copy of the GNU General Public License along
    - with this program; if not write to the Free Software Foundation, Inc.,
    - 675 Mass Ave, Cambridge, MA 02139, USA.
    -
    -
    -This document describes the software used with the Digi/Linux driver package.
    -The four user programs listed below are described in this document:
    -
    - 1. digiConfig -> Application that configures the Digi driver.
    -
    - 2. digiDload -> Application which initializes the Digi hardware.
    -
    - 3. buildPCI -> Application which provides the user a method of
    - building device nodes for PCI devices.
    -
    - 4. ditty -> Application which provides the user a method of
    - configuring terminal options on Digi hardware.
    -
    -
    -
    ---------------------------------------------------------------------------
    -1. Configuring driver/kernel for Digi products
    ---------------------------------------------------------------------------
    -
    - The Digi driver must be configured each time Digi hardware is added
    - or removed. There are two supported methods of doing this. The
    - first method configures the driver dynamically at boot time but requires
    - the user to utilize the lilo loader. This method is the preffered method
    - as it does not require the rebuilding of the kernel. In order to use lilo
    - to configure Digi boards at boot time an appropriate append command should
    - be added to /etc/lilo.conf below the appropriate label decleration.
    - See footer 4. The append commands format is a string of comma separated
    - identifiers or integers used to configure supported boards. These six
    - values in order are:
    -
    - Enable/Disable this card or Override,
    - Type of card: PC/Xe (AccelePort) (0), PC/Xeve (1), PC/Xem or PC/Xr (2),
    - EISA/Xem (3), PC/Xe (64K) (4), PC/Xi (5).
    - Enable/Disable alternate pin arrangement,
    - Number of ports on this card,
    - I/O Port where card is configured (in HEX if using string identifiers),
    - Base of memory window (in HEX if using string identifiers)
    -
    - A sample append command is given below which if used would configure and
    - enable a PC/Xe with 8 ports, at i/o address 200, memory address 0xd0000
    - with alt pin turned off. The lilo.conf file should look like this:
    -
    - image = /vmlinuz
    - root = /dev/hda2
    - label = vmlinuz
    - append="digiepca=E,PC/Xe,D,8,200,D0000"
    -
    - likewise the below will perform the same function:
    -
    - image = /vmlinuz
    - root = /dev/hda2
    - label = vmlinuz
    - append="digiepca=1,0,0,8,512,851968"
    -
    - Note:
    -
    - PCI boards are auto-detected and configured (Hence their codes are
    - not given here). Do not attempt to configure PCI boards with the lilo
    - append command.
    -
    - If configuration data has been specified by using digiConfig (Described
    - below), and you wish to override this configuration using lilo without
    - specifying a specific card (Example if there are PCI cards in the system)
    - the following override command will accomplish this:
    -
    - -> append="digiepca=2"
    -
    - If lilo is not enabled, the second method of configuring Digi hardware
    - will have to be used. digiConfig is an application that can be used
    - to inform the system of any additions, deletions, or modifications
    - involving Digi hardware. To use this method the operator executes
    - digiConfig anytime an EISA or ISA card is added that he wishes to use.
    - This routine is also used to remove cards from the system, and to modify
    - parameters of those cards already present in the system. Upon being
    - executed digiConfig modifies files accessed by the Digi driver. To make
    - these changes permanent; the operating system must be recompiled. After
    - the operating system has been recompiled and booted, the changes made with
    - digiConfig will be introduced to the user. This program MUST be executed
    - every time Digi EISA/ISA hardware configuration changes. Note, it is not
    - necessary to execute digiConfig in order to configure the Digi PCI cards.
    - These cards are self-identifying and will be recognized by the driver.
    - They cannot be displayed using digiConfig nor will digiConfig build the
    - device nodes their device nodes. See footer 1.
    -
    - To execute digiConfig; simply type: digiConfig
    -
    - The application will query you for the type, memory address, port
    - address, number of ports, alt pin disposition and status of each board
    - that exist on the system. Note, currently this driver only supports
    - PC/Xe, PC/Xeve, PC/Xi, PC/Xr, and PC/Xem as well as their EISA and PCI
    - implementations if applicable. All supported cards (Other than PCI) that
    - are present should be registered via digiConfig. See footer 2.
    -
    - After all cards have been configured select exit. The system will then
    - inform you if any changes have been made, and ask you if it is okay to
    - make these changes permanent. If the data entered is correct, select okay.
    - Selecting cancel will prevent the changes from becoming active. digiConfig
    - can then be re-executed to configure the system again.
    -
    ---------------------------------------------------------------------------
    -2. Initializing Digi hardware with digiDload
    ---------------------------------------------------------------------------
    -
    - digiDload is the application executed after the Digi driver has been
    - loaded. It is responsible for initializing the hardware and leaving
    - it in a state such that the Digi board may be operated by the user.
    - The application may be placed anywhere on the path, but its related
    - support files must be located in /etc/digi. The related files are:
    -
    - sxfep.bin
    - sxbios.bin
    - xxfep.bin
    - xxbios.bin
    -
    - The format for this command is "digiDload [v]". If given the "v"
    - option turns on verbosity. If not given the application runs in quite
    - mode. To execute the program simply type:
    -
    - digiDload
    -
    - Upon completion digiDload will generate the below message:
    -
    - "digiDload complete: Card initialized"
    -
    - At this point the card is configured and ready for normal usage. See
    - technotes.doc for information on how how ports are determined and
    - assigned.
    -
    ---------------------------------------------------------------------------
    -3. Build PCI device nodes with buildPCI
    ---------------------------------------------------------------------------
    -
    - buildPCI is an application useful for building the necessary device nodes
    - for Digi PCI cards. It is reccomended that this tool be used because the
    - current digiConfig application does not provide this function for PCI cards
    - (Though it does build device nodes for non-PCI cards). To use this program
    - execute the following:first install the driver, and execute digiDload (See above). After digiDload
    - has successfully loaded, execute the following:
    -
    - buildPCI <arg1> <arg2>
    -
    - Where arg1 is the number of ports connected to Digi cards that are not PCI
    - (As shown by the digiConfig utility), and arg2 is the number of ports
    - connected to Digi cards that are PCI.
    -
    - Note, buildPCI only has to be ran once to build the necessary device
    - nodes. Though this program may be executed at anytime, we reccomend
    - delaying execution until the first time you install the package and after
    - digiDload has been executed.
    -
    ---------------------------------------------------------------------------
    -4. Setting Terminal Options with ditty
    ---------------------------------------------------------------------------
    -
    -ditty is a utility program that sets and displays the terminal options
    -for Digi intelligent serial products. See man ditty for detailed information.
    -
    -
    -Footnotes:
    -
    -1. The 1.2.x kernel does not provide a method of mapping the high
    - addresses (Normally higher than RAM) associated with PCI. For this
    - reason, this driver disables PCI support while running under the 1.2.x
    - kernels.
    -
    -2. PCI cards should not and cannot be registered with digiConfig. After
    - the driver has been loaded buildPCI may be executed to construct the
    - necessary device nodes. This step is not necessary for system not
    - having Digi PCI cards.
    -
    -3. This is because we forsee a time when buildPCI may auto-detect the
    - available Digi PCI cards and this would only work if the program is
    - executed after digiDload.
    -
    -4. A complete example is given in install.doc.
    -
    --------------CHANGES--------------------
    -
    -All changes should be recorded here. All changes should be explained in
    -verbose detail.
    ------------------------------------------------------------------------
    -Programmer : Ronnie Sanford
    -Date : June 1, 1996
    -Description (Verbose) : Initial release of driver package.
    -Files affected : all
    -Release version : 1.0.0f (BETA)
    ------------------------------------------------------------------------
    ------------------------------------------------------------------------
    -Programmer : Ronnie Sanford
    -Date : August 7, 1996
    -Description (Verbose) : Made several modifications to provide PCI and EISA
    - support:
    -
    - 1. We now allocate the termios structures based on
    - the maximum number of channels that COULD be
    - available to the system. We no longer use the
    - number of channels declared in epcaconfig.h
    - (NBDEVS) as the total channel number. This is
    - because this value does not represent channels
    - available to potential PCI cards. This new
    - larger value is also passed back to the os in
    - the num field of tty_driver.
    -
    - 2. Added code to copy the previous board structure
    - (Now called static_boards) into a new local
    - copy of the boards structure. This has been
    - done so that PCI cards may be added to this
    - board array and later referenced (And even
    - queried.).
    -
    - 3. Added code to pc_init that checks for supported
    - PCI cards. If found this code initializes a new
    - entry into the drivers local board structure
    - with the PCI cards address, and type, etc.. It
    - also bumps the card count (num_cards).
    -
    - 4. Modified code in post_fep_init so that when this
    - routine is executed the number of ports supported
    - by a particular PCI card will be determined and
    - loaded into the board structure. It would be
    - much better if this code was placed in pc_init
    - (Because we could then report to the os the true
    - number of ports available; not just the max), but
    - since the card has to be booted to determine the
    - number of ports it supports, we are forced to do it
    - after DIGI_INIT has called post_fep_init. In the
    - future we may attempt to read the num ports
    - attached directly (address 0x1ac).
    -
    - 5. Added board types to epca.h in support of various
    - PCI boards (Some of which do not exist yet).
    - Added procedures for these boards throughout the
    - code. Note, windowing is not necessary for PCI
    - boards.
    -
    - 6. Added code supporting the EISA/XEM. This included
    - modifying epca.h with the new board type and
    - adding this type into the driver. The EISA/XEM
    - is basically identical to the PC/XEM, other than
    - it's base address does not have to be (And cannot
    - be configured directly).
    -
    - 7. Modified digiConfig to prompt for EISA/XEM cards.
    -
    -Files affected : epca.c, epca.h, digi1.h, digiConfig
    -Release version : 1.0.0g (BETA)
    ------------------------------------------------------------------------
    ------------------------------------------------------------------------
    -Programmer : Ronnie Sanford
    -Date : August 21, 1996
    -Description (Verbose) : Made the following modifications:
    -
    - 1. A problem affecting hard flow control was found
    - in the termios2digi_h routine. Specifically,
    - when the user activated hard flow control using
    - the CRTSCTS specification, the values used to
    - program hard flow control on the board were
    - incorrect. The solution was to change a line
    - that read "res |= ((ch->m_dtr) | (ch->m_rts));"
    - to "res |= ((ch->m_cts) | (ch->m_rts));" This
    - line only applies if cflag & CRTSCTS. Special
    - thanks to Matt Robinson (matt@mania.com.au) who
    - found and fixed this problem.
    -
    - 2. In previous betas the cud device was set to CLOCAL
    - on driver boot up. Likewise the ttyD device was
    - set to ~CLOCAL. This has been fixed in this driver.
    - Now ttyD is CLOCAL and cud is ~CLOCAL. The fix
    - for this can be found in pc_init.
    -
    - 3. In ditty.c many changes were made to eliminate bugs
    - and warning messages. Two ioctl calls were eliminated
    - as well a problem involving using the returned baud
    - index to determine the drivers baud rate. Newer
    - Linux kernels support higher baud rates by using
    - 0x1000 bit. When the returned value (ored with
    - 0x1000) was used to reference our fbaud table a
    - serious memory problem occurred. This has been fixed.
    -
    - 4. Added a request_region call to post_fep_init. This
    - should cause the i/o ports being used to be
    - registered with proc.
    -
    - 5. Modified digiConfig to set all cud and ttyD devices
    - to read/write all permission.
    -
    - 6. Developed a new apps called buildPCI that provides
    - an easy way to build device nodes for PCI cards.
    -
    - 7. Modified user.doc and technotes.doc document the
    - use of buildPCI.
    -
    -Files affected : epca.c, ditty.c, digiConfig, user.doc, technotes.doc
    -Release version : 1.0.0 (Official release)
    ------------------------------------------------------------------------
    -Programmer : Ronnie Sanford
    -Date : August 21, 1996
    -Description (Verbose) : Made the following modifications:
    -
    - 1. Removed code from pc_close which closes the
    - drivers line discipline and restores its original
    - line discipline. This is currently unnecessary,
    - though future fast cook enhancements may require
    - this.
    -
    - 2. Removed code in block_til_ready that set the
    - asyncflags to either ASYNC_CALLOUT_ACTIVE, or
    - ASYNC_NORMAL_ACTIVE. This code was redundant
    - as it already existed in block_til_ready.
    -
    - 3. Added code in block_til_ready to cause a return
    - prior to schedule being called if the device
    - was a CALLOUT device. CALLOUT devices never
    - block on CD. (This was a serious bug that
    - prevented the CALLOUT devices (ttyD) from
    - functioning properly in some instances.
    -
    - Make a change in the MODEMCHG_IND case of doevent
    - such that it does not require ASYNC_CALLOUT_ACTIVE
    - or ASYNC_NORMAL_ACTIVE to be set in order to
    - unblock an open (Using wait_interruptible).
    -
    - Thanks to Mike McLagan (mike.mclagan@linux.org)
    - for diagnosing and fixing this problem.
    -
    - 4. Made changes to the disposition of CLOCAL on
    - both SERIAL NORMAL and CALLOUT devices. Both
    - device types now have CLOCAL active at default.
    - This may be changed with a stty command.
    -
    - 5. Made changes to digiConfig such that it checks
    - major.h (If valid) for the correct major
    - numbers to use.
    -
    -Files affected : epca.c, digiConfig
    -Release version : 1.0.1a
    -
    -
    ------------------------------------------------------------------------
    -Programmer : Ronnie Sanford
    -Date : September 17, 1996
    -Description (Verbose) : Made the following modifications:
    -
    - 1. Modified pc_open such that it no longer checks
    - the cflag value returned by termios2digi_c for
    - CLOCAL. Digi hardware does not use this value
    - and thus termios2digi_c rightly screens this
    - value out. This driver checks for CLOCAL using
    - the drivers cflag value as known by the Linux OS.
    - (The value passed into termios2digi_c)
    -
    - 2. Modified termios2digi_c to screen out the
    - CBAUDEX in CBAUD. This error caused parity to
    - automaticaly be enabled on at higher baud rates.
    -
    -
    - 3. Added the "disable_bh()" call to the shutdown
    - subroutine. Hopefully this will allow the driver
    - to correctly clean up after itself when used as a
    - module.
    -
    - 4. Added support for the PC/XI and 64K PC/XE cards.
    - This involved primarily modifying digiDload to
    - initialize and boot the new cards; however
    - driver modifications were also required to
    - provide the proper windowing for the newly
    - supported cards. (Code was also added to
    - determine the memory segment of the XI card as
    - that card may have more than 64K. Currently
    - digiDload assumes a 64K XI card.)
    -
    - 5. Added subroutine called epca_setup that can be
    - called during LILO boot up. This provides the
    - user an easy way to change cards; without
    - running digiConfig and without recompiling the
    - kernel. Added code in pc_init and pc_open to
    - support the epca_setup routine. pc_init checks
    - the liloconfig flag (Which is set by epca_setup)
    - to determine if the driver is using the LILO
    - arguments. If not pc_init loads the board data
    - found in epcaconfig.h; if so it DOESN'T load
    - epcaconfig data depending on epca_setup to handle
    - board configuration. pc_open has been modified
    - such that it checks to ensure that no errors
    - occurred during the LILO boot process. If a
    - user attempts to boot the driver (via. LILO)
    - with incorrect data, the open will fail.
    -
    - 6. Modified the windowing routines pcxe_rxwinon
    - and pcxe_txwinon routines. A bug existed such
    - that those routines checked to see if the rxwin
    - and txwin flags were reset. If so they assumed
    - the board was an XI or 64K XE. Furthermore since
    - these flags were never initialized in our driver
    - sometimes they were 0 and therefore caused a
    - memory fault (Or at least a window overrun). This
    - code has been removed since the pcxe shares
    - nothing in common with the 64K XI and XE.
    -
    - 7. Added code in pc_init to set the memory_seg for
    - the various boards. This code was necessary to
    - correct a bug in the PCXE, PCXEVE code where
    - receive and transmit pointers were being calculated
    - from an uninitialized variable (memory_seg).
    -
    - 8. Modified digiConfig to allow 64K PC/XI and 64K
    - PC/XE cards to be configured.
    -
    - 9. Made changes to support the new 2.1.x development
    - kernel. In particular this required changing all
    - references to vremap to ioremap.
    -
    - 10. Modified digiConfig such that it now generates
    - node names corresponding to their internal
    - as opposed to the label on the port itself. Nodes
    - (ttyD?? and cud??) now start at 0. Example:
    - ttyD0 and cud0 represent port 1 on any supported
    - Digi product. A similar change has been made
    - in buildPCI.c.
    -
    - 12. At the early portion of post_fep_init if a PCI
    - card is detected a warning message could be given
    - incorrectly if 64 ports were attached to a PCI
    - card. The below line :
    -
    - epcaassert(bd->numports > 64,"PCI returned a invalid number of ports");
    -
    - was changed to :
    -
    - epcaassert(bd->numports <= 64,"PCI returned a invalid number of ports");
    -
    - Remember that epcaassert checks for NOT true.
    - Special thanks to Daniel Taylor for fixing this.
    -
    - 13. Modified the epcaparam routine. In version 100
    - and 101a there was a line that looked like the
    - below:
    -
    - if (ch->omodem != mval)
    -
    - The problem with this line was that the first time
    - through omodem was not initialized. Secondly, since
    - many TIOC commands did not alter mval (They use
    - a different variable) changes made by these commands
    - could be lost. This line was changed to:
    -
    - mval ^= ch->modemfake & (mval ^ ch->modem);
    -
    - if (ch->omodem ^ mval)
    -
    - 14. Modified digiConfig in such a way that it checks
    - the version number of the kernel and if it finds
    - a 2.x.x kernel or higher it reads the necessary
    - major numbers for cud and ttyD devices from major.h.
    - This was also done in prior versions but these
    - versions required a #define which identified the
    - kernel as a version which did not have major numbers
    - assigned to Digi systems. This #define is no
    - longer required allowing the same source tree for
    - multiple kernel releases.
    -
    - 15. Used macros to replace kernel specific calls such
    - as put_fs_long, get_fs_long, put_user, and get_user
    - the kernel version is now detected and the macro
    - is defined as to correspond with the kernel it
    - is being compiled into. Again this was done to
    - allow one source tree for multiple kernel releases.
    -
    - 16. Added support for the new 2.1.x development kernels
    - to digiInstall.
    -
    -Files affected : epca.c, digiConfig
    -Release version : 1.1.0
    ------------------------------------------------------------------------
    -Programmer : Daniel Taylor
    -Date : April 25, 1997
    -Description (Verbose) : Updated driver:
    - 1. Fixed DCD bug. (&tq scheduler)
    - 2. Removed BH handler code, as it was only handling
    - hangups, and not being called for that.
    - 3. Namespace cleanup (DIGI_TIMER2 => DIGI_TIMER)
    - 4. Updated to 2.1.36, removed #ifdefs for earlier
    - kernel revisions.
    -Files affected : epca.c
    -Release version : 1.1.1 (BETA)
    ------------------------------------------------------------------------
    -Programmer : Daniel Taylor
    -Date : March 11, 1999
    -Description (Verbose) : Updated driver:
    - 1. Simultaneous data and modem change events were
    - resulting in the modem change events not being
    - recognized. Fixed.
    - 2. Modified pc_info device name to work better
    - with devfs.
    -Files affected : epca.c
    -Release version : 1.3.0-K
    ------------------------------------------------------------------------
    -Programmer : Jeff Garzik
    -Date : February 26, 2000
    -Description (Verbose) : Updated driver:
    - 1. Use new kernel PCI interfaces.
    - 2. Updated list of includes.
    -Files affected : epca.c
    -Release version : 1.3.0.1-LK
    ------------------------------------------------------------------------
    -Programmer : Arjan van de Ven <adve@oce.nl>
    -Date : March 10, 2000
    -Description (Verbose) : Fixed includes to make it actually compile
    - for kernel 2.3.51
    -Files affected : epca.c
    -Release version : 1.3.0.2-LK
    ------------------------------------------------------------------------
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/


  • Next message: Jean Delvare: "Re: dmi_scan on x86_64"

    Relevant Pages

    • SunPCi / Intel 21555 drivers
      ... SunPCi cards are PCI cards developed by Sun that contain an almost ... On the Solaris side, Sun keeps diskimage files which act as the hard ... in the beginning stages of developing a Linux driver for the host side. ...
      (Linux-Kernel)
    • Re: Multi port serial card supported under Solaris 10/X64
      ... work with PCI cards, so any supplier must also write a Solaris ... you'll need a 64 bit x86 driver ...
      (comp.unix.solaris)
    • Re: PCI Modem in SPARC
      ... >>would not talk to a standard PCI UART, ... and the 3 PCI cards I have all do it ... you will need a driver of some sort. ...
      (comp.unix.solaris)
    • Re: Kernel 2.6 supported ULTRA 160 SCIS card needed
      ... This beast needs to be fed VERY FAST. ... I don't want to have to mess with driver compilation or complicated ... The Adaptec cards are well-established. ... To get maximum performance out of U160 or U320 SCSI, you'll need 64-bit PCI or PCI-X. ...
      (comp.os.linux.hardware)
    • Re: PROBLEM: 2.6.23-rc "NETDEV WATCHDOG: eth0: transmit timed out"
      ... 2.6.23-rc1 I have trouble with my network connection. ... # Bus options (PCI, PCMCIA, EISA, MCA, ISA) ... # PCCARD support ... # Generic Driver Options ...
      (Linux-Kernel)