netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH 2/4] isdn/capi: Make verbose reporting depend on capidrv
  2014-05-18 21:26 [PATCH 0/4] ISDN patches for net-next Tilman Schmidt
  2014-05-18 21:26 ` [PATCH 3/4] tty: allow tty drivers to rename their device nodes Tilman Schmidt
  2014-05-18 21:26 ` [PATCH 4/4] isdn/capi: fix (middleware) " Tilman Schmidt
@ 2014-05-18 21:26 ` Tilman Schmidt
  2014-05-18 21:26 ` [PATCH 1/4] isdn/capi: move capi_info2str to capidrv.c Tilman Schmidt
  2014-05-19  1:36 ` [PATCH 0/4] ISDN patches for net-next David Miller
  4 siblings, 0 replies; 10+ messages in thread
From: Tilman Schmidt @ 2014-05-18 21:26 UTC (permalink / raw)
  To: netdev; +Cc: Paul Bolle, isdn4linux, Keil, Karsten

From: Paul Bolle <pebolle@tiscali.nl>

The Kconfig symbol ISDN_DRV_AVMB1_VERBOSE_REASON is only used for
capi_info2str(). That function is only used in capidrv.c. So setting it
without setting ISDN_CAPI_CAPIDRV is pointless. Make it depend on
ISDN_CAPI_CAPIDRV, rename it to ISDN_CAPI_CAPIDRV_VERBOSE and put its
entry after ISDN_CAPI_CAPIDRV's entry.

Since this symbol seems to be primarily used for debugging, keep it off
by default. By now the last users of capidrv hopefully know all they
need to know about the reasons for disconnecting.

Signed-off-by: Paul Bolle <pebolle@tiscali.nl>
Signed-off-by: Tilman Schmidt <tilman@imap.cc>
---
 drivers/isdn/capi/Kconfig   | 16 ++++++++--------
 drivers/isdn/capi/capidrv.c |  2 +-
 2 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/drivers/isdn/capi/Kconfig b/drivers/isdn/capi/Kconfig
index 9816c51..1d7adff 100644
--- a/drivers/isdn/capi/Kconfig
+++ b/drivers/isdn/capi/Kconfig
@@ -1,11 +1,3 @@
-config ISDN_DRV_AVMB1_VERBOSE_REASON
-	bool "Verbose reason code reporting"
-	default y
-	help
-	  If you say Y here, the CAPI drivers will give verbose reasons for
-	  disconnecting. This will increase the size of the kernel by 7 KB. If
-	  unsure, say Y.
-
 config CAPI_TRACE
 	bool "CAPI trace support"
 	default y
@@ -42,3 +34,11 @@ config ISDN_CAPI_CAPIDRV
 	  the legacy isdn4linux link layer.  If you have a card which is
 	  supported by a CAPI driver, but still want to use old features like
 	  ippp interfaces or ttyI emulation, say Y/M here.
+
+config ISDN_CAPI_CAPIDRV_VERBOSE
+	bool "Verbose reason code reporting"
+	depends on ISDN_CAPI_CAPIDRV
+	help
+	  If you say Y here, the capidrv interface will give verbose reasons
+	  for disconnecting. This will increase the size of the kernel by 7 KB.
+	  If unsure, say N.
diff --git a/drivers/isdn/capi/capidrv.c b/drivers/isdn/capi/capidrv.c
index 70e67f6..fd6d28f 100644
--- a/drivers/isdn/capi/capidrv.c
+++ b/drivers/isdn/capi/capidrv.c
@@ -765,7 +765,7 @@ static inline int new_bchan(capidrv_contr *card)
 /* ------------------------------------------------------------------- */
 static char *capi_info2str(u16 reason)
 {
-#ifndef CONFIG_ISDN_DRV_AVMB1_VERBOSE_REASON
+#ifndef CONFIG_ISDN_CAPI_CAPIDRV_VERBOSE
 	return "..";
 #else
 	switch (reason) {
-- 
1.9.2.459.g68773ac

^ permalink raw reply related	[flat|nested] 10+ messages in thread

* [PATCH 1/4] isdn/capi: move capi_info2str to capidrv.c
  2014-05-18 21:26 [PATCH 0/4] ISDN patches for net-next Tilman Schmidt
                   ` (2 preceding siblings ...)
  2014-05-18 21:26 ` [PATCH 2/4] isdn/capi: Make verbose reporting depend on capidrv Tilman Schmidt
@ 2014-05-18 21:26 ` Tilman Schmidt
  2014-05-19  1:36 ` [PATCH 0/4] ISDN patches for net-next David Miller
  4 siblings, 0 replies; 10+ messages in thread
From: Tilman Schmidt @ 2014-05-18 21:26 UTC (permalink / raw)
  To: netdev; +Cc: Paul Bolle, isdn4linux, Keil, Karsten

From: Paul Bolle <pebolle@tiscali.nl>

capi_info2str() is apparently meant to be of general utility. It is
actually only used in capidrv.c. So move it from capiutil.c to
capidrv.c and (obviously) stop exporting it.

And, since we're touching this, merge the two versions of this
function.

Signed-off-by: Paul Bolle <pebolle@tiscali.nl>
Signed-off-by: Tilman Schmidt <tilman@imap.cc>
---
 drivers/isdn/capi/capidrv.c   | 195 ++++++++++++++++++++++++++++++++++++++++
 drivers/isdn/capi/capiutil.c  | 200 ------------------------------------------
 include/linux/isdn/capiutil.h |   5 --
 3 files changed, 195 insertions(+), 205 deletions(-)

diff --git a/drivers/isdn/capi/capidrv.c b/drivers/isdn/capi/capidrv.c
index cc9f192..70e67f6 100644
--- a/drivers/isdn/capi/capidrv.c
+++ b/drivers/isdn/capi/capidrv.c
@@ -763,6 +763,201 @@ static inline int new_bchan(capidrv_contr *card)
 }
 
 /* ------------------------------------------------------------------- */
+static char *capi_info2str(u16 reason)
+{
+#ifndef CONFIG_ISDN_DRV_AVMB1_VERBOSE_REASON
+	return "..";
+#else
+	switch (reason) {
+
+/*-- informative values (corresponding message was processed) -----*/
+	case 0x0001:
+		return "NCPI not supported by current protocol, NCPI ignored";
+	case 0x0002:
+		return "Flags not supported by current protocol, flags ignored";
+	case 0x0003:
+		return "Alert already sent by another application";
+
+/*-- error information concerning CAPI_REGISTER -----*/
+	case 0x1001:
+		return "Too many applications";
+	case 0x1002:
+		return "Logical block size too small, must be at least 128 Bytes";
+	case 0x1003:
+		return "Buffer exceeds 64 kByte";
+	case 0x1004:
+		return "Message buffer size too small, must be at least 1024 Bytes";
+	case 0x1005:
+		return "Max. number of logical connections not supported";
+	case 0x1006:
+		return "Reserved";
+	case 0x1007:
+		return "The message could not be accepted because of an internal busy condition";
+	case 0x1008:
+		return "OS resource error (no memory ?)";
+	case 0x1009:
+		return "CAPI not installed";
+	case 0x100A:
+		return "Controller does not support external equipment";
+	case 0x100B:
+		return "Controller does only support external equipment";
+
+/*-- error information concerning message exchange functions -----*/
+	case 0x1101:
+		return "Illegal application number";
+	case 0x1102:
+		return "Illegal command or subcommand or message length less than 12 bytes";
+	case 0x1103:
+		return "The message could not be accepted because of a queue full condition !! The error code does not imply that CAPI cannot receive messages directed to another controller, PLCI or NCCI";
+	case 0x1104:
+		return "Queue is empty";
+	case 0x1105:
+		return "Queue overflow, a message was lost !! This indicates a configuration error. The only recovery from this error is to perform a CAPI_RELEASE";
+	case 0x1106:
+		return "Unknown notification parameter";
+	case 0x1107:
+		return "The Message could not be accepted because of an internal busy condition";
+	case 0x1108:
+		return "OS Resource error (no memory ?)";
+	case 0x1109:
+		return "CAPI not installed";
+	case 0x110A:
+		return "Controller does not support external equipment";
+	case 0x110B:
+		return "Controller does only support external equipment";
+
+/*-- error information concerning resource / coding problems -----*/
+	case 0x2001:
+		return "Message not supported in current state";
+	case 0x2002:
+		return "Illegal Controller / PLCI / NCCI";
+	case 0x2003:
+		return "Out of PLCI";
+	case 0x2004:
+		return "Out of NCCI";
+	case 0x2005:
+		return "Out of LISTEN";
+	case 0x2006:
+		return "Out of FAX resources (protocol T.30)";
+	case 0x2007:
+		return "Illegal message parameter coding";
+
+/*-- error information concerning requested services  -----*/
+	case 0x3001:
+		return "B1 protocol not supported";
+	case 0x3002:
+		return "B2 protocol not supported";
+	case 0x3003:
+		return "B3 protocol not supported";
+	case 0x3004:
+		return "B1 protocol parameter not supported";
+	case 0x3005:
+		return "B2 protocol parameter not supported";
+	case 0x3006:
+		return "B3 protocol parameter not supported";
+	case 0x3007:
+		return "B protocol combination not supported";
+	case 0x3008:
+		return "NCPI not supported";
+	case 0x3009:
+		return "CIP Value unknown";
+	case 0x300A:
+		return "Flags not supported (reserved bits)";
+	case 0x300B:
+		return "Facility not supported";
+	case 0x300C:
+		return "Data length not supported by current protocol";
+	case 0x300D:
+		return "Reset procedure not supported by current protocol";
+
+/*-- informations about the clearing of a physical connection -----*/
+	case 0x3301:
+		return "Protocol error layer 1 (broken line or B-channel removed by signalling protocol)";
+	case 0x3302:
+		return "Protocol error layer 2";
+	case 0x3303:
+		return "Protocol error layer 3";
+	case 0x3304:
+		return "Another application got that call";
+/*-- T.30 specific reasons -----*/
+	case 0x3311:
+		return "Connecting not successful (remote station is no FAX G3 machine)";
+	case 0x3312:
+		return "Connecting not successful (training error)";
+	case 0x3313:
+		return "Disconnected before transfer (remote station does not support transfer mode, e.g. resolution)";
+	case 0x3314:
+		return "Disconnected during transfer (remote abort)";
+	case 0x3315:
+		return "Disconnected during transfer (remote procedure error, e.g. unsuccessful repetition of T.30 commands)";
+	case 0x3316:
+		return "Disconnected during transfer (local tx data underrun)";
+	case 0x3317:
+		return "Disconnected during transfer (local rx data overflow)";
+	case 0x3318:
+		return "Disconnected during transfer (local abort)";
+	case 0x3319:
+		return "Illegal parameter coding (e.g. SFF coding error)";
+
+/*-- disconnect causes from the network according to ETS 300 102-1/Q.931 -----*/
+	case 0x3481: return "Unallocated (unassigned) number";
+	case 0x3482: return "No route to specified transit network";
+	case 0x3483: return "No route to destination";
+	case 0x3486: return "Channel unacceptable";
+	case 0x3487:
+		return "Call awarded and being delivered in an established channel";
+	case 0x3490: return "Normal call clearing";
+	case 0x3491: return "User busy";
+	case 0x3492: return "No user responding";
+	case 0x3493: return "No answer from user (user alerted)";
+	case 0x3495: return "Call rejected";
+	case 0x3496: return "Number changed";
+	case 0x349A: return "Non-selected user clearing";
+	case 0x349B: return "Destination out of order";
+	case 0x349C: return "Invalid number format";
+	case 0x349D: return "Facility rejected";
+	case 0x349E: return "Response to STATUS ENQUIRY";
+	case 0x349F: return "Normal, unspecified";
+	case 0x34A2: return "No circuit / channel available";
+	case 0x34A6: return "Network out of order";
+	case 0x34A9: return "Temporary failure";
+	case 0x34AA: return "Switching equipment congestion";
+	case 0x34AB: return "Access information discarded";
+	case 0x34AC: return "Requested circuit / channel not available";
+	case 0x34AF: return "Resources unavailable, unspecified";
+	case 0x34B1: return "Quality of service unavailable";
+	case 0x34B2: return "Requested facility not subscribed";
+	case 0x34B9: return "Bearer capability not authorized";
+	case 0x34BA: return "Bearer capability not presently available";
+	case 0x34BF: return "Service or option not available, unspecified";
+	case 0x34C1: return "Bearer capability not implemented";
+	case 0x34C2: return "Channel type not implemented";
+	case 0x34C5: return "Requested facility not implemented";
+	case 0x34C6: return "Only restricted digital information bearer capability is available";
+	case 0x34CF: return "Service or option not implemented, unspecified";
+	case 0x34D1: return "Invalid call reference value";
+	case 0x34D2: return "Identified channel does not exist";
+	case 0x34D3: return "A suspended call exists, but this call identity does not";
+	case 0x34D4: return "Call identity in use";
+	case 0x34D5: return "No call suspended";
+	case 0x34D6: return "Call having the requested call identity has been cleared";
+	case 0x34D8: return "Incompatible destination";
+	case 0x34DB: return "Invalid transit network selection";
+	case 0x34DF: return "Invalid message, unspecified";
+	case 0x34E0: return "Mandatory information element is missing";
+	case 0x34E1: return "Message type non-existent or not implemented";
+	case 0x34E2: return "Message not compatible with call state or message type non-existent or not implemented";
+	case 0x34E3: return "Information element non-existent or not implemented";
+	case 0x34E4: return "Invalid information element contents";
+	case 0x34E5: return "Message not compatible with call state";
+	case 0x34E6: return "Recovery on timer expiry";
+	case 0x34EF: return "Protocol error, unspecified";
+	case 0x34FF: return "Interworking, unspecified";
+
+	default: return "No additional information";
+	}
+#endif
+}
 
 static void handle_controller(_cmsg *cmsg)
 {
diff --git a/drivers/isdn/capi/capiutil.c b/drivers/isdn/capi/capiutil.c
index d26f170..6e797e5 100644
--- a/drivers/isdn/capi/capiutil.c
+++ b/drivers/isdn/capi/capiutil.c
@@ -22,205 +22,6 @@
 
 /* from CAPI2.0 DDK AVM Berlin GmbH */
 
-#ifndef CONFIG_ISDN_DRV_AVMB1_VERBOSE_REASON
-char *capi_info2str(u16 reason)
-{
-	return "..";
-}
-#else
-char *capi_info2str(u16 reason)
-{
-	switch (reason) {
-
-/*-- informative values (corresponding message was processed) -----*/
-	case 0x0001:
-		return "NCPI not supported by current protocol, NCPI ignored";
-	case 0x0002:
-		return "Flags not supported by current protocol, flags ignored";
-	case 0x0003:
-		return "Alert already sent by another application";
-
-/*-- error information concerning CAPI_REGISTER -----*/
-	case 0x1001:
-		return "Too many applications";
-	case 0x1002:
-		return "Logical block size too small, must be at least 128 Bytes";
-	case 0x1003:
-		return "Buffer exceeds 64 kByte";
-	case 0x1004:
-		return "Message buffer size too small, must be at least 1024 Bytes";
-	case 0x1005:
-		return "Max. number of logical connections not supported";
-	case 0x1006:
-		return "Reserved";
-	case 0x1007:
-		return "The message could not be accepted because of an internal busy condition";
-	case 0x1008:
-		return "OS resource error (no memory ?)";
-	case 0x1009:
-		return "CAPI not installed";
-	case 0x100A:
-		return "Controller does not support external equipment";
-	case 0x100B:
-		return "Controller does only support external equipment";
-
-/*-- error information concerning message exchange functions -----*/
-	case 0x1101:
-		return "Illegal application number";
-	case 0x1102:
-		return "Illegal command or subcommand or message length less than 12 bytes";
-	case 0x1103:
-		return "The message could not be accepted because of a queue full condition !! The error code does not imply that CAPI cannot receive messages directed to another controller, PLCI or NCCI";
-	case 0x1104:
-		return "Queue is empty";
-	case 0x1105:
-		return "Queue overflow, a message was lost !! This indicates a configuration error. The only recovery from this error is to perform a CAPI_RELEASE";
-	case 0x1106:
-		return "Unknown notification parameter";
-	case 0x1107:
-		return "The Message could not be accepted because of an internal busy condition";
-	case 0x1108:
-		return "OS Resource error (no memory ?)";
-	case 0x1109:
-		return "CAPI not installed";
-	case 0x110A:
-		return "Controller does not support external equipment";
-	case 0x110B:
-		return "Controller does only support external equipment";
-
-/*-- error information concerning resource / coding problems -----*/
-	case 0x2001:
-		return "Message not supported in current state";
-	case 0x2002:
-		return "Illegal Controller / PLCI / NCCI";
-	case 0x2003:
-		return "Out of PLCI";
-	case 0x2004:
-		return "Out of NCCI";
-	case 0x2005:
-		return "Out of LISTEN";
-	case 0x2006:
-		return "Out of FAX resources (protocol T.30)";
-	case 0x2007:
-		return "Illegal message parameter coding";
-
-/*-- error information concerning requested services  -----*/
-	case 0x3001:
-		return "B1 protocol not supported";
-	case 0x3002:
-		return "B2 protocol not supported";
-	case 0x3003:
-		return "B3 protocol not supported";
-	case 0x3004:
-		return "B1 protocol parameter not supported";
-	case 0x3005:
-		return "B2 protocol parameter not supported";
-	case 0x3006:
-		return "B3 protocol parameter not supported";
-	case 0x3007:
-		return "B protocol combination not supported";
-	case 0x3008:
-		return "NCPI not supported";
-	case 0x3009:
-		return "CIP Value unknown";
-	case 0x300A:
-		return "Flags not supported (reserved bits)";
-	case 0x300B:
-		return "Facility not supported";
-	case 0x300C:
-		return "Data length not supported by current protocol";
-	case 0x300D:
-		return "Reset procedure not supported by current protocol";
-
-/*-- informations about the clearing of a physical connection -----*/
-	case 0x3301:
-		return "Protocol error layer 1 (broken line or B-channel removed by signalling protocol)";
-	case 0x3302:
-		return "Protocol error layer 2";
-	case 0x3303:
-		return "Protocol error layer 3";
-	case 0x3304:
-		return "Another application got that call";
-/*-- T.30 specific reasons -----*/
-	case 0x3311:
-		return "Connecting not successful (remote station is no FAX G3 machine)";
-	case 0x3312:
-		return "Connecting not successful (training error)";
-	case 0x3313:
-		return "Disconnected before transfer (remote station does not support transfer mode, e.g. resolution)";
-	case 0x3314:
-		return "Disconnected during transfer (remote abort)";
-	case 0x3315:
-		return "Disconnected during transfer (remote procedure error, e.g. unsuccessful repetition of T.30 commands)";
-	case 0x3316:
-		return "Disconnected during transfer (local tx data underrun)";
-	case 0x3317:
-		return "Disconnected during transfer (local rx data overflow)";
-	case 0x3318:
-		return "Disconnected during transfer (local abort)";
-	case 0x3319:
-		return "Illegal parameter coding (e.g. SFF coding error)";
-
-/*-- disconnect causes from the network according to ETS 300 102-1/Q.931 -----*/
-	case 0x3481: return "Unallocated (unassigned) number";
-	case 0x3482: return "No route to specified transit network";
-	case 0x3483: return "No route to destination";
-	case 0x3486: return "Channel unacceptable";
-	case 0x3487:
-		return "Call awarded and being delivered in an established channel";
-	case 0x3490: return "Normal call clearing";
-	case 0x3491: return "User busy";
-	case 0x3492: return "No user responding";
-	case 0x3493: return "No answer from user (user alerted)";
-	case 0x3495: return "Call rejected";
-	case 0x3496: return "Number changed";
-	case 0x349A: return "Non-selected user clearing";
-	case 0x349B: return "Destination out of order";
-	case 0x349C: return "Invalid number format";
-	case 0x349D: return "Facility rejected";
-	case 0x349E: return "Response to STATUS ENQUIRY";
-	case 0x349F: return "Normal, unspecified";
-	case 0x34A2: return "No circuit / channel available";
-	case 0x34A6: return "Network out of order";
-	case 0x34A9: return "Temporary failure";
-	case 0x34AA: return "Switching equipment congestion";
-	case 0x34AB: return "Access information discarded";
-	case 0x34AC: return "Requested circuit / channel not available";
-	case 0x34AF: return "Resources unavailable, unspecified";
-	case 0x34B1: return "Quality of service unavailable";
-	case 0x34B2: return "Requested facility not subscribed";
-	case 0x34B9: return "Bearer capability not authorized";
-	case 0x34BA: return "Bearer capability not presently available";
-	case 0x34BF: return "Service or option not available, unspecified";
-	case 0x34C1: return "Bearer capability not implemented";
-	case 0x34C2: return "Channel type not implemented";
-	case 0x34C5: return "Requested facility not implemented";
-	case 0x34C6: return "Only restricted digital information bearer capability is available";
-	case 0x34CF: return "Service or option not implemented, unspecified";
-	case 0x34D1: return "Invalid call reference value";
-	case 0x34D2: return "Identified channel does not exist";
-	case 0x34D3: return "A suspended call exists, but this call identity does not";
-	case 0x34D4: return "Call identity in use";
-	case 0x34D5: return "No call suspended";
-	case 0x34D6: return "Call having the requested call identity has been cleared";
-	case 0x34D8: return "Incompatible destination";
-	case 0x34DB: return "Invalid transit network selection";
-	case 0x34DF: return "Invalid message, unspecified";
-	case 0x34E0: return "Mandatory information element is missing";
-	case 0x34E1: return "Message type non-existent or not implemented";
-	case 0x34E2: return "Message not compatible with call state or message type non-existent or not implemented";
-	case 0x34E3: return "Information element non-existent or not implemented";
-	case 0x34E4: return "Invalid information element contents";
-	case 0x34E5: return "Message not compatible with call state";
-	case 0x34E6: return "Recovery on timer expiry";
-	case 0x34EF: return "Protocol error, unspecified";
-	case 0x34FF: return "Interworking, unspecified";
-
-	default: return "No additional information";
-	}
-}
-#endif
-
 typedef struct {
 	int typ;
 	size_t off;
@@ -1073,4 +874,3 @@ EXPORT_SYMBOL(capi_cmsg_header);
 EXPORT_SYMBOL(capi_cmd2str);
 EXPORT_SYMBOL(capi_cmsg2str);
 EXPORT_SYMBOL(capi_message2str);
-EXPORT_SYMBOL(capi_info2str);
diff --git a/include/linux/isdn/capiutil.h b/include/linux/isdn/capiutil.h
index 5a52f2c..44bd604 100644
--- a/include/linux/isdn/capiutil.h
+++ b/include/linux/isdn/capiutil.h
@@ -164,11 +164,6 @@ unsigned capi_cmsg_header(_cmsg * cmsg, __u16 _ApplId,
 			  __u8 _Command, __u8 _Subcommand,
 			  __u16 _Messagenumber, __u32 _Controller);
 
-/*
- * capi_info2str generated a readable string for Capi2.0 reasons.
- */
-char *capi_info2str(__u16 reason);
-
 /*-----------------------------------------------------------------------*/
 
 /*
-- 
1.9.2.459.g68773ac

^ permalink raw reply related	[flat|nested] 10+ messages in thread

* [PATCH 4/4] isdn/capi: fix (middleware) device nodes
  2014-05-18 21:26 [PATCH 0/4] ISDN patches for net-next Tilman Schmidt
  2014-05-18 21:26 ` [PATCH 3/4] tty: allow tty drivers to rename their device nodes Tilman Schmidt
