ASR_BASE
Change-Id: Icf3719cc0afe3eeb3edc7fa80a2eb5199ca9dda1
diff --git a/marvell/linux/Documentation/isdn/avmb1.rst b/marvell/linux/Documentation/isdn/avmb1.rst
new file mode 100644
index 0000000..de3961e
--- /dev/null
+++ b/marvell/linux/Documentation/isdn/avmb1.rst
@@ -0,0 +1,246 @@
+================================
+Driver for active AVM Controller
+================================
+
+The driver provides a kernel capi2.0 Interface (kernelcapi) and
+on top of this a User-Level-CAPI2.0-interface (capi)
+and a driver to connect isdn4linux with CAPI2.0 (capidrv).
+The lowlevel interface can be used to implement a CAPI2.0
+also for passive cards since July 1999.
+
+The author can be reached at calle@calle.in-berlin.de.
+The command avmcapictrl is part of the isdn4k-utils.
+t4-files can be found at ftp://ftp.avm.de/cardware/b1/linux/firmware
+
+Currently supported cards:
+
+ - B1 ISA (all versions)
+ - B1 PCI
+ - T1/T1B (HEMA card)
+ - M1
+ - M2
+ - B1 PCMCIA
+
+Installing
+----------
+
+You need at least /dev/capi20 to load the firmware.
+
+::
+
+ mknod /dev/capi20 c 68 0
+ mknod /dev/capi20.00 c 68 1
+ mknod /dev/capi20.01 c 68 2
+ .
+ .
+ .
+ mknod /dev/capi20.19 c 68 20
+
+Running
+-------
+
+To use the card you need the t4-files to download the firmware.
+AVM GmbH provides several t4-files for the different D-channel
+protocols (b1.t4 for Euro-ISDN). Install these file in /lib/isdn.
+
+if you configure as modules load the modules this way::
+
+ insmod /lib/modules/current/misc/capiutil.o
+ insmod /lib/modules/current/misc/b1.o
+ insmod /lib/modules/current/misc/kernelcapi.o
+ insmod /lib/modules/current/misc/capidrv.o
+ insmod /lib/modules/current/misc/capi.o
+
+if you have an B1-PCI card load the module b1pci.o::
+
+ insmod /lib/modules/current/misc/b1pci.o
+
+and load the firmware with::
+
+ avmcapictrl load /lib/isdn/b1.t4 1
+
+if you have an B1-ISA card load the module b1isa.o
+and add the card by calling::
+
+ avmcapictrl add 0x150 15
+
+and load the firmware by calling::
+
+ avmcapictrl load /lib/isdn/b1.t4 1
+
+if you have an T1-ISA card load the module t1isa.o
+and add the card by calling::
+
+ avmcapictrl add 0x450 15 T1 0
+
+and load the firmware by calling::
+
+ avmcapictrl load /lib/isdn/t1.t4 1
+
+if you have an PCMCIA card (B1/M1/M2) load the module b1pcmcia.o
+before you insert the card.
+
+Leased Lines with B1
+--------------------
+
+Init card and load firmware.
+
+For an D64S use "FV: 1" as phone number
+
+For an D64S2 use "FV: 1" and "FV: 2" for multilink
+or "FV: 1,2" to use CAPI channel bundling.
+
+/proc-Interface
+-----------------
+
+/proc/capi::
+
+ dr-xr-xr-x 2 root root 0 Jul 1 14:03 .
+ dr-xr-xr-x 82 root root 0 Jun 30 19:08 ..
+ -r--r--r-- 1 root root 0 Jul 1 14:03 applications
+ -r--r--r-- 1 root root 0 Jul 1 14:03 applstats
+ -r--r--r-- 1 root root 0 Jul 1 14:03 capi20
+ -r--r--r-- 1 root root 0 Jul 1 14:03 capidrv
+ -r--r--r-- 1 root root 0 Jul 1 14:03 controller
+ -r--r--r-- 1 root root 0 Jul 1 14:03 contrstats
+ -r--r--r-- 1 root root 0 Jul 1 14:03 driver
+ -r--r--r-- 1 root root 0 Jul 1 14:03 ncci
+ -r--r--r-- 1 root root 0 Jul 1 14:03 users
+
+/proc/capi/applications:
+ applid level3cnt datablkcnt datablklen ncci-cnt recvqueuelen
+ level3cnt:
+ capi_register parameter
+ datablkcnt:
+ capi_register parameter
+ ncci-cnt:
+ current number of nccis (connections)
+ recvqueuelen:
+ number of messages on receive queue
+
+ for example::
+
+ 1 -2 16 2048 1 0
+ 2 2 7 2048 1 0
+
+/proc/capi/applstats:
+ applid recvctlmsg nrecvdatamsg nsentctlmsg nsentdatamsg
+ recvctlmsg:
+ capi messages received without DATA_B3_IND
+ recvdatamsg:
+ capi DATA_B3_IND received
+ sentctlmsg:
+ capi messages sent without DATA_B3_REQ
+ sentdatamsg:
+ capi DATA_B3_REQ sent
+
+ for example::
+
+ 1 2057 1699 1721 1699
+
+/proc/capi/capi20: statistics of capi.o (/dev/capi20)
+ minor nopen nrecvdropmsg nrecvctlmsg nrecvdatamsg sentctlmsg sentdatamsg
+ minor:
+ minor device number of capi device
+ nopen:
+ number of calls to devices open
+ nrecvdropmsg:
+ capi messages dropped (messages in recvqueue in close)
+ nrecvctlmsg:
+ capi messages received without DATA_B3_IND
+ nrecvdatamsg:
+ capi DATA_B3_IND received
+ nsentctlmsg:
+ capi messages sent without DATA_B3_REQ
+ nsentdatamsg:
+ capi DATA_B3_REQ sent
+
+ for example::
+
+ 1 2 18 0 16 2
+
+/proc/capi/capidrv: statistics of capidrv.o (capi messages)
+ nrecvctlmsg nrecvdatamsg sentctlmsg sentdatamsg
+ nrecvctlmsg:
+ capi messages received without DATA_B3_IND
+ nrecvdatamsg:
+ capi DATA_B3_IND received
+ nsentctlmsg:
+ capi messages sent without DATA_B3_REQ
+ nsentdatamsg:
+ capi DATA_B3_REQ sent
+
+ for example:
+ 2780 2226 2256 2226
+
+/proc/capi/controller:
+ controller drivername state cardname controllerinfo
+
+ for example::
+
+ 1 b1pci running b1pci-e000 B1 3.07-01 0xe000 19
+ 2 t1isa running t1isa-450 B1 3.07-01 0x450 11 0
+ 3 b1pcmcia running m2-150 B1 3.07-01 0x150 5
+
+/proc/capi/contrstats:
+ controller nrecvctlmsg nrecvdatamsg sentctlmsg sentdatamsg
+ nrecvctlmsg:
+ capi messages received without DATA_B3_IND
+ nrecvdatamsg:
+ capi DATA_B3_IND received
+ nsentctlmsg:
+ capi messages sent without DATA_B3_REQ
+ nsentdatamsg:
+ capi DATA_B3_REQ sent
+
+ for example::
+
+ 1 2845 2272 2310 2274
+ 2 2 0 2 0
+ 3 2 0 2 0
+
+/proc/capi/driver:
+ drivername ncontroller
+
+ for example::
+
+ b1pci 1
+ t1isa 1
+ b1pcmcia 1
+ b1isa 0
+
+/proc/capi/ncci:
+ apllid ncci winsize sendwindow
+
+ for example::
+
+ 1 0x10101 8 0
+
+/proc/capi/users: kernelmodules that use the kernelcapi.
+ name
+
+ for example::
+
+ capidrv
+ capi20
+
+Questions
+---------
+
+Check out the FAQ (ftp.isdn4linux.de) or subscribe to the
+linux-avmb1@calle.in-berlin.de mailing list by sending
+a mail to majordomo@calle.in-berlin.de with
+subscribe linux-avmb1
+in the body.
+
+German documentation and several scripts can be found at
+ftp://ftp.avm.de/cardware/b1/linux/
+
+Bugs
+----
+
+If you find any please let me know.
+
+Enjoy,
+
+Carsten Paeth (calle@calle.in-berlin.de)
diff --git a/marvell/linux/Documentation/isdn/credits.rst b/marvell/linux/Documentation/isdn/credits.rst
new file mode 100644
index 0000000..319323f
--- /dev/null
+++ b/marvell/linux/Documentation/isdn/credits.rst
@@ -0,0 +1,73 @@
+=======
+Credits
+=======
+
+
+I want to thank all who contributed to this project and especially to:
+(in alphabetical order)
+
+Thomas Bogendörfer (tsbogend@bigbug.franken.de)
+ Tester, lots of bugfixes and hints.
+
+Alan Cox (alan@lxorguk.ukuu.org.uk)
+ For help getting into standard-kernel.
+
+Henner Eisen (eis@baty.hanse.de)
+ For X.25 implementation.
+
+Volker Götz (volker@oops.franken.de)
+ For contribution of man-pages, the imontty-tool and a perfect
+ maintaining of the mailing-list at hub-wue.
+
+Matthias Hessler (hessler@isdn4linux.de)
+ For creating and maintaining the FAQ.
+
+Bernhard Hailer (Bernhard.Hailer@lrz.uni-muenchen.de)
+ For creating the FAQ, and the leafsite HOWTO.
+
+Michael 'Ghandi' Herold (michael@abadonna.franken.de)
+ For contribution of the vbox answering machine.
+
+Michael Hipp (Michael.Hipp@student.uni-tuebingen.de)
+ For his Sync-PPP-code.
+
+Karsten Keil (keil@isdn4linux.de)
+ For adding 1TR6-support to the Teles-driver.
+ For the HiSax-driver.
+
+Michael Knigge (knick@cove.han.de)
+ For contributing the imon-tool
+
+Andreas Kool (akool@Kool.f.EUnet.de)
+ For contribution of the isdnlog/isdnrep-tool
+
+Pedro Roque Marques (roque@di.fc.ul.pt)
+ For lot of new ideas and the pcbit driver.
+
+Eberhard Mönkeberg (emoenke@gwdg.de)
+ For testing and help to get into kernel.
+
+Thomas Neumann (tn@ruhr.de)
+ For help with Cisco-SLARP and keepalive
+
+Jan den Ouden (denouden@groovin.xs4all.nl)
+ For contribution of the original teles-driver
+
+Carsten Paeth (calle@calle.in-berlin.de)
+ For the AVM-B1-CAPI2.0 driver
+
+Thomas Pfeiffer (pfeiffer@pds.de)
+ For V.110, extended T.70 and Hylafax extensions in isdn_tty.c
+
+Max Riegel (riegel@max.franken.de)
+ For making the ICN hardware-documentation and test-equipment available.
+
+Armin Schindler (mac@melware.de)
+ For the eicon active card driver.
+
+Gerhard 'Fido' Schneider (fido@wuff.mayn.de)
+ For heavy-duty-beta-testing with his BBS ;)
+
+Thomas Uhl (uhl@think.de)
+ For distributing the cards.
+ For pushing me to work ;-)
diff --git a/marvell/linux/Documentation/isdn/gigaset.rst b/marvell/linux/Documentation/isdn/gigaset.rst
new file mode 100644
index 0000000..98b4ec5
--- /dev/null
+++ b/marvell/linux/Documentation/isdn/gigaset.rst
@@ -0,0 +1,465 @@
+==========================
+GigaSet 307x Device Driver
+==========================
+
+1. Requirements
+=================
+
+1.1. Hardware
+-------------
+
+ This driver supports the connection of the Gigaset 307x/417x family of
+ ISDN DECT bases via Gigaset M101 Data, Gigaset M105 Data or direct USB
+ connection. The following devices are reported to be compatible:
+
+ Bases:
+ - Siemens Gigaset 3070/3075 isdn
+ - Siemens Gigaset 4170/4175 isdn
+ - Siemens Gigaset SX205/255
+ - Siemens Gigaset SX353
+ - T-Com Sinus 45 [AB] isdn
+ - T-Com Sinus 721X[A] [SE]
+ - Vox Chicago 390 ISDN (KPN Telecom)
+
+ RS232 data boxes:
+ - Siemens Gigaset M101 Data
+ - T-Com Sinus 45 Data 1
+
+ USB data boxes:
+ - Siemens Gigaset M105 Data
+ - Siemens Gigaset USB Adapter DECT
+ - T-Com Sinus 45 Data 2
+ - T-Com Sinus 721 data
+ - Chicago 390 USB (KPN)
+
+ See also http://www.erbze.info/sinus_gigaset.htm
+ (archived at https://web.archive.org/web/20100717020421/http://www.erbze.info:80/sinus_gigaset.htm ) and
+ http://gigaset307x.sourceforge.net/
+
+ We had also reports from users of Gigaset M105 who could use the drivers
+ with SX 100 and CX 100 ISDN bases (only in unimodem mode, see section 2.5.)
+ If you have another device that works with our driver, please let us know.
+
+ Chances of getting an USB device to work are good if the output of::
+
+ lsusb
+
+ at the command line contains one of the following::
+
+ ID 0681:0001
+ ID 0681:0002
+ ID 0681:0009
+ ID 0681:0021
+ ID 0681:0022
+
+1.2. Software
+-------------
+
+ The driver works with the Kernel CAPI subsystem and can be used with any
+ software which is able to use CAPI 2.0 for ISDN connections (voice or data).
+
+ There are some user space tools available at
+ https://sourceforge.net/projects/gigaset307x/
+ which provide access to additional device specific functions like SMS,
+ phonebook or call journal.
+
+
+2. How to use the driver
+==========================
+
+2.1. Modules
+------------
+
+ For the devices to work, the proper kernel modules have to be loaded.
+ This normally happens automatically when the system detects the USB
+ device (base, M105) or when the line discipline is attached (M101). It
+ can also be triggered manually using the modprobe(8) command, for example
+ for troubleshooting or to pass module parameters.
+
+ The module ser_gigaset provides a serial line discipline N_GIGASET_M101
+ which uses the regular serial port driver to access the device, and must
+ therefore be attached to the serial device to which the M101 is connected.
+ The ldattach(8) command (included in util-linux-ng release 2.14 or later)
+ can be used for that purpose, for example::
+
+ ldattach GIGASET_M101 /dev/ttyS1
+
+ This will open the device file, attach the line discipline to it, and
+ then sleep in the background, keeping the device open so that the line
+ discipline remains active. To deactivate it, kill the daemon, for example
+ with::
+
+ killall ldattach
+
+ before disconnecting the device. To have this happen automatically at
+ system startup/shutdown on an LSB compatible system, create and activate
+ an appropriate LSB startup script /etc/init.d/gigaset. (The init name
+ 'gigaset' is officially assigned to this project by LANANA.)
+ Alternatively, just add the 'ldattach' command line to /etc/rc.local.
+
+ The modules accept the following parameters:
+
+ =============== ========== ==========================================
+ Module Parameter Meaning
+
+ gigaset debug debug level (see section 3.2.)
+
+ startmode initial operation mode (see section 2.5.):
+ bas_gigaset ) 1=CAPI (default), 0=Unimodem
+ ser_gigaset )
+ usb_gigaset ) cidmode initial Call-ID mode setting (see section
+ 2.5.): 1=on (default), 0=off
+
+ =============== ========== ==========================================
+
+ Depending on your distribution you may want to create a separate module
+ configuration file like /etc/modprobe.d/gigaset.conf for these.
+
+2.2. Device nodes for user space programs
+-----------------------------------------
+
+ The device can be accessed from user space (eg. by the user space tools
+ mentioned in 1.2.) through the device nodes:
+
+ - /dev/ttyGS0 for M101 (RS232 data boxes)
+ - /dev/ttyGU0 for M105 (USB data boxes)
+ - /dev/ttyGB0 for the base driver (direct USB connection)
+
+ If you connect more than one device of a type, they will get consecutive
+ device nodes, eg. /dev/ttyGU1 for a second M105.
+
+ You can also set a "default device" for the user space tools to use when
+ no device node is given as parameter, by creating a symlink /dev/ttyG to
+ one of them, eg.::
+
+ ln -s /dev/ttyGB0 /dev/ttyG
+
+ The devices accept the following device specific ioctl calls
+ (defined in gigaset_dev.h):
+
+ ``ioctl(int fd, GIGASET_REDIR, int *cmd);``
+
+ If cmd==1, the device is set to be controlled exclusively through the
+ character device node; access from the ISDN subsystem is blocked.
+
+ If cmd==0, the device is set to be used from the ISDN subsystem and does
+ not communicate through the character device node.
+
+ ``ioctl(int fd, GIGASET_CONFIG, int *cmd);``
+
+ (ser_gigaset and usb_gigaset only)
+
+ If cmd==1, the device is set to adapter configuration mode where commands
+ are interpreted by the M10x DECT adapter itself instead of being
+ forwarded to the base station. In this mode, the device accepts the
+ commands described in Siemens document "AT-Kommando Alignment M10x Data"
+ for setting the operation mode, associating with a base station and
+ querying parameters like field strengh and signal quality.
+
+ Note that there is no ioctl command for leaving adapter configuration
+ mode and returning to regular operation. In order to leave adapter
+ configuration mode, write the command ATO to the device.
+
+ ``ioctl(int fd, GIGASET_BRKCHARS, unsigned char brkchars[6]);``
+
+ (usb_gigaset only)
+
+ Set the break characters on an M105's internal serial adapter to the six
+ bytes stored in brkchars[]. Unused bytes should be set to zero.
+
+ ioctl(int fd, GIGASET_VERSION, unsigned version[4]);
+ Retrieve version information from the driver. version[0] must be set to
+ one of:
+
+ - GIGVER_DRIVER: retrieve driver version
+ - GIGVER_COMPAT: retrieve interface compatibility version
+ - GIGVER_FWBASE: retrieve the firmware version of the base
+
+ Upon return, version[] is filled with the requested version information.
+
+2.3. CAPI
+---------
+
+ The devices will show up as CAPI controllers as soon as the
+ corresponding driver module is loaded, and can then be used with
+ CAPI 2.0 kernel and user space applications. For user space access,
+ the module capi.ko must be loaded.
+
+ Most distributions handle loading and unloading of the various CAPI
+ modules automatically via the command capiinit(1) from the capi4k-utils
+ package or a similar mechanism. Note that capiinit(1) cannot unload the
+ Gigaset drivers because it doesn't support more than one module per
+ driver.
+
+2.5. Unimodem mode
+------------------
+
+ In this mode the device works like a modem connected to a serial port
+ (the /dev/ttyGU0, ... mentioned above) which understands the commands::
+
+ ATZ init, reset
+ => OK or ERROR
+ ATD
+ ATDT dial
+ => OK, CONNECT,
+ BUSY,
+ NO DIAL TONE,
+ NO CARRIER,
+ NO ANSWER
+ <pause>+++<pause> change to command mode when connected
+ ATH hangup
+
+ You can use some configuration tool of your distribution to configure this
+ "modem" or configure pppd/wvdial manually. There are some example ppp
+ configuration files and chat scripts in the gigaset-VERSION/ppp directory
+ in the driver packages from https://sourceforge.net/projects/gigaset307x/.
+ Please note that the USB drivers are not able to change the state of the
+ control lines. This means you must use "Stupid Mode" if you are using
+ wvdial or you should use the nocrtscts option of pppd.
+ You must also assure that the ppp_async module is loaded with the parameter
+ flag_time=0. You can do this e.g. by adding a line like::
+
+ options ppp_async flag_time=0
+
+ to an appropriate module configuration file, like::
+
+ /etc/modprobe.d/gigaset.conf.
+
+ Unimodem mode is needed for making some devices [e.g. SX100] work which
+ do not support the regular Gigaset command set. If debug output (see
+ section 3.2.) shows something like this when dialing::
+
+ CMD Received: ERROR
+ Available Params: 0
+ Connection State: 0, Response: -1
+ gigaset_process_response: resp_code -1 in ConState 0 !
+ Timeout occurred
+
+ then switching to unimodem mode may help.
+
+ If you have installed the command line tool gigacontr, you can enter
+ unimodem mode using::
+
+ gigacontr --mode unimodem
+
+ You can switch back using::
+
+ gigacontr --mode isdn
+
+ You can also put the driver directly into Unimodem mode when it's loaded,
+ by passing the module parameter startmode=0 to the hardware specific
+ module, e.g.::
+
+ modprobe usb_gigaset startmode=0
+
+ or by adding a line like::
+
+ options usb_gigaset startmode=0
+
+ to an appropriate module configuration file, like::
+
+ /etc/modprobe.d/gigaset.conf
+
+2.6. Call-ID (CID) mode
+-----------------------
+
+ Call-IDs are numbers used to tag commands to, and responses from, the
+ Gigaset base in order to support the simultaneous handling of multiple
+ ISDN calls. Their use can be enabled ("CID mode") or disabled ("Unimodem
+ mode"). Without Call-IDs (in Unimodem mode), only a very limited set of
+ functions is available. It allows outgoing data connections only, but
+ does not signal incoming calls or other base events.
+
+ DECT cordless data devices (M10x) permanently occupy the cordless
+ connection to the base while Call-IDs are activated. As the Gigaset
+ bases only support one DECT data connection at a time, this prevents
+ other DECT cordless data devices from accessing the base.
+
+ During active operation, the driver switches to the necessary mode
+ automatically. However, for the reasons above, the mode chosen when
+ the device is not in use (idle) can be selected by the user.
+
+ - If you want to receive incoming calls, you can use the default
+ settings (CID mode).
+ - If you have several DECT data devices (M10x) which you want to use
+ in turn, select Unimodem mode by passing the parameter "cidmode=0" to
+ the appropriate driver module (ser_gigaset or usb_gigaset).
+
+ If you want both of these at once, you are out of luck.
+
+ You can also use the tty class parameter "cidmode" of the device to
+ change its CID mode while the driver is loaded, eg.::
+
+ echo 0 > /sys/class/tty/ttyGU0/cidmode
+
+2.7. Dialing Numbers
+--------------------
+provided by an application for dialing out must
+ be a public network number according to the local dialing plan, without
+ any dial prefix for getting an outside line.
+
+ Internal calls can be made by providing an internal extension number
+ prefixed with ``**`` (two asterisks) as the called party number. So to dial
+ eg. the first registered DECT handset, give ``**11`` as the called party
+ number. Dialing ``***`` (three asterisks) calls all extensions
+ simultaneously (global call).
+
+ Unimodem mode does not support internal calls.
+
+2.8. Unregistered Wireless Devices (M101/M105)
+----------------------------------------------
+
+ The main purpose of the ser_gigaset and usb_gigaset drivers is to allow
+ the M101 and M105 wireless devices to be used as ISDN devices for ISDN
+ connections through a Gigaset base. Therefore they assume that the device
+ is registered to a DECT base.
+
+ If the M101/M105 device is not registered to a base, initialization of
+ the device fails, and a corresponding error message is logged by the
+ driver. In that situation, a restricted set of functions is available
+ which includes, in particular, those necessary for registering the device
+ to a base or for switching it between Fixed Part and Portable Part
+ modes. See the gigacontr(8) manpage for details.
+
+3. Troubleshooting
+====================
+
+3.1. Solutions to frequently reported problems
+----------------------------------------------
+
+ Problem:
+ You have a slow provider and isdn4linux gives up dialing too early.
+ Solution:
+ Load the isdn module using the dialtimeout option. You can do this e.g.
+ by adding a line like::
+
+ options isdn dialtimeout=15
+
+ to /etc/modprobe.d/gigaset.conf or a similar file.
+
+ Problem:
+ The isdnlog program emits error messages or just doesn't work.
+ Solution:
+ Isdnlog supports only the HiSax driver. Do not attempt to use it with
+ other drivers such as Gigaset.
+
+ Problem:
+ You have two or more DECT data adapters (M101/M105) and only the
+ first one you turn on works.
+ Solution:
+ Select Unimodem mode for all DECT data adapters. (see section 2.5.)
+
+ Problem:
+ Messages like this::
+
+ usb_gigaset 3-2:1.0: Could not initialize the device.
+
+ appear in your syslog.
+ Solution:
+ Check whether your M10x wireless device is correctly registered to the
+ Gigaset base. (see section 2.7.)
+
+3.2. Telling the driver to provide more information
+---------------------------------------------------
+ Building the driver with the "Gigaset debugging" kernel configuration
+ option (CONFIG_GIGASET_DEBUG) gives it the ability to produce additional
+ information useful for debugging.
+
+ You can control the amount of debugging information the driver produces by
+ writing an appropriate value to /sys/module/gigaset/parameters/debug,
+ e.g.::
+
+ echo 0 > /sys/module/gigaset/parameters/debug
+
+ switches off debugging output completely,
+
+ ::
+
+ echo 0x302020 > /sys/module/gigaset/parameters/debug
+
+ enables a reasonable set of debugging output messages. These values are
+ bit patterns where every bit controls a certain type of debugging output.
+ See the constants DEBUG_* in the source file gigaset.h for details.
+
+ The initial value can be set using the debug parameter when loading the
+ module "gigaset", e.g. by adding a line::
+
+ options gigaset debug=0
+
+ to your module configuration file, eg. /etc/modprobe.d/gigaset.conf
+
+ Generated debugging information can be found
+ - as output of the command::
+
+ dmesg
+
+ - in system log files written by your syslog daemon, usually
+ in /var/log/, e.g. /var/log/messages.
+
+3.3. Reporting problems and bugs
+--------------------------------
+ If you can't solve problems with the driver on your own, feel free to
+ use one of the forums, bug trackers, or mailing lists on
+
+ https://sourceforge.net/projects/gigaset307x
+
+ or write an electronic mail to the maintainers.
+
+ Try to provide as much information as possible, such as
+
+ - distribution
+ - kernel version (uname -r)
+ - gcc version (gcc --version)
+ - hardware architecture (uname -m, ...)
+ - type and firmware version of your device (base and wireless module,
+ if any)
+ - output of "lsusb -v" (if using an USB device)
+ - error messages
+ - relevant system log messages (it would help if you activate debug
+ output as described in 3.2.)
+
+ For help with general configuration problems not specific to our driver,
+ such as isdn4linux and network configuration issues, please refer to the
+ appropriate forums and newsgroups.
+
+3.4. Reporting problem solutions
+--------------------------------
+ If you solved a problem with our drivers, wrote startup scripts for your
+ distribution, ... feel free to contact us (using one of the places
+ mentioned in 3.3.). We'd like to add scripts, hints, documentation
+ to the driver and/or the project web page.
+
+
+4. Links, other software
+==========================
+
+ - Sourceforge project developing this driver and associated tools
+ https://sourceforge.net/projects/gigaset307x
+ - Yahoo! Group on the Siemens Gigaset family of devices
+ https://de.groups.yahoo.com/group/Siemens-Gigaset
+ - Siemens Gigaset/T-Sinus compatibility table
+ http://www.erbze.info/sinus_gigaset.htm
+ (archived at https://web.archive.org/web/20100717020421/http://www.erbze.info:80/sinus_gigaset.htm )
+
+
+5. Credits
+============
+
+ Thanks to
+
+ Karsten Keil
+ for his help with isdn4linux
+ Deti Fliegl
+ for his base driver code
+ Dennis Dietrich
+ for his kernel 2.6 patches
+ Andreas Rummel
+ for his work and logs to get unimodem mode working
+ Andreas Degert
+ for his logs and patches to get cx 100 working
+ Dietrich Feist
+ for his generous donation of one M105 and two M101 cordless adapters
+ Christoph Schweers
+ for his generous donation of a M34 device
+
+ and all the other people who sent logs and other information.
diff --git a/marvell/linux/Documentation/isdn/hysdn.rst b/marvell/linux/Documentation/isdn/hysdn.rst
new file mode 100644
index 0000000..0a168d1
--- /dev/null
+++ b/marvell/linux/Documentation/isdn/hysdn.rst
@@ -0,0 +1,196 @@
+============
+Hysdn Driver
+============
+
+The hysdn driver has been written by
+Werner Cornelius (werner@isdn4linux.de or werner@titro.de)
+for Hypercope GmbH Aachen Germany. Hypercope agreed to publish this driver
+under the GNU General Public License.
+
+The CAPI 2.0-support was added by Ulrich Albrecht (ualbrecht@hypercope.de)
+for Hypercope GmbH Aachen, Germany.
+
+
+ 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.
+
+.. Table of contents
+
+ 1. About the driver
+
+ 2. Loading/Unloading the driver
+
+ 3. Entries in the /proc filesystem
+
+ 4. The /proc/net/hysdn/cardconfX file
+
+ 5. The /proc/net/hysdn/cardlogX file
+
+ 6. Where to get additional info and help
+
+
+1. About the driver
+===================
+
+ The drivers/isdn/hysdn subdir contains a driver for HYPERCOPEs active
+ PCI isdn cards Champ, Ergo and Metro. To enable support for this cards
+ enable ISDN support in the kernel config and support for HYSDN cards in
+ the active cards submenu. The driver may only be compiled and used if
+ support for loadable modules and the process filesystem have been enabled.
+
+ These cards provide two different interfaces to the kernel. Without the
+ optional CAPI 2.0 support, they register as ethernet card. IP-routing
+ to a ISDN-destination is performed on the card itself. All necessary
+ handlers for various protocols like ppp and others as well as config info
+ and firmware may be fetched from Hypercopes WWW-Site www.hypercope.de.
+
+ With CAPI 2.0 support enabled, the card can also be used as a CAPI 2.0
+ compliant devices with either CAPI 2.0 applications
+ (check isdn4k-utils) or -using the capidrv module- as a regular
+ isdn4linux device. This is done via the same mechanism as with the
+ active AVM cards and in fact uses the same module.
+
+
+2. Loading/Unloading the driver
+===============================
+
+ The module has no command line parameters and auto detects up to 10 cards
+ in the id-range 0-9.
+ If a loaded driver shall be unloaded all open files in the /proc/net/hysdn
+ subdir need to be closed and all ethernet interfaces allocated by this
+ driver must be shut down. Otherwise the module counter will avoid a module
+ unload.
+
+ If you are using the CAPI 2.0-interface, make sure to load/modprobe the
+ kernelcapi-module first.
+
+ If you plan to use the capidrv-link to isdn4linux, make sure to load
+ capidrv.o after all modules using this driver (i.e. after hysdn and
+ any avm-specific modules).
+
+3. Entries in the /proc filesystem
+==================================
+
+ When the module has been loaded it adds the directory hysdn in the
+ /proc/net tree. This directory contains exactly 2 file entries for each
+ card. One is called cardconfX and the other cardlogX, where X is the
+ card id number from 0 to 9.
+ The cards are numbered in the order found in the PCI config data.
+
+4. The /proc/net/hysdn/cardconfX file
+=====================================
+
+ This file may be read to get by everyone to get info about the cards type,
+ actual state, available features and used resources.
+ The first 3 entries (id, bus and slot) are PCI info fields, the following
+ type field gives the information about the cards type:
+
+ - 4 -> Ergo card (server card with 2 b-chans)
+ - 5 -> Metro card (server card with 4 or 8 b-chans)
+ - 6 -> Champ card (client card with 2 b-chans)
+
+ The following 3 fields show the hardware assignments for irq, iobase and the
+ dual ported memory (dp-mem).
+
+ The fields b-chans and fax-chans announce the available card resources of
+ this types for the user.
+
+ The state variable indicates the actual drivers state for this card with the
+ following assignments.
+
+ - 0 -> card has not been booted since driver load
+ - 1 -> card booting is actually in progess
+ - 2 -> card is in an error state due to a previous boot failure
+ - 3 -> card is booted and active
+
+ And the last field (device) shows the name of the ethernet device assigned
+ to this card. Up to the first successful boot this field only shows a -
+ to tell that no net device has been allocated up to now. Once a net device
+ has been allocated it remains assigned to this card, even if a card is
+ rebooted and an boot error occurs.
+
+ Writing to the cardconfX file boots the card or transfers config lines to
+ the cards firmware. The type of data is automatically detected when the
+ first data is written. Only root has write access to this file.
+ The firmware boot files are normally called hyclient.pof for client cards
+ and hyserver.pof for server cards.
+ After successfully writing the boot file, complete config files or single
+ config lines may be copied to this file.
+ If an error occurs the return value given to the writing process has the
+ following additional codes (decimal):
+
+ ==== ============================================
+ 1000 Another process is currently bootng the card
+ 1001 Invalid firmware header
+ 1002 Boards dual-port RAM test failed
+ 1003 Internal firmware handler error
+ 1004 Boot image size invalid
+ 1005 First boot stage (bootstrap loader) failed
+ 1006 Second boot stage failure
+ 1007 Timeout waiting for card ready during boot
+ 1008 Operation only allowed in booted state
+ 1009 Config line too long
+ 1010 Invalid channel number
+ 1011 Timeout sending config data
+ ==== ============================================
+
+ Additional info about error reasons may be fetched from the log output.
+
+5. The /proc/net/hysdn/cardlogX file
+====================================
+
+ The cardlogX file entry may be opened multiple for reading by everyone to
+ get the cards and drivers log data. Card messages always start with the
+ keyword LOG. All other lines are output from the driver.
+ The driver log data may be redirected to the syslog by selecting the
+ appropriate bitmask. The cards log messages will always be send to this
+ interface but never to the syslog.
+
+ A root user may write a decimal or hex (with 0x) value t this file to select
+ desired output options. As mentioned above the cards log dat is always
+ written to the cardlog file independent of the following options only used
+ to check and debug the driver itself:
+
+ For example::
+
+ echo "0x34560078" > /proc/net/hysdn/cardlog0
+
+ to output the hex log mask 34560078 for card 0.
+
+ The written value is regarded as an unsigned 32-Bit value, bit ored for
+ desired output. The following bits are already assigned:
+
+ ========== ============================================================
+ 0x80000000 All driver log data is alternatively via syslog
+ 0x00000001 Log memory allocation errors
+ 0x00000010 Firmware load start and close are logged
+ 0x00000020 Log firmware record parser
+ 0x00000040 Log every firmware write actions
+ 0x00000080 Log all card related boot messages
+ 0x00000100 Output all config data sent for debugging purposes
+ 0x00000200 Only non comment config lines are shown wth channel
+ 0x00000400 Additional conf log output
+ 0x00001000 Log the asynchronous scheduler actions (config and log)
+ 0x00100000 Log all open and close actions to /proc/net/hysdn/card files
+ 0x00200000 Log all actions from /proc file entries
+ 0x00010000 Log network interface init and deinit
+ ========== ============================================================
+
+6. Where to get additional info and help
+========================================
+
+ If you have any problems concerning the driver or configuration contact
+ the Hypercope support team (support@hypercope.de) and or the authors
+ Werner Cornelius (werner@isdn4linux or cornelius@titro.de) or
+ Ulrich Albrecht (ualbrecht@hypercope.de).
diff --git a/marvell/linux/Documentation/isdn/index.rst b/marvell/linux/Documentation/isdn/index.rst
new file mode 100644
index 0000000..407e74b7
--- /dev/null
+++ b/marvell/linux/Documentation/isdn/index.rst
@@ -0,0 +1,24 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+====
+ISDN
+====
+
+.. toctree::
+ :maxdepth: 2
+
+ interface_capi
+
+ avmb1
+ gigaset
+ hysdn
+ m_isdn
+
+ credits
+
+.. only:: subproject and html
+
+ Indices
+ =======
+
+ * :ref:`genindex`
diff --git a/marvell/linux/Documentation/isdn/interface_capi.rst b/marvell/linux/Documentation/isdn/interface_capi.rst
new file mode 100644
index 0000000..01a4b5a
--- /dev/null
+++ b/marvell/linux/Documentation/isdn/interface_capi.rst
@@ -0,0 +1,407 @@
+=========================================
+Kernel CAPI Interface to Hardware Drivers
+=========================================
+
+1. Overview
+===========
+
+From the CAPI 2.0 specification:
+COMMON-ISDN-API (CAPI) is an application programming interface standard used
+to access ISDN equipment connected to basic rate interfaces (BRI) and primary
+rate interfaces (PRI).
+
+Kernel CAPI operates as a dispatching layer between CAPI applications and CAPI
+hardware drivers. Hardware drivers register ISDN devices (controllers, in CAPI
+lingo) with Kernel CAPI to indicate their readiness to provide their service
+to CAPI applications. CAPI applications also register with Kernel CAPI,
+requesting association with a CAPI device. Kernel CAPI then dispatches the
+application registration to an available device, forwarding it to the
+corresponding hardware driver. Kernel CAPI then forwards CAPI messages in both
+directions between the application and the hardware driver.
+
+Format and semantics of CAPI messages are specified in the CAPI 2.0 standard.
+This standard is freely available from https://www.capi.org.
+
+
+2. Driver and Device Registration
+=================================
+
+CAPI drivers optionally register themselves with Kernel CAPI by calling the
+Kernel CAPI function register_capi_driver() with a pointer to a struct
+capi_driver. This structure must be filled with the name and revision of the
+driver, and optionally a pointer to a callback function, add_card(). The
+registration can be revoked by calling the function unregister_capi_driver()
+with a pointer to the same struct capi_driver.
+
+CAPI drivers must register each of the ISDN devices they control with Kernel
+CAPI by calling the Kernel CAPI function attach_capi_ctr() with a pointer to a
+struct capi_ctr before they can be used. This structure must be filled with
+the names of the driver and controller, and a number of callback function
+pointers which are subsequently used by Kernel CAPI for communicating with the
+driver. The registration can be revoked by calling the function
+detach_capi_ctr() with a pointer to the same struct capi_ctr.
+
+Before the device can be actually used, the driver must fill in the device
+information fields 'manu', 'version', 'profile' and 'serial' in the capi_ctr
+structure of the device, and signal its readiness by calling capi_ctr_ready().
+From then on, Kernel CAPI may call the registered callback functions for the
+device.
+
+If the device becomes unusable for any reason (shutdown, disconnect ...), the
+driver has to call capi_ctr_down(). This will prevent further calls to the
+callback functions by Kernel CAPI.
+
+
+3. Application Registration and Communication
+=============================================
+
+Kernel CAPI forwards registration requests from applications (calls to CAPI
+operation CAPI_REGISTER) to an appropriate hardware driver by calling its
+register_appl() callback function. A unique Application ID (ApplID, u16) is
+allocated by Kernel CAPI and passed to register_appl() along with the
+parameter structure provided by the application. This is analogous to the
+open() operation on regular files or character devices.
+
+After a successful return from register_appl(), CAPI messages from the
+application may be passed to the driver for the device via calls to the
+send_message() callback function. Conversely, the driver may call Kernel
+CAPI's capi_ctr_handle_message() function to pass a received CAPI message to
+Kernel CAPI for forwarding to an application, specifying its ApplID.
+
+Deregistration requests (CAPI operation CAPI_RELEASE) from applications are
+forwarded as calls to the release_appl() callback function, passing the same
+ApplID as with register_appl(). After return from release_appl(), no CAPI
+messages for that application may be passed to or from the device anymore.
+
+
+4. Data Structures
+==================
+
+4.1 struct capi_driver
+----------------------
+
+This structure describes a Kernel CAPI driver itself. It is used in the
+register_capi_driver() and unregister_capi_driver() functions, and contains
+the following non-private fields, all to be set by the driver before calling
+register_capi_driver():
+
+``char name[32]``
+ the name of the driver, as a zero-terminated ASCII string
+``char revision[32]``
+ the revision number of the driver, as a zero-terminated ASCII string
+``int (*add_card)(struct capi_driver *driver, capicardparams *data)``
+ a callback function pointer (may be NULL)
+
+
+4.2 struct capi_ctr
+-------------------
+
+This structure describes an ISDN device (controller) handled by a Kernel CAPI
+driver. After registration via the attach_capi_ctr() function it is passed to
+all controller specific lower layer interface and callback functions to
+identify the controller to operate on.
+
+It contains the following non-private fields:
+
+to be set by the driver before calling attach_capi_ctr():
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+``struct module *owner``
+ pointer to the driver module owning the device
+
+``void *driverdata``
+ an opaque pointer to driver specific data, not touched by Kernel CAPI
+
+``char name[32]``
+ the name of the controller, as a zero-terminated ASCII string
+
+``char *driver_name``
+ the name of the driver, as a zero-terminated ASCII string
+
+``int (*load_firmware)(struct capi_ctr *ctrlr, capiloaddata *ldata)``
+ (optional) pointer to a callback function for sending firmware and
+ configuration data to the device
+
+ The function may return before the operation has completed.
+
+ Completion must be signalled by a call to capi_ctr_ready().
+
+ Return value: 0 on success, error code on error
+ Called in process context.
+
+``void (*reset_ctr)(struct capi_ctr *ctrlr)``
+ (optional) pointer to a callback function for stopping the device,
+ releasing all registered applications
+
+ The function may return before the operation has completed.
+
+ Completion must be signalled by a call to capi_ctr_down().
+
+ Called in process context.
+
+``void (*register_appl)(struct capi_ctr *ctrlr, u16 applid, capi_register_params *rparam)``
+ pointers to callback function for registration of
+ applications with the device
+
+ Calls to these functions are serialized by Kernel CAPI so that only
+ one call to any of them is active at any time.
+
+``void (*release_appl)(struct capi_ctr *ctrlr, u16 applid)``
+ pointers to callback functions deregistration of
+ applications with the device
+
+ Calls to these functions are serialized by Kernel CAPI so that only
+ one call to any of them is active at any time.
+
+``u16 (*send_message)(struct capi_ctr *ctrlr, struct sk_buff *skb)``
+ pointer to a callback function for sending a CAPI message to the
+ device
+
+ Return value: CAPI error code
+
+ If the method returns 0 (CAPI_NOERROR) the driver has taken ownership
+ of the skb and the caller may no longer access it. If it returns a
+ non-zero (error) value then ownership of the skb returns to the caller
+ who may reuse or free it.
+
+ The return value should only be used to signal problems with respect
+ to accepting or queueing the message. Errors occurring during the
+ actual processing of the message should be signaled with an
+ appropriate reply message.
+
+ May be called in process or interrupt context.
+
+ Calls to this function are not serialized by Kernel CAPI, ie. it must
+ be prepared to be re-entered.
+
+``char *(*procinfo)(struct capi_ctr *ctrlr)``
+ pointer to a callback function returning the entry for the device in
+ the CAPI controller info table, /proc/capi/controller
+
+``const struct file_operations *proc_fops``
+ pointers to callback functions for the device's proc file
+ system entry, /proc/capi/controllers/<n>; pointer to the device's
+ capi_ctr structure is available from struct proc_dir_entry::data
+ which is available from struct inode.
+
+Note:
+ Callback functions except send_message() are never called in interrupt
+ context.
+
+to be filled in before calling capi_ctr_ready():
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+``u8 manu[CAPI_MANUFACTURER_LEN]``
+ value to return for CAPI_GET_MANUFACTURER
+
+``capi_version version``
+ value to return for CAPI_GET_VERSION
+
+``capi_profile profile``
+ value to return for CAPI_GET_PROFILE
+
+``u8 serial[CAPI_SERIAL_LEN]``
+ value to return for CAPI_GET_SERIAL
+
+
+4.3 SKBs
+--------
+
+CAPI messages are passed between Kernel CAPI and the driver via send_message()
+and capi_ctr_handle_message(), stored in the data portion of a socket buffer
+(skb). Each skb contains a single CAPI message coded according to the CAPI 2.0
+standard.
+
+For the data transfer messages, DATA_B3_REQ and DATA_B3_IND, the actual
+payload data immediately follows the CAPI message itself within the same skb.
+The Data and Data64 parameters are not used for processing. The Data64
+parameter may be omitted by setting the length field of the CAPI message to 22
+instead of 30.
+
+
+4.4 The _cmsg Structure
+-----------------------
+
+(declared in <linux/isdn/capiutil.h>)
+
+The _cmsg structure stores the contents of a CAPI 2.0 message in an easily
+accessible form. It contains members for all possible CAPI 2.0 parameters,
+including subparameters of the Additional Info and B Protocol structured
+parameters, with the following exceptions:
+
+* second Calling party number (CONNECT_IND)
+
+* Data64 (DATA_B3_REQ and DATA_B3_IND)
+
+* Sending complete (subparameter of Additional Info, CONNECT_REQ and INFO_REQ)
+
+* Global Configuration (subparameter of B Protocol, CONNECT_REQ, CONNECT_RESP
+ and SELECT_B_PROTOCOL_REQ)
+
+Only those parameters appearing in the message type currently being processed
+are actually used. Unused members should be set to zero.
+
+Members are named after the CAPI 2.0 standard names of the parameters they
+represent. See <linux/isdn/capiutil.h> for the exact spelling. Member data
+types are:
+
+=========== =================================================================
+u8 for CAPI parameters of type 'byte'
+
+u16 for CAPI parameters of type 'word'
+
+u32 for CAPI parameters of type 'dword'
+
+_cstruct for CAPI parameters of type 'struct'
+ The member is a pointer to a buffer containing the parameter in
+ CAPI encoding (length + content). It may also be NULL, which will
+ be taken to represent an empty (zero length) parameter.
+ Subparameters are stored in encoded form within the content part.
+
+_cmstruct alternative representation for CAPI parameters of type 'struct'
+ (used only for the 'Additional Info' and 'B Protocol' parameters)
+ The representation is a single byte containing one of the values:
+ CAPI_DEFAULT: The parameter is empty/absent.
+ CAPI_COMPOSE: The parameter is present.
+ Subparameter values are stored individually in the corresponding
+ _cmsg structure members.
+=========== =================================================================
+
+Functions capi_cmsg2message() and capi_message2cmsg() are provided to convert
+messages between their transport encoding described in the CAPI 2.0 standard
+and their _cmsg structure representation. Note that capi_cmsg2message() does
+not know or check the size of its destination buffer. The caller must make
+sure it is big enough to accommodate the resulting CAPI message.
+
+
+5. Lower Layer Interface Functions
+==================================
+
+(declared in <linux/isdn/capilli.h>)
+
+::
+
+ void register_capi_driver(struct capi_driver *drvr)
+ void unregister_capi_driver(struct capi_driver *drvr)
+
+register/unregister a driver with Kernel CAPI
+
+::
+
+ int attach_capi_ctr(struct capi_ctr *ctrlr)
+ int detach_capi_ctr(struct capi_ctr *ctrlr)
+
+register/unregister a device (controller) with Kernel CAPI
+
+::
+
+ void capi_ctr_ready(struct capi_ctr *ctrlr)
+ void capi_ctr_down(struct capi_ctr *ctrlr)
+
+signal controller ready/not ready
+
+::
+
+ void capi_ctr_suspend_output(struct capi_ctr *ctrlr)
+ void capi_ctr_resume_output(struct capi_ctr *ctrlr)
+
+signal suspend/resume
+
+::
+
+ void capi_ctr_handle_message(struct capi_ctr * ctrlr, u16 applid,
+ struct sk_buff *skb)
+
+pass a received CAPI message to Kernel CAPI
+for forwarding to the specified application
+
+
+6. Helper Functions and Macros
+==============================
+
+Library functions (from <linux/isdn/capilli.h>):
+
+::
+
+ void capilib_new_ncci(struct list_head *head, u16 applid,
+ u32 ncci, u32 winsize)
+ void capilib_free_ncci(struct list_head *head, u16 applid, u32 ncci)
+ void capilib_release_appl(struct list_head *head, u16 applid)
+ void capilib_release(struct list_head *head)
+ void capilib_data_b3_conf(struct list_head *head, u16 applid,
+ u32 ncci, u16 msgid)
+ u16 capilib_data_b3_req(struct list_head *head, u16 applid,
+ u32 ncci, u16 msgid)
+
+
+Macros to extract/set element values from/in a CAPI message header
+(from <linux/isdn/capiutil.h>):
+
+====================== ============================= ====================
+Get Macro Set Macro Element (Type)
+====================== ============================= ====================
+CAPIMSG_LEN(m) CAPIMSG_SETLEN(m, len) Total Length (u16)
+CAPIMSG_APPID(m) CAPIMSG_SETAPPID(m, applid) ApplID (u16)
+CAPIMSG_COMMAND(m) CAPIMSG_SETCOMMAND(m,cmd) Command (u8)
+CAPIMSG_SUBCOMMAND(m) CAPIMSG_SETSUBCOMMAND(m, cmd) Subcommand (u8)
+CAPIMSG_CMD(m) - Command*256
+ + Subcommand (u16)
+CAPIMSG_MSGID(m) CAPIMSG_SETMSGID(m, msgid) Message Number (u16)
+
+CAPIMSG_CONTROL(m) CAPIMSG_SETCONTROL(m, contr) Controller/PLCI/NCCI
+ (u32)
+CAPIMSG_DATALEN(m) CAPIMSG_SETDATALEN(m, len) Data Length (u16)
+====================== ============================= ====================
+
+
+Library functions for working with _cmsg structures
+(from <linux/isdn/capiutil.h>):
+
+``unsigned capi_cmsg2message(_cmsg *cmsg, u8 *msg)``
+ Assembles a CAPI 2.0 message from the parameters in ``*cmsg``,
+ storing the result in ``*msg``.
+
+``unsigned capi_message2cmsg(_cmsg *cmsg, u8 *msg)``
+ Disassembles the CAPI 2.0 message in ``*msg``, storing the parameters
+ in ``*cmsg``.
+
+``unsigned capi_cmsg_header(_cmsg *cmsg, u16 ApplId, u8 Command, u8 Subcommand, u16 Messagenumber, u32 Controller)``
+ Fills the header part and address field of the _cmsg structure ``*cmsg``
+ with the given values, zeroing the remainder of the structure so only
+ parameters with non-default values need to be changed before sending
+ the message.
+
+``void capi_cmsg_answer(_cmsg *cmsg)``
+ Sets the low bit of the Subcommand field in ``*cmsg``, thereby
+ converting ``_REQ`` to ``_CONF`` and ``_IND`` to ``_RESP``.
+
+``char *capi_cmd2str(u8 Command, u8 Subcommand)``
+ Returns the CAPI 2.0 message name corresponding to the given command
+ and subcommand values, as a static ASCII string. The return value may
+ be NULL if the command/subcommand is not one of those defined in the
+ CAPI 2.0 standard.
+
+
+7. Debugging
+============
+
+The module kernelcapi has a module parameter showcapimsgs controlling some
+debugging output produced by the module. It can only be set when the module is
+loaded, via a parameter "showcapimsgs=<n>" to the modprobe command, either on
+the command line or in the configuration file.
+
+If the lowest bit of showcapimsgs is set, kernelcapi logs controller and
+application up and down events.
+
+In addition, every registered CAPI controller has an associated traceflag
+parameter controlling how CAPI messages sent from and to tha controller are
+logged. The traceflag parameter is initialized with the value of the
+showcapimsgs parameter when the controller is registered, but can later be
+changed via the MANUFACTURER_REQ command KCAPI_CMD_TRACE.
+
+If the value of traceflag is non-zero, CAPI messages are logged.
+DATA_B3 messages are only logged if the value of traceflag is > 2.
+
+If the lowest bit of traceflag is set, only the command/subcommand and message
+length are logged. Otherwise, kernelcapi logs a readable representation of
+the entire message.
diff --git a/marvell/linux/Documentation/isdn/m_isdn.rst b/marvell/linux/Documentation/isdn/m_isdn.rst
new file mode 100644
index 0000000..9957de3
--- /dev/null
+++ b/marvell/linux/Documentation/isdn/m_isdn.rst
@@ -0,0 +1,9 @@
+============
+mISDN Driver
+============
+
+mISDN is a new modular ISDN driver, in the long term it should replace
+the old I4L driver architecture for passiv ISDN cards.
+It was designed to allow a broad range of applications and interfaces
+but only have the basic function in kernel, the interface to the user
+space is based on sockets with a own address family AF_ISDN.