[PATCH 3/4] tty: allow tty drivers to rename their device nodes

[PATCH 3/4] tty: allow tty drivers to rename their device nodes

[Tilman Schmidt]

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

[PATCH 1/4] isdn/capi: move capi_info2str to capidrv.c

[Tilman Schmidt]

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

[PATCH 0/4] ISDN patches for net-next (resubmission)

[Tilman Schmidt]

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

[PATCH 2/4] isdn/capi: Make verbose reporting depend on capidrv

[Tilman Schmidt]

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

[PATCH 3/4] tty: allow tty drivers to rename their device nodes

[Tilman Schmidt]

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

[PATCH 4/4] isdn/capi: fix (middleware) device nodes

[Tilman Schmidt]

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

Re: [PATCH 1/4] isdn/capi: move capi_info2str to capidrv.c

[Karsten Keil]

Am 21.05.2014 23:39, schrieb Tilman Schmidt:
> 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.


I disagree here, since this is a general helper function and should be
not in a special driver, but stay in capiutils.c which is the place for
the driver independent stuff. I used this function from time to time to
instrument other places for debugging as well.

Karsten

> 
> 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_grep r(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);
> -
>  /*-----------------------------------------------------------------------*/
>  
>  /*
> 

Re: [PATCH 1/4] isdn/capi: move capi_info2str to capidrv.c

[Paul Bolle]

Karsten,

On Thu, 2014-05-22 at 08:32 +0200, Karsten Keil wrote:
> Am 21.05.2014 23:39, schrieb Tilman Schmidt: 
> > 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.
>
> I disagree here, since this is a general helper function and should be
> not in a special driver, but stay in capiutils.c which is the place for
> the driver independent stuff. I used this function from time to time to
> instrument other places for debugging as well.

Thanks for commenting. It would be nice if you could also comment on
patch 4/4. You might be able to tell whether the things I say there
about, well, the history of CAPI (middleware) device nodes are correct,
as you were already maintainer during that period, weren't you?

This patch, 1/4, and patch 2/4, simplify the Kconfig file and the code a
bit. It makes it  bit easier to understand how the CAPI code fits
together. Same thing with my commit d1958f8c2f0d ("isdn/capi: Make
Middleware depend on CAPI2.0"). It is also nice to drop the
ISDN_DRV_AVMB1_VERBOSE_REASON name, which only makes sense to people
that know the ancient history of this code.

Anyhow, this patch might complicate your local debugging practices. That
might be inconvenient for you. But in mainline we see a function that's
used in one place only. And I think cleaning up mainline code is what
counts.


Paul Bolle

Re: [PATCH 1/4] isdn/capi: move capi_info2str to capidrv.c

[David Miller]

From: Paul Bolle <pebolle@tiscali.nl>
Date: Thu, 22 May 2014 23:38:09 +0200

> Anyhow, this patch might complicate your local debugging practices. That
> might be inconvenient for you. But in mainline we see a function that's
> used in one place only. And I think cleaning up mainline code is what
> counts.

+1

Re: [PATCH 1/4] isdn/capi: move capi_info2str to capidrv.c

[Karsten Keil]

Hi Paul,

Am 22.05.2014 23:38, schrieb Paul Bolle:
> Karsten,
> 
> On Thu, 2014-05-22 at 08:32 +0200, Karsten Keil wrote:
>> Am 21.05.2014 23:39, schrieb Tilman Schmidt: 
>>> 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.
>>
>> I disagree here, since this is a general helper function and should be
>> not in a special driver, but stay in capiutils.c which is the place for
>> the driver independent stuff. I used this function from time to time to
>> instrument other places for debugging as well.
> 
> Thanks for commenting. It would be nice if you could also comment on
> patch 4/4. You might be able to tell whether the things I say there
> about, well, the history of CAPI (middleware) device nodes are correct,
> as you were already maintainer during that period, weren't you?
> 

Yes I fully agree here, I have the same opinion as Tilman already
stated. And thanks a lot for this work.

> This patch, 1/4, and patch 2/4, simplify the Kconfig file and the code a
> bit. It makes it  bit easier to understand how the CAPI code fits
> together. Same thing with my commit d1958f8c2f0d ("isdn/capi: Make
> Middleware depend on CAPI2.0"). It is also nice to drop the
> ISDN_DRV_AVMB1_VERBOSE_REASON name, which only makes sense to people
> that know the ancient history of this code.

I'm not against dropping ISDN_DRV_AVMB1_VERBOSE_REASON completely, it
was introduced in a time in which some KByte of memory did count a lot,
since the PCs had often less than 4 MByte.

Back to capi_info2str():
My issue is that this change moves a part of the CAPI20 specification
out of the capi modules. Everything from the CAPI specification (which
is also defines these strings), is implemented in the 2 capi modules.
The capidrv is not part of the CAPI20 specification, it is only the
interface between CAPI20 and the old isdn4linux code, you can completely
run CAPI20 applications without capidrv. If you disable I4L, nobody
could use the CAPI reason translation. Yes, only the i4l interface
driver did use it up to now, but this doesn't mean that it is the
correct place. I think that this do not make it clearer how the code
fits together.

> 
> Anyhow, this patch might complicate your local debugging practices. That
> might be inconvenient for you. But in mainline we see a function that's
> used in one place only. And I think cleaning up mainline code is what
> counts.
> 

I'm not against cleaning up.
If you still think, that we should move the code I do not compain again,
but I want make sure that you understand why it was in that place and
that it makes sense from the design of the CAPI20.

Thanks again for your value work.

Karsten

Re: [PATCH 1/4] isdn/capi: move capi_info2str to capidrv.c

[Paul Bolle]

Hi Karsten,

On Sat, 2014-05-24 at 13:01 +0200, Karsten Keil wrote:
> Am 22.05.2014 23:38, schrieb Paul Bolle:
> > On Thu, 2014-05-22 at 08:32 +0200, Karsten Keil wrote:
> >> I disagree here, since this is a general helper function and should be
> >> not in a special driver, but stay in capiutils.c which is the place for
> >> the driver independent stuff. I used this function from time to time to
> >> instrument other places for debugging as well.
> > 
> > Thanks for commenting. It would be nice if you could also comment on
> > patch 4/4. You might be able to tell whether the things I say there
> > about, well, the history of CAPI (middleware) device nodes are correct,
> > as you were already maintainer during that period, weren't you? 
> 
> Yes I fully agree here, I have the same opinion as Tilman already
> stated. And thanks a lot for this work.

Good to hear, thanks!

> > This patch, 1/4, and patch 2/4, simplify the Kconfig file and the code a
> > bit. It makes it  bit easier to understand how the CAPI code fits
> > together. Same thing with my commit d1958f8c2f0d ("isdn/capi: Make
> > Middleware depend on CAPI2.0"). It is also nice to drop the
> > ISDN_DRV_AVMB1_VERBOSE_REASON name, which only makes sense to people
> > that know the ancient history of this code.
> 
> I'm not against dropping ISDN_DRV_AVMB1_VERBOSE_REASON completely, it
> was introduced in a time in which some KByte of memory did count a lot,
> since the PCs had often less than 4 MByte.

(I wasn't actually proposing to drop it. The patches rename it and move
it, and the code it enables, around a bit.)

> Back to capi_info2str():
> My issue is that this change moves a part of the CAPI20 specification
> out of the capi modules. Everything from the CAPI specification (which
> is also defines these strings), is implemented in the 2 capi modules.

capi_info2str() is currently - speaking from memory - mostly a list of
magic constant and some strings. I know that (most of?) the magic
constants can be mapped to defines elsewhere in the tree. I seem to
remember that these constants came from the spec. I don't care about
capidrv myself, so I resisted the urge to clean it all up.

But, anyhow, do you mean to say that these errors strings themselves are
to be found in a spec?

> The capidrv is not part of the CAPI20 specification, it is only the
> interface between CAPI20 and the old isdn4linux code, you can completely
> run CAPI20 applications without capidrv. If you disable I4L, nobody
> could use the CAPI reason translation. Yes, only the i4l interface
> driver did use it up to now, but this doesn't mean that it is the
> correct place. I think that this do not make it clearer how the code
> fits together.
>
> > Anyhow, this patch might complicate your local debugging practices. That
> > might be inconvenient for you. But in mainline we see a function that's
> > used in one place only. And I think cleaning up mainline code is what
> > counts.
> 
> I'm not against cleaning up.
> If you still think, that we should move the code I do not compain again,
> but I want make sure that you understand why it was in that place and
> that it makes sense from the design of the CAPI20.

So it seems you're saying we could move capi_info2str() into capidrv as
long as we store the magic constants (but, in my opinion, as proper
defines) and the error strings in some central place. Say one of the
capi headers. Is that what you're saying?

That would be quite a bit of tedious work, but it might be worth it.
I'll have to look into that, which might take a few days. Tilman, any
thoughts already?


Paul Bolle

Re: [PATCH 1/4] isdn/capi: move capi_info2str to capidrv.c

[Tilman Schmidt]

[-- Attachment #1: Type: text/plain, Size: 4806 bytes --]

Hi Paul, hi Karsten,

capi_info2str() is not important for the actual implementation of the
CAPI 2.0 standard. It just translates the 16 bit binary "Info" and
"Reason" codes defined in the CAPI 2.0 standard to the corresponding
text strings for display purposes. It's arguable whether drivers should
do so at all, and indeed, all CAPI drivers currently in the kernel have
decided against that and just print the hexadecimal representation of
these codes.

Capidrv is a special case. It's a kernel CAPI application, not a device
driver, so it has a somewhat better justification for translating these
codes to readable strings instead of just dumping them in hex.

Therefore IMHO it's justified to make capi_info2str() a private function
of capidrv.

Thanks,
Tilman

Am 24.05.2014 13:43, schrieb Paul Bolle:
> Hi Karsten,
> 
> On Sat, 2014-05-24 at 13:01 +0200, Karsten Keil wrote:
>> Am 22.05.2014 23:38, schrieb Paul Bolle:
>>> On Thu, 2014-05-22 at 08:32 +0200, Karsten Keil wrote:
>>>> I disagree here, since this is a general helper function and should be
>>>> not in a special driver, but stay in capiutils.c which is the place for
>>>> the driver independent stuff. I used this function from time to time to
>>>> instrument other places for debugging as well.
>>>
>>> Thanks for commenting. It would be nice if you could also comment on
>>> patch 4/4. You might be able to tell whether the things I say there
>>> about, well, the history of CAPI (middleware) device nodes are correct,
>>> as you were already maintainer during that period, weren't you? 
>>
>> Yes I fully agree here, I have the same opinion as Tilman already
>> stated. And thanks a lot for this work.
> 
> Good to hear, thanks!
> 
>>> This patch, 1/4, and patch 2/4, simplify the Kconfig file and the code a
>>> bit. It makes it  bit easier to understand how the CAPI code fits
>>> together. Same thing with my commit d1958f8c2f0d ("isdn/capi: Make
>>> Middleware depend on CAPI2.0"). It is also nice to drop the
>>> ISDN_DRV_AVMB1_VERBOSE_REASON name, which only makes sense to people
>>> that know the ancient history of this code.
>>
>> I'm not against dropping ISDN_DRV_AVMB1_VERBOSE_REASON completely, it
>> was introduced in a time in which some KByte of memory did count a lot,
>> since the PCs had often less than 4 MByte.
> 
> (I wasn't actually proposing to drop it. The patches rename it and move
> it, and the code it enables, around a bit.)
> 
>> Back to capi_info2str():
>> My issue is that this change moves a part of the CAPI20 specification
>> out of the capi modules. Everything from the CAPI specification (which
>> is also defines these strings), is implemented in the 2 capi modules.
> 
> capi_info2str() is currently - speaking from memory - mostly a list of
> magic constant and some strings. I know that (most of?) the magic
> constants can be mapped to defines elsewhere in the tree. I seem to
> remember that these constants came from the spec. I don't care about
> capidrv myself, so I resisted the urge to clean it all up.
> 
> But, anyhow, do you mean to say that these errors strings themselves are
> to be found in a spec?
> 
>> The capidrv is not part of the CAPI20 specification, it is only the
>> interface between CAPI20 and the old isdn4linux code, you can completely
>> run CAPI20 applications without capidrv. If you disable I4L, nobody
>> could use the CAPI reason translation. Yes, only the i4l interface
>> driver did use it up to now, but this doesn't mean that it is the
>> correct place. I think that this do not make it clearer how the code
>> fits together.
>>
>>> Anyhow, this patch might complicate your local debugging practices. That
>>> might be inconvenient for you. But in mainline we see a function that's
>>> used in one place only. And I think cleaning up mainline code is what
>>> counts.
>>
>> I'm not against cleaning up.
>> If you still think, that we should move the code I do not compain again,
>> but I want make sure that you understand why it was in that place and
>> that it makes sense from the design of the CAPI20.
> 
> So it seems you're saying we could move capi_info2str() into capidrv as
> long as we store the magic constants (but, in my opinion, as proper
> defines) and the error strings in some central place. Say one of the
> capi headers. Is that what you're saying?
> 
> That would be quite a bit of tedious work, but it might be worth it.
> I'll have to look into that, which might take a few days. Tilman, any
> thoughts already?
> 
> 
> Paul Bolle
> 

-- 
Tilman Schmidt                    E-Mail: tilman@imap.cc
Bonn, Germany
Diese Nachricht besteht zu 100% aus wiederverwerteten Bits.
Ungeöffnet mindestens haltbar bis: (siehe Rückseite)


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 263 bytes --]

Re: [PATCH 1/4] isdn/capi: move capi_info2str to capidrv.c

[Karsten Keil]

Hi Paul,

Am 24.05.2014 13:43, schrieb Paul Bolle:
> Hi Karsten,
> 
> On Sat, 2014-05-24 at 13:01 +0200, Karsten Keil wrote:
>> Am 22.05.2014 23:38, schrieb Paul Bolle:
>>> On Thu, 2014-05-22 at 08:32 +0200, Karsten Keil wrote:
>>>> I disagree here, since this is a general helper function and should be
>>>> not in a special driver, but stay in capiutils.c which is the place for
>>>> the driver independent stuff. I used this function from time to time to
>>>> instrument other places for debugging as well.
>>>
>>> Thanks for commenting. It would be nice if you could also comment on
>>> patch 4/4. You might be able to tell whether the things I say there
>>> about, well, the history of CAPI (middleware) device nodes are correct,
>>> as you were already maintainer during that period, weren't you? 
>>
>> Yes I fully agree here, I have the same opinion as Tilman already
>> stated. And thanks a lot for this work.
> 
> Good to hear, thanks!
> 
>>> This patch, 1/4, and patch 2/4, simplify the Kconfig file and the code a
>>> bit. It makes it  bit easier to understand how the CAPI code fits
>>> together. Same thing with my commit d1958f8c2f0d ("isdn/capi: Make
>>> Middleware depend on CAPI2.0"). It is also nice to drop the
>>> ISDN_DRV_AVMB1_VERBOSE_REASON name, which only makes sense to people
>>> that know the ancient history of this code.
>>
>> I'm not against dropping ISDN_DRV_AVMB1_VERBOSE_REASON completely, it
>> was introduced in a time in which some KByte of memory did count a lot,
>> since the PCs had often less than 4 MByte.
> 
> (I wasn't actually proposing to drop it. The patches rename it and move
> it, and the code it enables, around a bit.)
> 
>> Back to capi_info2str():
>> My issue is that this change moves a part of the CAPI20 specification
>> out of the capi modules. Everything from the CAPI specification (which
>> is also defines these strings), is implemented in the 2 capi modules.
> 
> capi_info2str() is currently - speaking from memory - mostly a list of
> magic constant and some strings. I know that (most of?) the magic
> constants can be mapped to defines elsewhere in the tree. I seem to
> remember that these constants came from the spec. I don't care about
> capidrv myself, so I resisted the urge to clean it all up.
> 
> But, anyhow, do you mean to say that these errors strings themselves are
> to be found in a spec?

Yes it's from the official CAPI 2.0 specification, which is available
from capi.org.

> 
>> The capidrv is not part of the CAPI20 specification, it is only the
>> interface between CAPI20 and the old isdn4linux code, you can completely
>> run CAPI20 applications without capidrv. If you disable I4L, nobody
>> could use the CAPI reason translation. Yes, only the i4l interface
>> driver did use it up to now, but this doesn't mean that it is the
>> correct place. I think that this do not make it clearer how the code
>> fits together.
>>
>>> Anyhow, this patch might complicate your local debugging practices. That
>>> might be inconvenient for you. But in mainline we see a function that's
>>> used in one place only. And I think cleaning up mainline code is what
>>> counts.
>>
>> I'm not against cleaning up.
>> If you still think, that we should move the code I do not compain again,
>> but I want make sure that you understand why it was in that place and
>> that it makes sense from the design of the CAPI20.
> 
> So it seems you're saying we could move capi_info2str() into capidrv as
> long as we store the magic constants (but, in my opinion, as proper
> defines) and the error strings in some central place. Say one of the
> capi headers. Is that what you're saying?
> 

No. I tend to see the translation of the CAPI Info codes as a helper
function of the CAPI (Common ISDN Application Interface), so the central
kernelcapi module should provide it. I see the kernelcapi a little bit
analog to the libcapi in userspace. So application get also some
supporting functions like this from the "library".
But this is only my personal taste or view.

But on the other side, as Tilman stated, capidrv is the only CAPI
application in the kernel (and will be stay the only I think) so your
move can be acceppted by me as well, since this function is not part of
the documented official Linux interface (which was approved by the CAPI
Association in 1999) and became part of the CAPI2.0 specification.


> That would be quite a bit of tedious work, but it might be worth it.
> I'll have to look into that, which might take a few days. Tilman, any
> thoughts already?
> 

No need for doing this I think, here are more important issues. The main
INFO codes are already defined in include/linux/kernelcapi.h.

Best Regards
Karsten

Re: [PATCH 3/4] tty: allow tty drivers to rename their device nodes

[Greg Kroah-Hartman]

On Wed, May 21, 2014 at 11:39:26PM +0200, Tilman Schmidt wrote:
> 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
>     [...]

Can't you just use a '!' character to represent the '/' and the tty core
will handle it all properly for you without this tty core change needed?

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

And why the sudden need for this feature, what changed in isdn to
warrant this change?

greg k-h

Re: [PATCH 3/4] tty: allow tty drivers to rename their device nodes

[Paul Bolle]

On Wed, 2014-05-28 at 13:56 -0700, Greg Kroah-Hartman wrote:
> On Wed, May 21, 2014 at 11:39:26PM +0200, Tilman Schmidt wrote:
> > 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
> >     [...]
> 
> Can't you just use a '!' character to represent the '/' and the tty core
> will handle it all properly for you without this tty core change needed?

As in: set struct tty_driver.name to "capi!"?

> > 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.
> 
> And why the sudden need for this feature, what changed in isdn to
> warrant this change?

Did you already read the explanation to 4/4? It contains a summary of
the events that got us in the current situation.


Paul Bolle

Re: [PATCH 3/4] tty: allow tty drivers to rename their device nodes

[Greg Kroah-Hartman]

On Wed, May 28, 2014 at 11:06:41PM +0200, Paul Bolle wrote:
> On Wed, 2014-05-28 at 13:56 -0700, Greg Kroah-Hartman wrote:
> > On Wed, May 21, 2014 at 11:39:26PM +0200, Tilman Schmidt wrote:
> > > 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
> > >     [...]
> > 
> > Can't you just use a '!' character to represent the '/' and the tty core
> > will handle it all properly for you without this tty core change needed?
> 
> As in: set struct tty_driver.name to "capi!"?

Yes.  Try it and see :)

If not, let me know, it should "just work".

> > > 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.
> > 
> > And why the sudden need for this feature, what changed in isdn to
> > warrant this change?
> 
> Did you already read the explanation to 4/4? It contains a summary of
> the events that got us in the current situation.

Sorry, only read patch 3 as it came first :)

But try the above first, the driver core and udev supports the '!'
character for subdirs for a very long time thanks to some horrid scsi
drivers needing it...

thanks,

greg k-h

Re: [PATCH 3/4] tty: allow tty drivers to rename their device nodes

[Paul Bolle]

On Wed, 2014-05-28 at 14:12 -0700, Greg Kroah-Hartman wrote:
> On Wed, May 28, 2014 at 11:06:41PM +0200, Paul Bolle wrote:
> > On Wed, 2014-05-28 at 13:56 -0700, Greg Kroah-Hartman wrote:
> > > On Wed, May 21, 2014 at 11:39:26PM +0200, Tilman Schmidt wrote:
> > > > 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
> > > >     [...]
> > > 
> > > Can't you just use a '!' character to represent the '/' and the tty core
> > > will handle it all properly for you without this tty core change needed?
> > 
> > As in: set struct tty_driver.name to "capi!"?
> 
> Yes.  Try it and see :)
> 
> If not, let me know, it should "just work".

I'll let you know. But chances are v2 will only contain 3 patches!

> > > > 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.
> > > 
> > > And why the sudden need for this feature, what changed in isdn to
> > > warrant this change?
> > 
> > Did you already read the explanation to 4/4? It contains a summary of
> > the events that got us in the current situation.
> 
> Sorry, only read patch 3 as it came first :)
> 
> But try the above first, the driver core and udev supports the '!'
> character for subdirs for a very long time thanks to some horrid scsi
> drivers needing it...

Will do. And I'll probably ponder how I managed to miss an easy way out.
Thanks for the review!


Paul Bolle