@ 2014-05-18 21:26 ` Tilman Schmidt
  2014-05-18 21:26 ` [PATCH 2/4] isdn/capi: Make verbose reporting depend on capidrv Tilman Schmidt
                   ` (2 subsequent siblings)
  4 siblings, 0 replies; 10+ messages in thread
From: Tilman Schmidt @ 2014-05-18 21:26 UTC (permalink / raw)
  To: netdev
  Cc: Paul Bolle, isdn4linux, Keil, Karsten, Jiri Slaby,
	Greg Kroah-Hartman

From: Paul Bolle <pebolle@tiscali.nl>

Since v2.4 the capi driver used the following device nodes if
"middleware" support was enabled:
    /dev/capi20
    /dev/capi/0
    /dev/capi/1
    [...]

/dev/capi20 is a character device node. /dev/capi/0 (and up) are tty
device nodes (with a different major).

This device node (naming) scheme is not documented anywhere, as far as I
know. It was originally provided by the capifs pseudo filesystem (before
udev became available). It is required for example by the pppd
capiplugin. It was supported until a few years ago. But a number of
developments broke it:
- v2.6.6 (May 2004) renamed /dev/capi20 to /dev/capi and removed the
  "/" from the name of capi's tty driver. The explanation of the patch
  that did this included two examples of udev rules "to restore the old
  namespace";
- either udev 154 (May 2010) or udev 179 (January 2012) stopped
  allowing to rename device nodes, and thus the ability to have
  /dev/capi20 appear instead of /dev/capi and /dev/capi/0 (and up)
  instead of /dev/capi0 (and up);
- v3.0 (July 2011) also removed capifs. That disabled another method to
  create the /dev/capi/0 (and up) device nodes.

So now users need to manually tweak their setup (eg, create /dev/capi/
and fill that with symlinks) to get things working. This is all rather
hacky and only discoverable by searching the web. Fix all this by
renaming /dev/capi back to /dev/capi20, and by adding a devnode()
callback to the "capi_nc" tty driver so the tty device nodes appear as
/dev/capi/0 (and up).

Signed-off-by: Paul Bolle <pebolle@tiscali.nl>
Signed-off-by: Tilman Schmidt <tilman@imap.cc>
---
 drivers/isdn/capi/Kconfig | 2 +-
 drivers/isdn/capi/capi.c  | 8 +++++++-
 2 files changed, 8 insertions(+), 2 deletions(-)

diff --git a/drivers/isdn/capi/Kconfig b/drivers/isdn/capi/Kconfig
index 1d7adff..7641b30 100644
--- a/drivers/isdn/capi/Kconfig
+++ b/drivers/isdn/capi/Kconfig
@@ -9,7 +9,7 @@ config CAPI_TRACE
 	  If unsure, say Y.
 
 config ISDN_CAPI_CAPI20
-	tristate "CAPI2.0 /dev/capi support"
+	tristate "CAPI2.0 /dev/capi20 support"
 	help
 	  This option will provide the CAPI 2.0 interface to userspace
 	  applications via /dev/capi20. Applications should use the
diff --git a/drivers/isdn/capi/capi.c b/drivers/isdn/capi/capi.c
index ac6f72b..e9afa74 100644
--- a/drivers/isdn/capi/capi.c
+++ b/drivers/isdn/capi/capi.c
@@ -1250,6 +1250,11 @@ static const struct tty_operations capinc_ops = {
 	.cleanup = capinc_tty_cleanup,
 };
 
+static char *capi_devnode(struct device *dev, umode_t *mode)
+{
+	return kasprintf(GFP_KERNEL, "capi/%u", MINOR(dev->devt));
+}
+
 static int __init capinc_tty_init(void)
 {
 	struct tty_driver *drv;
@@ -1272,6 +1277,7 @@ static int __init capinc_tty_init(void)
 	}
 	drv->driver_name = "capi_nc";
 	drv->name = "capi";
+	drv->devnode = capi_devnode;
 	drv->major = 0;
 	drv->minor_start = 0;
 	drv->type = TTY_DRIVER_TYPE_SERIAL;
@@ -1417,7 +1423,7 @@ static int __init capi_init(void)
 		return PTR_ERR(capi_class);
 	}
 
-	device_create(capi_class, NULL, MKDEV(capi_major, 0), NULL, "capi");
+	device_create(capi_class, NULL, MKDEV(capi_major, 0), NULL, "capi20");
 
 	if (capinc_tty_init() < 0) {
 		device_destroy(capi_class, MKDEV(capi_major, 0));
-- 
1.9.2.459.g68773ac

^ permalink raw reply related	[flat|nested] 10+ messages in thread

* [PATCH 0/4] ISDN patches for net-next
@ 2014-05-18 21:26 Tilman Schmidt
  2014-05-18 21:26 ` [PATCH 3/4] tty: allow tty drivers to rename their device nodes Tilman Schmidt
                   ` (4 more replies)
  0 siblings, 5 replies; 10+ messages in thread
From: Tilman Schmidt @ 2014-05-18 21:26 UTC (permalink / raw)
  To: netdev; +Cc: Paul Bolle, isdn4linux, Keil, Karsten

Here's a series of patches for the ISDN CAPI subsystem and an auxiliary
patch to the tty driver, prepared by Paul Bolle over the last couple of
weeks. I would appreciate if you could merge these via net-next.

Paul Bolle (4):
  isdn/capi: move capi_info2str to capidrv.c
  isdn/capi: Make verbose reporting depend on capidrv
  tty: allow tty drivers to rename their device nodes
  isdn/capi: fix (middleware) device nodes

 drivers/isdn/capi/Kconfig     |  18 ++--
 drivers/isdn/capi/capi.c      |   8 +-
 drivers/isdn/capi/capidrv.c   | 195 ++++++++++++++++++++++++++++++++++++++++
 drivers/isdn/capi/capiutil.c  | 200 ------------------------------------------
 drivers/tty/tty_io.c          |  16 +++-
 include/linux/isdn/capiutil.h |   5 --
 include/linux/tty_driver.h    |   1 +
 7 files changed, 226 insertions(+), 217 deletions(-)

-- 
1.9.2.459.g68773ac

^ permalink raw reply	[flat|nested] 10+ messages in thread

* [PATCH 3/4] tty: allow tty drivers to rename their device nodes
  2014-05-18 21:26 [PATCH 0/4] ISDN patches for net-next Tilman Schmidt
@ 2014-05-18 21:26 ` Tilman Schmidt
  2014-05-18 21:26 ` [PATCH 4/4] isdn/capi: fix (middleware) " Tilman Schmidt
                   ` (3 subsequent siblings)
  4 siblings, 0 replies; 10+ messages in thread
