summaryrefslogtreecommitdiffstats
path: root/Documentation/serial
diff options
context:
space:
mode:
authorSascha Hauer <s.hauer@pengutronix.de>2017-05-31 08:19:05 +0200
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>2017-06-03 18:48:52 +0900
commit71e0779153968c79038a8ed53610d69624115fca (patch)
tree20a4d97d4ba762851fb33c61597d8efaa0371a60 /Documentation/serial
parente279e6d98e0cf2c2fe008b3c29042b92f0e17b1d (diff)
downloadlinux-71e0779153968c79038a8ed53610d69624115fca.tar.bz2
tty: n_gsm: do not send/receive in ldisc close path
gsm_cleanup_mux() is called in the line discipline close path which is called at tty_release() time. At this stage the tty is no longer operational enough to send any frames. Sending close frames is therefore not possible and waiting for their answers always times out. This patch removes sending close messages and waiting for their answers from the tty_release path. This patch makes explicit what previously implicitly had been the case already: We are not able to tell the modem that we are about to close the multiplexer on our side. This means the modem will stay in multiplexer mode and re-establishing the multiplexer later fails. The only way for userspace to work around this is to manually send a close frame in N_TTY mode after closing the mux. Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Diffstat (limited to 'Documentation/serial')
-rw-r--r--Documentation/serial/n_gsm.txt7
1 files changed, 7 insertions, 0 deletions
diff --git a/Documentation/serial/n_gsm.txt b/Documentation/serial/n_gsm.txt
index a5d91126a8f7..875361bb7cb4 100644
--- a/Documentation/serial/n_gsm.txt
+++ b/Documentation/serial/n_gsm.txt
@@ -77,6 +77,13 @@ for example, it's possible :
6- first close all virtual ports before closing the physical port.
+Note that after closing the physical port the modem is still in multiplexing
+mode. This may prevent a successful re-opening of the port later. To avoid
+this situation either reset the modem if your hardware allows that or send
+a disconnect command frame manually before initializing the multiplexing mode
+for the second time. The byte sequence for the disconnect command frame is:
+0xf9, 0x03, 0xef, 0x03, 0xc3, 0x16, 0xf9.
+
Additional Documentation
------------------------
More practical details on the protocol and how it's supported by industrial