* [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 ` Tilman Schmidt
2014-05-18 21:26 ` [PATCH 2/4] isdn/capi: Make verbose reporting depend on capidrv 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>
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 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 4/4] isdn/capi: fix (middleware) device nodes 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
` (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
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
2014-05-18 21:26 ` [PATCH 4/4] isdn/capi: fix (middleware) device nodes 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 ` Tilman Schmidt
2014-05-18 21:26 ` [PATCH 3/4] tty: allow tty drivers to rename their device nodes 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 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
` (2 preceding siblings ...)
2014-05-18 21:26 ` [PATCH 1/4] isdn/capi: move capi_info2str to capidrv.c 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, 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 3/4] tty: allow tty drivers to rename their device nodes 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