summaryrefslogtreecommitdiff
path: root/Documentation
diff options
context:
space:
mode:
Diffstat (limited to 'Documentation')
-rw-r--r--Documentation/ABI/testing/sysfs-bus-iio13
-rw-r--r--Documentation/ABI/testing/sysfs-bus-iio-dma-buffer19
-rw-r--r--Documentation/devicetree/bindings/iio/accel/adi,adis16240.yaml49
-rw-r--r--Documentation/devicetree/bindings/iio/accel/bma180.txt7
-rw-r--r--Documentation/devicetree/bindings/iio/accel/bosch,bma400.yaml54
-rw-r--r--Documentation/devicetree/bindings/iio/accel/kionix,kxcjk1013.txt7
-rw-r--r--Documentation/devicetree/bindings/iio/adc/adi,ad7091r5.yaml54
-rw-r--r--Documentation/devicetree/bindings/iio/adc/lltc,ltc2496.yaml47
-rw-r--r--Documentation/devicetree/bindings/iio/adc/sigma-delta-modulator.txt13
-rw-r--r--Documentation/devicetree/bindings/iio/adc/sigma-delta-modulator.yaml37
-rw-r--r--Documentation/devicetree/bindings/iio/imu/adi,adis16480.txt1
-rw-r--r--Documentation/devicetree/bindings/iio/pressure/asc,dlhl60d.yaml51
-rw-r--r--Documentation/devicetree/bindings/iio/proximity/parallax-ping.yaml51
-rw-r--r--Documentation/devicetree/bindings/iio/temperature/maxim_thermocouple.txt7
-rw-r--r--Documentation/devicetree/bindings/vendor-prefixes.yaml4
-rw-r--r--Documentation/isdn/avmb1.rst246
-rw-r--r--Documentation/isdn/gigaset.rst465
-rw-r--r--Documentation/isdn/hysdn.rst196
-rw-r--r--Documentation/isdn/index.rst3
-rw-r--r--Documentation/isdn/interface_capi.rst71
-rw-r--r--Documentation/userspace-api/ioctl/ioctl-number.rst1
21 files changed, 397 insertions, 999 deletions
diff --git a/Documentation/ABI/testing/sysfs-bus-iio b/Documentation/ABI/testing/sysfs-bus-iio
index faaa2166d741..d3e53a6d8331 100644
--- a/Documentation/ABI/testing/sysfs-bus-iio
+++ b/Documentation/ABI/testing/sysfs-bus-iio
@@ -1726,3 +1726,16 @@ Contact: linux-iio@vger.kernel.org
Description:
List of valid periods (in seconds) for which the light intensity
must be above the threshold level before interrupt is asserted.
+
+What: /sys/bus/iio/devices/iio:deviceX/in_filter_notch_center_frequency
+KernelVersion: 5.5
+Contact: linux-iio@vger.kernel.org
+Description:
+ Center frequency in Hz for a notch filter. Used i.e. for line
+ noise suppression.
+
+What: /sys/bus/iio/devices/iio:deviceX/in_temp_thermocouple_type
+KernelVersion: 5.5
+Contact: linux-iio@vger.kernel.org
+Description:
+ One of the following thermocouple types: B, E, J, K, N, R, S, T.
diff --git a/Documentation/ABI/testing/sysfs-bus-iio-dma-buffer b/Documentation/ABI/testing/sysfs-bus-iio-dma-buffer
new file mode 100644
index 000000000000..d526e6571001
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-bus-iio-dma-buffer
@@ -0,0 +1,19 @@
+What: /sys/bus/iio/devices/iio:deviceX/buffer/length_align_bytes
+KernelVersion: 5.4
+Contact: linux-iio@vger.kernel.org
+Description:
+ DMA buffers tend to have a alignment requirement for the
+ buffers. If this alignment requirement is not met samples might
+ be dropped from the buffer.
+
+ This property reports the alignment requirements in bytes.
+ This means that the buffer size in bytes needs to be a integer
+ multiple of the number reported by this file.
+
+ The alignment requirements in number of sample sets will depend
+ on the enabled channels and the bytes per channel. This means
+ that the alignment requirement in samples sets might change
+ depending on which and how many channels are enabled. Whereas
+ the alignment requirement reported in bytes by this property
+ will remain static and does not depend on which channels are
+ enabled.
diff --git a/Documentation/devicetree/bindings/iio/accel/adi,adis16240.yaml b/Documentation/devicetree/bindings/iio/accel/adi,adis16240.yaml
new file mode 100644
index 000000000000..4147f02b5e3c
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/accel/adi,adis16240.yaml
@@ -0,0 +1,49 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/accel/adi,adis16240.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: ADIS16240 Programmable Impact Sensor and Recorder driver
+
+maintainers:
+ - Alexandru Ardelean <alexandru.ardelean@analog.com>
+
+description: |
+ ADIS16240 Programmable Impact Sensor and Recorder driver that supports
+ SPI interface.
+ https://www.analog.com/en/products/adis16240.html
+
+properties:
+ compatible:
+ enum:
+ - adi,adis16240
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - interrupts
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+ spi0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ /* Example for a SPI device node */
+ accelerometer@0 {
+ compatible = "adi,adis16240";
+ reg = <0>;
+ spi-max-frequency = <2500000>;
+ interrupt-parent = <&gpio0>;
+ interrupts = <0 IRQ_TYPE_LEVEL_HIGH>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/iio/accel/bma180.txt b/Documentation/devicetree/bindings/iio/accel/bma180.txt
index 3b25b4c4d446..f53237270b32 100644
--- a/Documentation/devicetree/bindings/iio/accel/bma180.txt
+++ b/Documentation/devicetree/bindings/iio/accel/bma180.txt
@@ -1,11 +1,14 @@
-* Bosch BMA180 / BMA250 triaxial acceleration sensor
+* Bosch BMA180 / BMA25x triaxial acceleration sensor
http://omapworld.com/BMA180_111_1002839.pdf
http://ae-bst.resource.bosch.com/media/products/dokumente/bma250/bst-bma250-ds002-05.pdf
Required properties:
- - compatible : should be "bosch,bma180" or "bosch,bma250"
+ - compatible : should be one of:
+ "bosch,bma180"
+ "bosch,bma250"
+ "bosch,bma254"
- reg : the I2C address of the sensor
Optional properties:
diff --git a/Documentation/devicetree/bindings/iio/accel/bosch,bma400.yaml b/Documentation/devicetree/bindings/iio/accel/bosch,bma400.yaml
new file mode 100644
index 000000000000..c1c6d6f223cf
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/accel/bosch,bma400.yaml
@@ -0,0 +1,54 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/accel/bosch,bma400.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Bosch BMA400 triaxial acceleration sensor
+
+maintainers:
+ - Dan Robertson <dan@dlrobertson.com>
+
+description: |
+ Acceleration and temperature iio sensors with an i2c interface
+
+ Specifications about the sensor can be found at:
+ https://ae-bst.resource.bosch.com/media/_tech/media/datasheets/BST-BMA400-DS000.pdf
+
+properties:
+ compatible:
+ enum:
+ - bosch,bma400
+
+ reg:
+ maxItems: 1
+
+ vdd-supply:
+ description: phandle to the regulator that provides power to the accelerometer
+
+ vddio-supply:
+ description: phandle to the regulator that provides power to the sensor's IO
+
+ interrupts:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ accelerometer@14 {
+ compatible = "bosch,bma400";
+ reg = <0x14>;
+ vdd-supply = <&vdd>;
+ vddio-supply = <&vddio>;
+ interrupt-parent = <&gpio0>;
+ interrupts = <0 IRQ_TYPE_LEVEL_HIGH>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/iio/accel/kionix,kxcjk1013.txt b/Documentation/devicetree/bindings/iio/accel/kionix,kxcjk1013.txt
index eb76a02e2a82..ce950e162d5d 100644
--- a/Documentation/devicetree/bindings/iio/accel/kionix,kxcjk1013.txt
+++ b/Documentation/devicetree/bindings/iio/accel/kionix,kxcjk1013.txt
@@ -9,9 +9,16 @@ Required properties:
"kionix,kxtf9"
- reg: i2c slave address
+Optional properties:
+
+ - mount-matrix: an optional 3x3 mounting rotation matrix
+
Example:
kxtf9@f {
compatible = "kionix,kxtf9";
reg = <0x0F>;
+ mount-matrix = "0", "1", "0",
+ "1", "0", "0",
+ "0", "0", "1";
};
diff --git a/Documentation/devicetree/bindings/iio/adc/adi,ad7091r5.yaml b/Documentation/devicetree/bindings/iio/adc/adi,ad7091r5.yaml
new file mode 100644
index 000000000000..31ffa275f5fa
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/adc/adi,ad7091r5.yaml
@@ -0,0 +1,54 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/adc/adi,ad7091r5.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Analog Devices AD7091R5 4-Channel 12-Bit ADC
+
+maintainers:
+ - Beniamin Bia <beniamin.bia@analog.com>
+
+description: |
+ Analog Devices AD7091R5 4-Channel 12-Bit ADC
+ https://www.analog.com/media/en/technical-documentation/data-sheets/ad7091r-5.pdf
+
+properties:
+ compatible:
+ enum:
+ - adi,ad7091r5
+
+ reg:
+ maxItems: 1
+
+ vref-supply:
+ description:
+ Phandle to the vref power supply
+
+ interrupts:
+ maxItems: 1
+
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ adc@2f {
+ compatible = "adi,ad7091r5";
+ reg = <0x2f>;
+
+ interrupts = <25 IRQ_TYPE_EDGE_FALLING>;
+ interrupt-parent = <&gpio>;
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/iio/adc/lltc,ltc2496.yaml b/Documentation/devicetree/bindings/iio/adc/lltc,ltc2496.yaml
new file mode 100644
index 000000000000..59009997dca0
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/adc/lltc,ltc2496.yaml
@@ -0,0 +1,47 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/adc/lltc,ltc2496.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Linear Technology / Analog Devices LTC2496 ADC
+
+maintainers:
+ - Lars-Peter Clausen <lars@metafoo.de>
+ - Michael Hennerich <Michael.Hennerich@analog.com>
+ - Stefan Popa <stefan.popa@analog.com>
+
+properties:
+ compatible:
+ enum:
+ - lltc,ltc2496
+
+ vref-supply:
+ description: phandle to an external regulator providing the reference voltage
+ allOf:
+ - $ref: /schemas/types.yaml#/definitions/phandle
+
+ reg:
+ description: spi chipselect number according to the usual spi bindings
+
+ spi-max-frequency:
+ description: maximal spi bus frequency supported
+
+required:
+ - compatible
+ - vref-supply
+ - reg
+
+examples:
+ - |
+ spi {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ adc@0 {
+ compatible = "lltc,ltc2496";
+ reg = <0>;
+ vref-supply = <&ltc2496_reg>;
+ spi-max-frequency = <2000000>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/iio/adc/sigma-delta-modulator.txt b/Documentation/devicetree/bindings/iio/adc/sigma-delta-modulator.txt
deleted file mode 100644
index 59b92cd32552..000000000000
--- a/Documentation/devicetree/bindings/iio/adc/sigma-delta-modulator.txt
+++ /dev/null
@@ -1,13 +0,0 @@
-Device-Tree bindings for sigma delta modulator
-
-Required properties:
-- compatible: should be "ads1201", "sd-modulator". "sd-modulator" can be use
- as a generic SD modulator if modulator not specified in compatible list.
-- #io-channel-cells = <0>: See the IIO bindings section "IIO consumers".
-
-Example node:
-
- ads1202: adc {
- compatible = "sd-modulator";
- #io-channel-cells = <0>;
- };
diff --git a/Documentation/devicetree/bindings/iio/adc/sigma-delta-modulator.yaml b/Documentation/devicetree/bindings/iio/adc/sigma-delta-modulator.yaml
new file mode 100644
index 000000000000..a390343d0c2a
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/adc/sigma-delta-modulator.yaml
@@ -0,0 +1,37 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/adc/sigma-delta-modulator.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Device-Tree bindings for sigma delta modulator
+
+maintainers:
+ - Arnaud Pouliquen <arnaud.pouliquen@st.com>
+
+properties:
+ compatible:
+ description: |
+ "sd-modulator" can be used as a generic SD modulator,
+ if the modulator is not specified in the compatible list.
+ enum:
+ - sd-modulator
+ - ads1201
+
+ '#io-channel-cells':
+ const: 0
+
+required:
+ - compatible
+ - '#io-channel-cells'
+
+additionalProperties: false
+
+examples:
+ - |
+ ads1202: adc {
+ compatible = "sd-modulator";
+ #io-channel-cells = <0>;
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/iio/imu/adi,adis16480.txt b/Documentation/devicetree/bindings/iio/imu/adi,adis16480.txt
index ed7783f45233..cd903a1d880d 100644
--- a/Documentation/devicetree/bindings/iio/imu/adi,adis16480.txt
+++ b/Documentation/devicetree/bindings/iio/imu/adi,adis16480.txt
@@ -8,6 +8,7 @@ Required properties for the ADIS16480:
* "adi,adis16480"
* "adi,adis16485"
* "adi,adis16488"
+ * "adi,adis16490"
* "adi,adis16495-1"
* "adi,adis16495-2"
* "adi,adis16495-3"
diff --git a/Documentation/devicetree/bindings/iio/pressure/asc,dlhl60d.yaml b/Documentation/devicetree/bindings/iio/pressure/asc,dlhl60d.yaml
new file mode 100644
index 000000000000..9f5ca9c42025
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/pressure/asc,dlhl60d.yaml
@@ -0,0 +1,51 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/pressure/asc,dlhl60d.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: All Sensors DLH series low voltage digital pressure sensors
+
+maintainers:
+ - Tomislav Denis <tomislav.denis@avl.com>
+
+description: |
+ Bindings for the All Sensors DLH series pressure sensors.
+
+ Specifications about the sensors can be found at:
+ http://www.allsensors.com/cad/DS-0355_Rev_B.PDF
+
+properties:
+ compatible:
+ enum:
+ - asc,dlhl60d
+ - asc,dlhl60g
+
+ reg:
+ description: I2C device address
+ maxItems: 1
+
+ interrupts:
+ description: interrupt mapping for EOC(data ready) pin
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ i2c0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ pressure@29 {
+ compatible = "asc,dlhl60d";
+ reg = <0x29>;
+ interrupt-parent = <&gpio0>;
+ interrupts = <10 IRQ_TYPE_EDGE_RISING>;
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/iio/proximity/parallax-ping.yaml b/Documentation/devicetree/bindings/iio/proximity/parallax-ping.yaml
new file mode 100644
index 000000000000..a079c9921af6
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/proximity/parallax-ping.yaml
@@ -0,0 +1,51 @@
+# SPDX-License-Identifier: (GPL-2.0-or-later OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/proximity/parallax-ping.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Parallax PING))) and LaserPING range finder
+
+maintainers:
+ - Andreas Klinger <ak@it-klinger.de>
+
+description: |
+ Bit-banging driver using one GPIO:
+ - ping-gpios is raised by the driver to start measurement
+ - direction of ping-gpio is then switched into input with an interrupt
+ for receiving distance value as PWM signal
+
+ Specifications about the devices can be found at:
+ http://parallax.com/sites/default/files/downloads/28041-LaserPING-2m-Rangefinder-Guide.pdf
+ http://parallax.com/sites/default/files/downloads/28015-PING-Documentation-v1.6.pdf
+
+properties:
+ compatible:
+ enum:
+ - parallax,ping
+ - parallax,laserping
+
+ ping-gpios:
+ description:
+ Definition of the GPIO for the triggering and echo (output and input)
+ This GPIO is set for about 5 us by the driver to tell the device it
+ should initiate the measurement cycle. Afterwards the GPIO is switched
+ to input direction with an interrupt. The device sets it and the
+ length of the input signal corresponds to the measured distance.
+ It needs to be an GPIO which is able to deliver an interrupt because
+ the time between two interrupts is measured in the driver.
+ See Documentation/devicetree/bindings/gpio/gpio.txt for information
+ on how to specify a consumer gpio.
+ maxItems: 1
+
+required:
+ - compatible
+ - ping-gpios
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+ proximity {
+ compatible = "parallax,laserping";
+ ping-gpios = <&gpio0 26 GPIO_ACTIVE_HIGH>;
+ };
diff --git a/Documentation/devicetree/bindings/iio/temperature/maxim_thermocouple.txt b/Documentation/devicetree/bindings/iio/temperature/maxim_thermocouple.txt
index 28bc5c4d965b..bb85cd0e039c 100644
--- a/Documentation/devicetree/bindings/iio/temperature/maxim_thermocouple.txt
+++ b/Documentation/devicetree/bindings/iio/temperature/maxim_thermocouple.txt
@@ -5,7 +5,10 @@ Maxim thermocouple support
Required properties:
- - compatible: must be "maxim,max31855" or "maxim,max6675"
+ - compatible: must be "maxim,max6675" or one of the following:
+ "maxim,max31855k", "maxim,max31855j", "maxim,max31855n",
+ "maxim,max31855s", "maxim,max31855t", "maxim,max31855e",
+ "maxim,max31855r"; the generic "max,max31855" is deprecated.
- reg: SPI chip select number for the device
- spi-max-frequency: must be 4300000
- spi-cpha: must be defined for max6675 to enable SPI mode 1
@@ -15,7 +18,7 @@ Required properties:
Example:
max31855@0 {
- compatible = "maxim,max31855";
+ compatible = "maxim,max31855k";
reg = <0>;
spi-max-frequency = <4300000>;
};
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml
index 9cb3bc683db7..315ebac520b3 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.yaml
+++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml
@@ -109,6 +109,8 @@ patternProperties:
description: Artesyn Embedded Technologies Inc.
"^asahi-kasei,.*":
description: Asahi Kasei Corp.
+ "^asc,.*":
+ description: All Sensors Corporation
"^aspeed,.*":
description: ASPEED Technology Inc.
"^asus,.*":
@@ -717,6 +719,8 @@ patternProperties:
description: Panasonic Corporation
"^parade,.*":
description: Parade Technologies Inc.
+ "^parallax,.*":
+ description: Parallax Inc.
"^pda,.*":
description: Precision Design Associates, Inc.
"^pericom,.*":
diff --git a/Documentation/isdn/avmb1.rst b/Documentation/isdn/avmb1.rst
deleted file mode 100644
index de3961e67553..000000000000
--- a/Documentation/isdn/avmb1.rst
+++ /dev/null
@@ -1,246 +0,0 @@
-================================
-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/Documentation/isdn/gigaset.rst b/Documentation/isdn/gigaset.rst
deleted file mode 100644
index 98b4ec521c51..000000000000
--- a/Documentation/isdn/gigaset.rst
+++ /dev/null
@@ -1,465 +0,0 @@
-==========================
-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/Documentation/isdn/hysdn.rst b/Documentation/isdn/hysdn.rst
deleted file mode 100644
index 0a168d1cbffc..000000000000
--- a/Documentation/isdn/hysdn.rst
+++ /dev/null
@@ -1,196 +0,0 @@
-============
-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/Documentation/isdn/index.rst b/Documentation/isdn/index.rst
index 407e74b78372..9622939fa526 100644
--- a/Documentation/isdn/index.rst
+++ b/Documentation/isdn/index.rst
@@ -9,9 +9,6 @@ ISDN
interface_capi
- avmb1
- gigaset
- hysdn
m_isdn
credits
diff --git a/Documentation/isdn/interface_capi.rst b/Documentation/isdn/interface_capi.rst
index 01a4b5ade9a4..fe2421444b76 100644
--- a/Documentation/isdn/interface_capi.rst
+++ b/Documentation/isdn/interface_capi.rst
@@ -26,13 +26,6 @@ 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
@@ -89,9 +82,6 @@ register_capi_driver():
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
-------------------
@@ -178,12 +168,6 @@ to be set by the driver before calling attach_capi_ctr():
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.
@@ -267,25 +251,10 @@ _cmstruct alternative representation for CAPI parameters of type 'struct'
_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)
@@ -302,13 +271,6 @@ 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)
@@ -319,21 +281,6 @@ 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>):
@@ -357,24 +304,6 @@ 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
diff --git a/Documentation/userspace-api/ioctl/ioctl-number.rst b/Documentation/userspace-api/ioctl/ioctl-number.rst
index 4ef86433bd67..2e91370dc159 100644
--- a/Documentation/userspace-api/ioctl/ioctl-number.rst
+++ b/Documentation/userspace-api/ioctl/ioctl-number.rst
@@ -132,7 +132,6 @@ Code Seq# Include File Comments
'F' 80-8F linux/arcfb.h conflict!
'F' DD video/sstfb.h conflict!
'G' 00-3F drivers/misc/sgi-gru/grulib.h conflict!
-'G' 00-0F linux/gigaset_dev.h conflict!
'H' 00-7F linux/hiddev.h conflict!
'H' 00-0F linux/hidraw.h conflict!
'H' 01 linux/mei.h conflict!