From: Tilman Schmidt @ 2014-05-18 21:26 UTC (permalink / raw)
  To: netdev
  Cc: Paul Bolle, isdn4linux, Keil, Karsten, Jiri Slaby,
	Greg Kroah-Hartman

From: Paul Bolle <pebolle@tiscali.nl>

The device nodes for tty drivers are named using a straightforward
scheme: tty_driver->name with an (increasing) digit appended. But the
capi driver (a part of one of the current ISDN subsystems) requires a
different naming scheme for its "capi_nc" tty_driver:
    /dev/capi/0
    /dev/capi/1
    [...]

So add a devnode() callback to struct tty_driver to allow tty drivers
to use a more elaborate naming scheme. And let tty_devnode(), the
devnode() callback for the "tty" class, call that new callback if a tty
driver uses one. This allows the capi driver to add a callback to
enable its scheme.

Signed-off-by: Paul Bolle <pebolle@tiscali.nl>
Signed-off-by: Tilman Schmidt <tilman@imap.cc>
---
 drivers/tty/tty_io.c       | 16 ++++++++++++++--
 include/linux/tty_driver.h |  1 +
 2 files changed, 15 insertions(+), 2 deletions(-)

diff --git a/drivers/tty/tty_io.c b/drivers/tty/tty_io.c
index 3411071..32d7878 100644
--- a/drivers/tty/tty_io.c
+++ b/drivers/tty/tty_io.c
@@ -3504,12 +3504,24 @@ void __init console_init(void)
 
 static char *tty_devnode(struct device *dev, umode_t *mode)
 {
+	struct tty_driver *driver = NULL;
+	int unused;
+	char *ret = NULL;
+
+	mutex_lock(&tty_mutex);
+	driver = get_tty_driver(dev->devt, &unused);
+	mutex_unlock(&tty_mutex);
+	if (driver && driver->devnode)
+		ret = driver->devnode(dev, mode);
+	if (driver)
+		tty_driver_kref_put(driver);
+
 	if (!mode)
-		return NULL;
+		return ret;
 	if (dev->devt == MKDEV(TTYAUX_MAJOR, 0) ||
 	    dev->devt == MKDEV(TTYAUX_MAJOR, 2))
 		*mode = 0666;
-	return NULL;
+	return ret;
 }
 
 static int __init tty_class_init(void)
