Commit 8a7e8ff8 authored by David S. Miller's avatar David S. Miller
Browse files

Merge tag 'isdn-removal' of https://git.kernel.org/pub/scm/linux/kernel/git/arnd/playground 

Arnd Bergmann says:

====================
isdn: deprecate non-mISDN drivers

When isdn4linux came up in the context of another patch series, I
remembered that we had discussed removing it a while ago.

It turns out that the suggestion from Karsten Keil wa to remove I4L
in 2018 after the last public ISDN networks are shut down. This has
happened now (with a very small number of exceptions), so I guess it's
time to try again.

We currently have three ISDN stacks in the kernel: the original
isdn4linux (with the hisax driver), the newer CAPI (with four drivers),
and finally the mISDN stack (supporting roughly the same hardware as
hisax).

As far as I can tell, anyone using ISDN with mainline kernel drivers in
the past few years uses mISDN, and this is typically used for voice-only
PBX installations that don't require a public network.

The older stacks support additional features for data networks, but those
typically make no sense any more if there is no network to connect to.

My proposal for this time is to kill off isdn4linux entirely, as it seems
to have been unusable for quite a while. This code has been abandoned
for many years and it does cause problems for treewide maintenance as
it tends to do everything that we try to stop doing.
Birger Harzenetter mentioned that is is still using i4l in order to
make use of the 'divert' feature that is not part of mISDN, but has
otherwise moved on to mISDN for normal operation, like apparently
everyone else.

CAPI in turn is not quite as obsolete, but two of the drivers (avm
and hysdn) don't seem to be used at all, while another one (gigaset)
will stop being maintained as Paul Bolle is no longer able to
test it after the network gets shut down in September.
All three are now moved into drivers/staging to let others speak
up in case there are remaining users.
This leaves Bluetooth CMTP as the only remaining user of CAPI, but
Marcel Holtmann wishes to keep maintaining it.

For the discussion on version 1, see [2]
Unfortunately, Karsten Keil as the maintainer has not participated in
the discussion.

      Arnd

[1] https://patchwork.kernel.org/patch/8484861/#17900371
[2] https://listserv.isdn4linux.de/pipermail/isdn4linux/2019-April/thread.html


====================

Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
parents 57f04102 6d979850

Documentation/isdn/HiSax.cert

deleted100644 → 0
+0 −96
Original line number Diff line number Diff line 
-----BEGIN PGP SIGNED MESSAGE-----



First:



    HiSax 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.



However, if you wish to modify the HiSax sources, please note the following:



HiSax has passed the ITU approval test suite with ELSA Quickstep ISDN cards

and Eicon Technology Diva 2.01 PCI card.

The certification is only valid for the combination of the tested software

version and the tested hardware. Any changes to the HiSax source code may

therefore affect the certification.



Additional ITU approval tests have been carried out for all generic cards

using Colognechip single chip solutions HFC-S PCI A for PCI cards as well

as HFC-S USB based USB ISDN ta adapters.

These tests included all layers 1-3 and as well all functional tests for 

the layer 1. Because all hardware based on these chips are complete ISDN

solutions in one chip all cards and USB-TAs using these chips are to be

regarded as approved for those tests. Some additional electrical tests

of the layer 1 which are independent of the driver and related to a

special hardware used will be regarded as approved if at least one 

solution has been tested including those electrical tests. So if cards 

or tas have been completely approved for any other os, the approval

for those electrical tests is valid for linux, too.

Please send any questions regarding this drivers or approval abouts to 

werner@isdn-development.de 

Additional information and the type approval documents will be found

shortly on the Colognechip website www.colognechip.com 



If you change the main files of the HiSax ISDN stack, the certification will

become invalid. Because in most countries it is illegal to connect

unapproved ISDN equipment to the public network, I have to guarantee that

changes in HiSax do not affect the certification.



In order to make a valid certification apparent to the user, I have built in

some validation checks that are made during the make process. The HiSax main

files are protected by md5 checksums and the md5sum file is pgp signed by

myself:



KeyID 1024/FF992F6D 1997/01/16 Karsten Keil <kkeil@suse.de>

Key fingerprint = 92 6B F7 58 EE 86 28 C8  C4 1A E6 DC 39 89 F2 AA



Only if the checksums are OK, and the signature of the file

"drivers/isdn/hisax/md5sums.asc" match, is the certification valid; a

message confirming this is then displayed during the hisax init process.



The affected files are:



drivers/isdn/hisax/isac.c

drivers/isdn/hisax/isdnl1.c

drivers/isdn/hisax/isdnl2.c

drivers/isdn/hisax/isdnl3.c

drivers/isdn/hisax/tei.c

drivers/isdn/hisax/callc.c

drivers/isdn/hisax/l3dss1.c

drivers/isdn/hisax/l3_1tr6.c

drivers/isdn/hisax/cert.c

drivers/isdn/hisax/elsa.c

drivers/isdn/hisax/diva.c

drivers/isdn/hisax/hfc_pci.c



Please send any changes, bugfixes and patches to me rather than implementing

them directly into the HiSax sources.



This does not reduce your rights granted by the GNU General Public License.

If you wish to change the sources, go ahead; but note that then the

certification is invalid even if you use one of the approved cards.



Here are the certification registration numbers for ELSA Quickstep cards:

German   D133361J CETECOM ICT Services GmbH 0682

European D133362J CETECOM ICT Services GmbH 0682





Karsten Keil

keil@isdn4linux.de



-----BEGIN PGP SIGNATURE-----

Version: 2.6.3i

Charset: noconv



iQCVAwUBOFAwqTpxHvX/mS9tAQFI2QP9GLDK2iy/KBhwReE3F7LeO+tVhffTVZ3a

20q5/z/WcIg/pnH0uTkl2UgDXBFXYl45zJyDGNpAposIFmT+Edd14o7Vj1w/BBdn

Y+5rBmJf+gyBu61da5d6bv0lpymwRa/um+ri+ilYnZ/XPfg5JKhdjGSBCJuJAElM

d2jFbTrsMYw=

=LNf9

-----END PGP SIGNATURE-----

Documentation/isdn/INTERFACE

deleted100644 → 0
+0 −759

File deleted.

Preview size limit exceeded, changes collapsed.

Documentation/isdn/INTERFACE.fax

deleted100644 → 0
+0 −163
Original line number Diff line number Diff line 
$Id: INTERFACE.fax,v 1.2 2000/08/06 09:22:50 armin Exp $





Description of the fax-subinterface between linklevel and hardwarelevel of 

  isdn4linux. 



  The communication between linklevel (LL) and hardwarelevel (HL) for fax

  is based on the struct T30_s (defined in isdnif.h).

  This struct is allocated in the LL.  

  In order to use fax, the LL provides the pointer to this struct with the 

  command ISDN_CMD_SETL3 (parm.fax). This pointer expires in case of hangup 

  and when a new channel to a new connection is assigned. 





Data handling:

  In send-mode the HL-driver has to handle the <DLE> codes and the bit-order 

  conversion by itself. 

  In receive-mode the LL-driver takes care of the bit-order conversion

  (specified by +FBOR)



Structure T30_s description:



  This structure stores the values (set by AT-commands), the remote-

  capability-values and the command-codes between LL and HL.



  If the HL-driver receives ISDN_CMD_FAXCMD, all needed information

  is in this struct set by the LL.

  To signal information to the LL, the HL-driver has to set the 

  parameters and use ISDN_STAT_FAXIND.

  (Please refer to INTERFACE)