diff --git a/include/linux/tty_driver.h b/include/linux/tty_driver.h
index 756a609..91265bf 100644
--- a/include/linux/tty_driver.h
+++ b/include/linux/tty_driver.h
@@ -294,6 +294,7 @@ struct tty_driver {
 	struct module	*owner;
 	const char	*driver_name;
 	const char	*name;
+	char *(*devnode)(struct device *dev, umode_t *mode);
 	int	name_base;	/* offset of printed name */
 	int	major;		/* major device number */
 	int	minor_start;	/* start of minor device number */
-- 
1.9.2.459.g68773ac

^ permalink raw reply related	[flat|nested] 10+ messages in thread

* Re: [PATCH 0/4] ISDN patches for net-next
  2014-05-18 21:26 [PATCH 0/4] ISDN patches for net-next Tilman Schmidt
                   ` (3 preceding siblings ...)
  2014-05-18 21:26 ` [PATCH 1/4] isdn/capi: move capi_info2str to capidrv.c Tilman Schmidt
@ 2014-05-19  1:36 ` David Miller
  2014-05-19 21:36   ` Tilman Schmidt
  4 siblings, 1 reply; 10+ messages in thread
From: David Miller @ 2014-05-19  1:36 UTC (permalink / raw)
  To: tilman; +Cc: netdev, pebolle, isdn4linux, isdn

From: Tilman Schmidt <tilman@imap.cc>
Date: Sun, 18 May 2014 23:26:08 +0200

> Here's a series of patches for the ISDN CAPI subsystem and an auxiliary
> patch to the tty driver, prepared by Paul Bolle over the last couple of
> weeks. I would appreciate if you could merge these via net-next.

Since this has been broken for several years, you might be doing more
harm than good by trying to change things back again.

Why not just have capiplugin able to search for and use the names
generated now?

That way it will work on any kernel version and/or combination with
udev.

I'm not really excited to apply this series, I genuinely think it
makes things worse, sorry.

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [PATCH 0/4] ISDN patches for net-next
  2014-05-19  1:36 ` [PATCH 0/4] ISDN patches for net-next David Miller
@ 2014-05-19 21:36   ` Tilman Schmidt
  2014-05-21 21:02     ` David Miller
  0 siblings, 1 reply; 10+ messages in thread
From: Tilman Schmidt @ 2014-05-19 21:36 UTC (permalink / raw)
  To: David Miller; +Cc: netdev, pebolle, isdn4linux, isdn

David,

thanks for your reply. I understand your concerns but I don't agree
with them and hope I'll be able to convince you otherwise.

On 19.05.2014 03:36, you wrote:
> Since this has been broken for several years, you might be doing more
> harm than good by trying to change things back again.

You appear to assume that there is a currently working configuration
which might be broken by the patch series. That is not the case.
The (very few) remaining users of PPP over ISDN cope with the
current situation in one of these ways:

a) staying with a pre-3.0 kernel that still provides capifs

b) staying with (or reverting to) the deprecated ISDN4Linux subsystem

c) patching the kernel locally to fix the breakage

d) staying with an old udev version that can still rename device nodes

e) explicitly running commands like
    mv /dev/capi /dev/capi20
    mkdir /dev/capi
    ln -s /dev/capi0 /dev/capi/0
    ln -s /dev/capi1 /dev/capi/1
   on every boot, typically via /etc/boot.local or similar mechanisms.

f) giving up on Linux ISDN support and buying a separate router.

None of these will be broken by fixing the problem in the kernel:

- a), b) and f) won't notice anything unless they read the changelog
  and find they can at last use ISDN over CAPI with a current kernel
  again if they want to.

- c) will notice that the local kernel patch doesn't apply anymore
  and happily drop it.

- d) and e) may or may not notice that renaming the CAPI nodes fails
  because the nodes are already named correctly, but apart from a
  couple of log messages everything will work as before.

> Why not just have capiplugin able to search for and use the names
> generated now?

For one, capiplugin is a pretty old piece of software. The risk of
breaking it in the attempt to adapt it to the Kernel CAPI interface
change is far bigger than the risk associated with reverting that
change in the kernel. What's more, capiplugin is not the only
software affected. /dev/capi20 is the documented standard device
for CAPI 2.0 on Linux. Userspace relies on that. We would have to
adapt at least libcapi20 too, and possibly an unknown number of
other applications.

In sum, I'm convinced the proposed patch series is the minimally
invasive way of sorting out the current mess surrounding the
CAPI device files.

Regards,
Tilman

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [PATCH 0/4] ISDN patches for net-next
  2014-05-19 21:36   ` Tilman Schmidt
@ 2014-05-21 21:02     ` David Miller
  0 siblings, 0 replies; 10+ messages in thread
From: David Miller @ 2014-05-21 21:02 UTC (permalink / raw)
  To: tilman; +Cc: netdev, pebolle, isdn4linux, isdn

From: Tilman Schmidt <tilman@imap.cc>
Date: Mon, 19 May 2014 23:36:37 +0200

> In sum, I'm convinced the proposed patch series is the minimally
> invasive way of sorting out the current mess surrounding the
> CAPI device files.

Ok, fair enough, please resubmit.

^ permalink raw reply	[flat|nested] 10+ messages in thread

* [PATCH 0/4] ISDN patches for net-next
@ 2014-10-03 15:03 Tilman Schmidt
  2014-10-06  1:18 ` David Miller
  0 siblings, 1 reply; 10+ messages in thread
From: Tilman Schmidt @ 2014-10-03 15:03 UTC (permalink / raw)
  To: netdev; +Cc: David Miller, Hansjoerg Lipp, Karsten Keil, isdn4linux

Here's a series of patches for the ISDN CAPI subsystem and the
Gigaset ISDN driver.  Please merge via net-next.

Tilman Schmidt (4):
  isdn/gigaset: improve error handling when leaving DLE mode
  isdn/gigaset: drop unused cardstate structure member
  isdn/gigaset: use USB API function usb_endpoint_num()
  isdn/capi: drop two dead if branches

 drivers/isdn/capi/capiutil.c       |    3 ---
 drivers/isdn/gigaset/ev-layer.c    |    3 ++-
 drivers/isdn/gigaset/usb-gigaset.c |   14 +++++---------
 3 files changed, 7 insertions(+), 13 deletions(-)

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [PATCH 0/4] ISDN patches for net-next
  2014-10-03 15:03 Tilman Schmidt
@ 2014-10-06  1:18 ` David Miller
  0 siblings, 0 replies; 10+ messages in thread
From: David Miller @ 2014-10-06  1:18 UTC (permalink / raw)
  To: tilman; +Cc: netdev, hjlipp, isdn, isdn4linux

From: Tilman Schmidt <tilman@imap.cc>
Date: Fri, 3 Oct 2014 17:03:32 +0200

> Here's a series of patches for the ISDN CAPI subsystem and the
> Gigaset ISDN driver.  Please merge via net-next.

Series applied, thanks.

^ permalink raw reply	[flat|nested] 10+ messages in thread

end of thread, other threads:[~2014-10-06  1:18 UTC | newest]

Thread overview: 10+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2014-05-18 21:26 [PATCH 0/4] ISDN patches for net-next Tilman Schmidt
2014-05-18 21:26 ` [PATCH 3/4] tty: allow tty drivers to rename their device nodes Tilman Schmidt
2014-05-18 21:26 ` [PATCH 4/4] isdn/capi: fix (middleware) " Tilman Schmidt
2014-05-18 21:26 ` [PATCH 2/4] isdn/capi: Make verbose reporting depend on capidrv Tilman Schmidt
2014-05-18 21:26 ` [PATCH 1/4] isdn/capi: move capi_info2str to capidrv.c Tilman Schmidt
2014-05-19  1:36 ` [PATCH 0/4] ISDN patches for net-next David Miller
2014-05-19 21:36   ` Tilman Schmidt
2014-05-21 21:02     ` David Miller
  -- strict thread matches above, loose matches on Subject: below --
2014-10-03 15:03 Tilman Schmidt
2014-10-06  1:18 ` David Miller

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).