Structure T30_s:



  All members are 8-bit unsigned (__u8)



  -  resolution     

  -  rate

  -  width

  -  length

  -  compression

  -  ecm

  -  binary

  -  scantime

  -  id[]

  Local faxmachine's parameters, set by +FDIS, +FDCS, +FLID, ...



  -  r_resolution

  -  r_rate

  -  r_width

  -  r_length

  -  r_compression

  -  r_ecm

  -  r_binary

  -  r_scantime

  -  r_id[]

  Remote faxmachine's parameters. To be set by HL-driver.



  -  phase      

  Defines the actual state of fax connection. Set by HL or LL

  depending on progress and type of connection.

  If the phase changes because of an AT command, the LL driver

  changes this value. Otherwise the HL-driver takes care of it, but

  only necessary on call establishment (from IDLE to PHASE_A).

  (one of the constants ISDN_FAX_PHASE_[IDLE,A,B,C,D,E])



  -  direction

  Defines outgoing/send or incoming/receive connection.

  (ISDN_TTY_FAX_CONN_[IN,OUT])



  -  code

  Commands from LL to HL; possible constants : 

      ISDN_TTY_FAX_DR        signals +FDR command to HL



      ISDN_TTY_FAX_DT        signals +FDT command to HL 



      ISDN_TTY_FAX_ET        signals +FET command to HL





  Other than that the "code" is set with the hangup-code value at

  the end of connection for the +FHNG message.

        

  -  r_code 

  Commands from HL to LL; possible constants :

      ISDN_TTY_FAX_CFR       output of +FCFR message. 



      ISDN_TTY_FAX_RID       output of remote ID set in r_id[]

                             (+FCSI/+FTSI on send/receive)



      ISDN_TTY_FAX_DCS       output of +FDCS and CONNECT message,

                             switching to phase C.



      ISDN_TTY_FAX_ET        signals end of data,

                             switching to phase D.



      ISDN_TTY_FAX_FCON      signals the established, outgoing connection,

                             switching to phase B.



      ISDN_TTY_FAX_FCON_I    signals the established, incoming connection,

                             switching to phase B.



      ISDN_TTY_FAX_DIS       output of +FDIS message and values.



      ISDN_TTY_FAX_SENT      signals that all data has been sent 

                             and <DLE><ETX> is acknowledged,

                             OK message will be sent.



      ISDN_TTY_FAX_PTS       signals a msg-confirmation (page sent successful),

                             depending on fet value:

                             0: output OK message (more pages follow)

                             1: switching to phase B (next document)



      ISDN_TTY_FAX_TRAIN_OK  output of +FDCS and OK message (for receive mode).



      ISDN_TTY_FAX_EOP       signals end of data in receive mode,

                             switching to phase D.



      ISDN_TTY_FAX_HNG       output of the +FHNG and value set by code and

                             OK message, switching to phase E.





  -  badlin

  Value of +FBADLIN  



  -  badmul

  Value of +FBADMUL



  -  bor

  Value of +FBOR



  -  fet

  Value of +FET command in send-mode.

  Set by HL in receive-mode for +FET message.



  -  pollid[]  

  ID-string, set by +FCIG



  -  cq

  Value of +FCQ



  -  cr

  Value of +FCR



  -  ctcrty

  Value of +FCTCRTY



  -  minsp

  Value of +FMINSP



  -  phcto

  Value of +FPHCTO



  -  rel

  Value of +FREL



  -  nbc

  Value of +FNBC (0,1)

  (+FNBC is not a known class 2 fax command, I added this to change the

   automatic "best capabilities" connection in the eicon HL-driver)



  

Armin

mac@melware.de

Documentation/isdn/README

deleted100644 → 0
+0 −599

File deleted.

Preview size limit exceeded, changes collapsed.

Documentation/isdn/README.FAQ

deleted100644 → 0
+0 −26
Original line number Diff line number Diff line 


The FAQ for isdn4linux

======================



Please note that there is a big FAQ available in the isdn4k-utils.

You find it in:

 isdn4k-utils/FAQ/i4lfaq.sgml



In case you just want to see the FAQ online, or download the newest version,

you can have a look at my website:

https://www.mhessler.de/i4lfaq/ (view + download)

or:

https://www.isdn4linux.de/faq/4lfaq.html (view)



As the extension tells, the FAQ is in SGML format, and you can convert it

into text/html/... format by using the sgml2txt/sgml2html/... tools.

Alternatively, you can also do a 'configure; make all' in the FAQ directory.





Please have a look at the FAQ before posting anything in the Mailinglist,

or the newsgroup!





Matthias Hessler

hessler@isdn4linux.de

CRA Git | Maintained and supported by SUSTech CRA and CCSE