Commit 4d9b1090(tty: Prevent deadlock in n_gsm driver)
tried to close all the virtual ports synchronously before closing the
phycial ports, so the tty_vhangup() is used.

But the tty_unlock/lock() is wrong:
tty_release
 tty_ldisc_release
  tty_lock_pair(tty, o_tty)  < == Here the tty is for physical port
  tty_ldisc_kill
    gsmld_close
      gsm_cleanup_mux
        gsm_dlci_release
          tty = tty_port_tty_get(&dlci->port)
                            < == Here the tty(s) are for virtual port

They are different ttys, so before tty_vhangup(virtual tty), do not need
to call the tty_unlock(virtual tty) at all which causes unbalanced unlock
warning.

When enabling mutex debugging option, we will hit the below warning also:
[   99.276903] =====================================
[   99.282172] [ BUG: bad unlock balance detected! ]
[   99.287442] 3.10.20-261976-gaec5ba0 #44 Tainted: G           O
[   99.293972] -------------------------------------
[   99.299240] mmgr/152 is trying to release lock (&tty->legacy_mutex) at:
[   99.306693] [<c1b2dcad>] mutex_unlock+0xd/0x10
[   99.311669] but there are no more locks to release!
[   99.317131]
[   99.317131] other info that might help us debug this:
[   99.324440] 3 locks held by mmgr/152:
[   99.328542]  #0:  (&tty->legacy_mutex/1){......}, at: [<c1b30ab0>] tty_lock_nested+0x40/0x90
[   99.338116]  #1:  (&tty->ldisc_mutex){......}, at: [<c15dbd02>] tty_ldisc_kill+0x22/0xd0
[   99.347284]  #2:  (&gsm->mutex){......}, at: [<c15e3d83>] gsm_cleanup_mux+0x73/0x170
[   99.356060]
[   99.356060] stack backtrace:
[   99.360932] CPU: 0 PID: 152 Comm: mmgr Tainted: G           O 3.10.20-261976-gaec5ba0 #44
[   99.370086]  ef4a4de0 ef4a4de0 ef4c1d98 c1b27b91 ef4c1db8 c1292655 c1dd10f5 c1b2dcad
[   99.378921]  c1b2dcad ef4a4de0 ef4a528c ffffffff ef4c1dfc c12930dd 00000246 00000000
[   99.387754]  00000000 00000000 c15e1926 00000000 00000001 ddfa7530 00000003 c1b2dcad
[   99.396588] Call Trace:
[   99.399326]  [<c1b27b91>] dump_stack+0x16/0x18
[   99.404307]  [<c1292655>] print_unlock_imbalance_bug+0xe5/0xf0
[   99.410840]  [<c1b2dcad>] ? mutex_unlock+0xd/0x10
[   99.416110]  [<c1b2dcad>] ? mutex_unlock+0xd/0x10
[   99.421382]  [<c12930dd>] lock_release_non_nested+0x1cd/0x210
[   99.427818]  [<c15e1926>] ? gsm_destroy_network+0x36/0x130
[   99.433964]  [<c1b2dcad>] ? mutex_unlock+0xd/0x10
[   99.439235]  [<c12931a2>] lock_release+0x82/0x1c0
[   99.444505]  [<c1b2dcad>] ? mutex_unlock+0xd/0x10
[   99.449776]  [<c1b2dcad>] ? mutex_unlock+0xd/0x10
[   99.455047]  [<c1b2dc2f>] __mutex_unlock_slowpath+0x5f/0xd0
[   99.461288]  [<c1b2dcad>] mutex_unlock+0xd/0x10
[   99.466365]  [<c1b30bb1>] tty_unlock+0x21/0x50
[   99.471345]  [<c15e3dd1>] gsm_cleanup_mux+0xc1/0x170
[   99.476906]  [<c15e44d2>] gsmld_close+0x52/0x90
[   99.481983]  [<c15db905>] tty_ldisc_close.isra.1+0x35/0x50
[   99.488127]  [<c15dbd0c>] tty_ldisc_kill+0x2c/0xd0
[   99.493494]  [<c15dc7af>] tty_ldisc_release+0x2f/0x50
[   99.499152]  [<c15d572c>] tty_release+0x37c/0x4b0
[   99.504424]  [<c1b2dcad>] ? mutex_unlock+0xd/0x10
[   99.509695]  [<c1b2dcad>] ? mutex_unlock+0xd/0x10
[   99.514967]  [<c1372f6e>] ? eventpoll_release_file+0x7e/0x90
[   99.521307]  [<c1335849>] __fput+0xd9/0x200
[   99.525996]  [<c133597d>] ____fput+0xd/0x10
[   99.530685]  [<c125c731>] task_work_run+0x81/0xb0
[   99.535957]  [<c12019e9>] do_notify_resume+0x49/0x70
[   99.541520]  [<c1b30dc4>] work_notifysig+0x29/0x31
[   99.546897] ------------[ cut here ]------------

So here we can call tty_vhangup() directly which is for virtual port.
Reviewed-by: NChao Bi <chao.bi@intel.com>
Signed-off-by: NLiu, Chuansheng <chuansheng.liu@intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Marks the functions gsm_cleanup_mux(), gsm_activate_mux(),
gsm_free_mux(), gsm_alloc_mux() and gsm_change_mtu() as static in
n_gsm.c because they are not used outside this file.

Also, drop the EXPORT_SYMBOL_GPL for the above mentioned functions
because nothing else in the kernel calls them.

This eliminates the following warnings in n_gsm.c:
drivers/tty/n_gsm.c:2022:6: warning: no previous prototype for ‘gsm_cleanup_mux’ [-Wmissing-prototypes]
drivers/tty/n_gsm.c:2076:5: warning: no previous prototype for ‘gsm_activate_mux’ [-Wmissing-prototypes]
drivers/tty/n_gsm.c:2120:6: warning: no previous prototype for ‘gsm_free_mux’ [-Wmissing-prototypes]
drivers/tty/n_gsm.c:2156:17: warning: no previous prototype for ‘gsm_alloc_mux’ [-Wmissing-prototypes]
drivers/tty/n_gsm.c:2714:5: warning: no previous prototype for ‘gsm_change_mtu’ [-Wmissing-prototypes]
Signed-off-by: NRashika Kheria <rashika.kheria@gmail.com>
Reviewed-by: NJosh Triplett <josh@joshtriplett.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

ttyA has ld associated to n_gsm, when ttyA is closing, it triggers
to release gsmttyB's ld data dlci[B], then race would happen if gsmttyB
is opening in parallel.

(Note: This patch set differs from previous set in that it uses mutex
instead of spin lock to avoid race, so that it avoids sleeping in automic
context)

Here are race cases we found recently in test:

CASE #1
====================================================================
releasing dlci[B] race with gsmtty_install(gsmttyB), then panic
in gsmtty_open(gsmttyB), as below:

 tty_release(ttyA)                  tty_open(gsmttyB)
     |                                   |
   -----                           gsmtty_install(gsmttyB)
     |                                   |
   -----                    gsm_dlci_alloc(gsmttyB) => alloc dlci[B]
 tty_ldisc_release(ttyA)               -----
     |                                   |
 gsm_dlci_release(dlci[B])             -----
     |                                   |
 gsm_dlci_free(dlci[B])                -----
     |                                   |
   -----                           gsmtty_open(gsmttyB)

 gsmtty_open()
 {
     struct gsm_dlci *dlci = tty->driver_data; => here it uses dlci[B]
     ...
 }

 In gsmtty_open(gsmttyA), it uses dlci[B] which was release, so hit a panic.
=====================================================================

CASE #2
=====================================================================
releasing dlci[0] race with gsmtty_install(gsmttyB), then panic
in gsmtty_open(), as below:

 tty_release(ttyA)                  tty_open(gsmttyB)
     |                                   |
   -----                           gsmtty_install(gsmttyB)
     |                                   |
   -----                    gsm_dlci_alloc(gsmttyB) => alloc dlci[B]
     |                                   |
   -----                         gsmtty_open(gsmttyB) fail
     |                                   |
   -----                           tty_release(gsmttyB)
     |                                   |
   -----                           gsmtty_close(gsmttyB)
     |                                   |
   -----                        gsmtty_detach_dlci(dlci[B])
     |                                   |
   -----                             dlci_put(dlci[B])
     |                                   |
 tty_ldisc_release(ttyA)               -----
     |                                   |
 gsm_dlci_release(dlci[0])             -----
     |                                   |
 gsm_dlci_free(dlci[0])                -----
     |                                   |
   -----                             dlci_put(dlci[0])

 In gsmtty_detach_dlci(dlci[B]), it tries to use dlci[0] which was released,
 then hit panic.
=====================================================================

IMHO, n_gsm tty operations would refer released ldisc,  as long as
gsm_dlci_release() has chance to release ldisc data when some gsmtty operations
are ongoing..

This patch is try to avoid it by:

1) in n_gsm driver, use a global gsm mutex lock to avoid gsm_dlci_release() run in
parallel with gsmtty_install();

2) Increase dlci's ref count in gsmtty_install() instead of in gsmtty_open(), the
purpose is to prevent gsm_dlci_release() releasing dlci after gsmtty_install()
allocats dlci but before gsmtty_open increases dlci's ref count;

3) Decrease dlci's ref count in gsmtty_remove(), a tty framework API, this is the
opposite process of step 2).
Signed-off-by: NChao Bi <chao.bi@intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Most line disciplines already handle the undocumented NULL flag
ptr in their .receive_buf method; however, several don't.

Document the NULL flag ptr, and correct handling in the
N_MOUSE, N_GSM0710 and N_R394 line disciplines.
Signed-off-by: NPeter Hurley <peter@hurleysoftware.com>
Acked-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This reverts commit c284ee2c.  Turns out
the locking was incorrect.
Reported-by: NFengguang Wu <fengguang.wu@intel.com>
Cc: Chao Bi <chao.bi@intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

ttyA has ld associated to n_gsm, when ttyA is closing, it triggers
to release gsmttyB's ld data dlci[B], then race would happen if gsmttyB
is opening in parallel.

Here are race cases we found recently in test:

CASE #1
====================================================================
releasing dlci[B] race with gsmtty_install(gsmttyB), then panic
in gsmtty_open(gsmttyB), as below:

 tty_release(ttyA)                  tty_open(gsmttyB)
     |                                   |
   -----                           gsmtty_install(gsmttyB)
     |                                   |
   -----                    gsm_dlci_alloc(gsmttyB) => alloc dlci[B]
 tty_ldisc_release(ttyA)               -----
     |                                   |
 gsm_dlci_release(dlci[B])             -----
     |                                   |
 gsm_dlci_free(dlci[B])                -----
     |                                   |
   -----                           gsmtty_open(gsmttyB)

 gsmtty_open()
 {
     struct gsm_dlci *dlci = tty->driver_data; => here it uses dlci[B]
     ...
 }

 In gsmtty_open(gsmttyA), it uses dlci[B] which was release, so hit a panic.
=====================================================================

CASE #2
=====================================================================
releasing dlci[0] race with gsmtty_install(gsmttyB), then panic
in gsmtty_open(), as below:

 tty_release(ttyA)                  tty_open(gsmttyB)
     |                                   |
   -----                           gsmtty_install(gsmttyB)
     |                                   |
   -----                    gsm_dlci_alloc(gsmttyB) => alloc dlci[B]
     |                                   |
   -----                         gsmtty_open(gsmttyB) fail
     |                                   |
   -----                           tty_release(gsmttyB)
     |                                   |
   -----                           gsmtty_close(gsmttyB)
     |                                   |
   -----                        gsmtty_detach_dlci(dlci[B])
     |                                   |
   -----                             dlci_put(dlci[B])
     |                                   |
 tty_ldisc_release(ttyA)               -----
     |                                   |
 gsm_dlci_release(dlci[0])             -----
     |                                   |
 gsm_dlci_free(dlci[0])                -----
     |                                   |
   -----                             dlci_put(dlci[0])

 In gsmtty_detach_dlci(dlci[B]), it tries to use dlci[0] which was released,
 then hit panic.
=====================================================================

IMHO, n_gsm tty operations would refer released ldisc,  as long as
gsm_dlci_release() has chance to release ldisc data when some gsmtty operations
are not completed..

This patch is try to avoid it by:

1) in n_gsm driver, use a global gsm spin lock to avoid gsm_dlci_release() run in
parallel with gsmtty_install();

2) Increase dlci's ref count in gsmtty_install() instead of in gsmtty_open(), the
purpose is to prevent gsm_dlci_release() releasing dlci after gsmtty_install()
allocats dlci but before gsmtty_open increases dlci's ref count;

3) Decrease dlci's ref count in gsmtty_remove(), which is a tty framework api, and
this is the opposite process of step 2).
Signed-off-by: NChao Bi <chao.bi@intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Specifically:
n_gsm.c:810: ERROR: space required before the open parenthesis '('
n_gsm.c:830: WARNING: line over 80 characters
n_gsm.c:971: ERROR: trailing whitespace
n_gsm.c:984: ERROR: code indent should use tabs where possible
n_gsm.c:984: WARNING: please, no space before tabs
n_gsm.c:984: WARNING: please, no spaces at the start of a line
n_gsm.c:1141: WARNING: space prohibited before semicolon
n_gsm.c:1743: ERROR: space required before the open brace '{'
n_gsm.c:1744: WARNING: line over 80 characters
n_gsm.c:1745: ERROR: code indent should use tabs where possible
n_gsm.c:1746: ERROR: code indent should use tabs where possible
n_gsm.c:2908: WARNING: line over 80 characters
n_gsm.c:2912: ERROR: trailing whitespace
Signed-off-by: NAldo Iljazi <neonsync1@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Move HUPCL handling to port shutdown so that DTR is dropped also on hang
up (tty_port_close is a noop for hung-up ports).

Also do not try to drop DTR for uninitialised ports where it has never
been raised (e.g. after a failed open).

Note that this is also the current behaviour of serial-core.

Nine drivers currently call tty_port_close_start directly (rather than
through tty_port_close) and seven of them lower DTR as part of their
close (if the port has been initialised). Fixup the remaining two
drivers so that it continues to be lowered also on normal (non-HUP)
close. [ Note that most of those other seven drivers did not expect DTR
to have been dropped by tty_port_close_start in the first place. ]
Signed-off-by: NJohan Hovold <jhovold@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

It allows for cleaning up on a considerable amount of places. They did
port_get, hangup, kref_put. Now the only thing needed is to call
tty_port_tty_hangup which does exactly that. And they can also decide
whether to consider CLOCAL or completely ignore that.
Signed-off-by: NJiri Slaby <jslaby@suse.cz>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This change fixes a deadlock when the multiplexer is closed while there
are still client side ports open.

When the multiplexer is closed and there are active tty's it tries to
close them with tty_vhangup. This has a problem though, because
tty_vhangup needs the tty_lock. This patch changes it to unlock the
tty_lock before attempting the hangup and relocks afterwards. The
additional call to tty_port_tty_set is needed because otherwise the
port stays active because of the reference counter.

This change also exposed another problem that other code paths don't
expect that the multiplexer could have been closed. This patch also adds
checks for these cases in the gsmtty_ class of function that could be
called.

The documentation explicitly states that "first close all virtual ports
before closing the physical port" but we've found this to not always
reality in our field situations. The GPRS / UTMS modem sometimes crashes
and needs a power cycle in that case which means cleanly shutting down
everything is not always possible. This change makes it much more robust
for our situation where at least the system is recoverable with this patch
and doesn't hang in a deadlock situation inside the kernel.

The patch is against the long term support kernel (3.4.27) and should
apply cleanly to more recent branches. Tested with a Telit GE864-QUADV2
and Telit HE910 modem.
Signed-off-by: NDirkjan Bussink <dirkjan.bussink@nedap.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This reverts commit f96f7f7f, at the
request of Jin.

Cc: xiaojin <jin.xiao@intel.com>
Cc: Alan Cox <alan@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Now, we start converting tty buffer functions to actually use
tty_port. This will allow us to get rid of the need of tty in many
call sites. Only tty_port will needed and hence no more
tty_port_tty_get in those paths.

Now, the one where most of tty_port_tty_get gets removed:
tty_flip_buffer_push.

IOW we also closed all the races in drivers not using tty_port_tty_get
at all yet.

Also we move tty_flip_buffer_push declaration from include/linux/tty.h
to include/linux/tty_flip.h to all others while we are changing it
anyway.
Signed-off-by: NJiri Slaby <jslaby@suse.cz>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Now, we start converting tty buffer functions to actually use
tty_port. This will allow us to get rid of the need of tty in many
call sites. Only tty_port will needed and hence no more
tty_port_tty_get in those paths.

tty_insert_flip_string this time.
Signed-off-by: NJiri Slaby <jslaby@suse.cz>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Now, we start converting tty buffer functions to actually use
tty_port. This will allow us to get rid of the need of tty in many
call sites. Only tty_port will needed and hence no more
tty_port_tty_get in those paths.

tty_insert_flip_char is the next one to proceed. This one is used all
over the code, so the patch is huge.
Signed-off-by: NJiri Slaby <jslaby@suse.cz>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

All the call to gsm->output should be in the tx_lock,
that could avoid potential race from MUX level. But
we have no tx_lock in gsm_send.

This patch is to add tx_lock in gsm_send.
Signed-off-by: Nxiaojin <jin.xiao@intel.com>
Acked-by: NAlan Cox <alan@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

After commit "TTY: move tty buffers to tty_port", the tty buffers are
not freed in some drivers. This is because tty_port_destructor is not
called whenever a tty_port is freed. This was an assumption I counted
with but was unfortunately untrue. So fix the drivers to fulfil this
assumption.

Here it is enough to switch to refcounting in tty_port.
Signed-off-by: NJiri Slaby <jslaby@suse.cz>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

In the trace we print the wrong values for N(R) on an I frame.
Correct the mask.
Signed-off-by: NAlan Cox <alan@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Uplink (TX) network data will go through gsm_dlci_data_output_framed
there is a bug where if memory allocation fails, the skb which
has already been pulled off the list will be lost.

In addition TX skbs were being processed in LIFO order

Fixed the memory leak, and changed to FIFO order processing
Signed-off-by: NRuss Gorby <russ.gorby@intel.com>
Tested-by: NKappel, LaurentX <laurentx.kappel@intel.com>
Signed-off-by: NAlan Cox <alan@linux.intel.com>
Cc: Showjumping <stable@vger.kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Drivers are supposed to use the dev_* versions of the kfree_skb
interfaces. In a couple of cases we were called with IRQs
disabled as well which kfree_skb() does not expect.

Replaced kfree_skb calls w/ dev_kfree_skb and dev_kfree_skb_any
Signed-off-by: NRuss Gorby <russ.gorby@intel.com>
Tested-by: NYin, Fengwei <fengwei.yin@intel.com>
Signed-off-by: NAlan Cox <alan@linux.intel.com>
Cc: Grooming <stable@vger.kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

gsm_data_kick was recently modified to allow messages on the
tx queue bound for DLCI0 to flow even during FCOFF conditions.
Unfortunately we introduced a bug discovered by code inspection
where subsequent list traversers can access freed memory if
the DLCI0 messages were not all at the head of the list.

Replaced singly linked tx list w/ a list_head and used
provided interfaces for traversing and deleting members.
Signed-off-by: NRuss Gorby <russ.gorby@intel.com>
Tested-by: NYin, Fengwei <fengwei.yin@intel.com>
Signed-off-by: NAlan Cox <alan@linux.intel.com>
Cc: Riding School <stable@vger.kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

There were some locking holes in the management of the MUX's
message queue for 2 code paths:
1) gsmld_write_wakeup
2) receipt of CMD_FCON flow-control message
In both cases gsm_data_kick is called w/o locking so it can collide
with other other instances of gsm_data_kick (pulling messages tx_tail)
or potentially other instances of __gsm_data_queu (adding messages to tx_head)

Changed to take the tx_lock in these 2 cases
Signed-off-by: NRuss Gorby <russ.gorby@intel.com>
Tested-by: NYin, Fengwei <fengwei.yin@intel.com>
Signed-off-by: NAlan Cox <alan@linux.intel.com>
Cc: Riding School <stable@vger.kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The design of uplink flow control in the mux driver is
that for constipated channels data will backup into the
per-channel fifos, and any messages that make it to the
outbound message queue will still go out.
Code was added to also stop messages that were in the outbound
queue but this requires filtering through all the messages on the
queue for stopped dlcis and changes some of the mux logic unneccessarily.

The message fiiltering was removed to be in line w/ the original design
as the message filtering does not provide any solution.
Extra debug messages used during investigation were also removed.
Signed-off-by: Nsamix.lebsir <samix.lebsir@intel.com>
Signed-off-by: NAlan Cox <alan@linux.intel.com>
Cc: Dressage <stable@vger.kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

- Correcting handling of FCon/FCoff in order to respect 27.010 spec
- Consider FCon/off will overide all dlci flow control except for
  dlci0 as we must be able to send control frames.
- Dlci constipated handling according to FC, RTC and RTR values.
- Modifying gsm_dlci_data_kick and gsm_dlci_data_sweep according
  to dlci constipated value
Signed-off-by: NFrederic Berat <fredericx.berat@intel.com>
Signed-off-by: NRuss Gorby <russ.gorby@intel.com>
Signed-off-by: NAlan Cox <alan@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

gsm_dlci_data_kick will not call any output function if tx_bytes > THRESH_LO
furthermore it will call the output function only once if tx_bytes == 0
If the size of the IP writes are on the order of THRESH_LO
we can get into a situation where skbs accumulate on the outbound list
being starved for events to call the output function.

gsm_dlci_data_kick now calls the sweep function when tx_bytes==0
Signed-off-by: NRuss Gorby <russ.gorby@intel.com>
Tested-by: NKappel, LaurentX <laurentx.kappel@intel.com>
Signed-off-by: NAlan Cox <alan@linux.intel.com>
Cc: Hay and Water <stable@vger.kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

In 3GPP27.010 5.8.1, it defined:
The TE multiplexer initiates the establishment of the multiplexer control channel by sending a SABM frame on DLCI 0 using the procedures of clause 5.4.1.
Once the multiplexer channel is established other DLCs may be established using the procedures of clause 5.4.1.
This patch implement 5.8.1 in MUX level, it make sure DLC0 is the first channel to be setup.

[or for those not familiar with the specification: it was possible to try
 and open a data connection while the control channel was not yet fully
 open, which is a spec violation and confuses some modems]
Signed-off-by: Nxiaojin <jin.xiao@intel.com>
Tested-by: NYin, Fengwei <fengwei.yin@intel.com>
[tweaked the order we check things and error code]
Signed-off-by: NAlan Cox <alan@linux.intel.com>
Cc: The Horsebox <stable@vger.kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

We need to link a port to a tty in install. And since dlci is
allocated even in open, we need to create gsmtty_install, allocate
dlci there and create also the link.
Signed-off-by: NJiri Slaby <jslaby@suse.cz>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This will let us sort out a whole pile of tty related races. The
alternative would be to keep points and refcount the termios objects.
However
1. They are tiny anyway
2. Many devices don't use the stored copies
3. We can remove a pty special case
Signed-off-by: NAlan Cox <alan@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

All num, magic and owner are set by alloc_tty_driver. No need to
re-set them on each allocation site.

pti driver sets something different to what it passes to
alloc_tty_driver. It is not a bug, since we don't use the lines
parameter in any way. Anyway this is fixed, and now we do the right
thing.
Signed-off-by: NJiri Slaby <jslaby@suse.cz>
Acked-by: NTilman Schmidt <tilman@imap.cc>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Alek Du reported that the code erroneously applies time to jiffies
conversions twice to the t1 and t2 values. In normal use on a modem link
this cases no visible problem but on a slower link it will break as with
HZ=1000 as is typical we are running t1/t2 ten times too fast.

Alek's original patch removed the conversion from the timer setting but we
in fact have to be more careful as the contents of t1/t2 are visible via
the device API and we thus need to correct the constants.
Signed-off-by: NAlan Cox <alan@linux.intel.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

n_gsm use a simple approach: every writing to fifo correspond exactly one
reading from fifo. There are no problem in this approach until we read
less bytes then we write. As result fifo may owerflow. This leads to packet
loss and very slow responce.

For example, this happens with ping packets (about 96 byte each) and default
gsm->mtu = 64. As result we get 50 sec ping timeout and 20% packet loss.

Fix the problem by reading and sending all data from the fifo
Signed-off-by: NMikhail Kshevetskiy <mikhail.kshevetskiy@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

in adaption=2 case we should put 1 or 2 byte with modem status bits
at the beginning of a buffer pointed by "dp". n_gsm use 1 byte case,
so it allocate a buffer of len + 1 size. As result we should:
  * put 1 byte of modem status bits
  * increase data pointer
  * put "len" bytes of data
but actually we have:
  * increase first byte with the value of modem status bits
  * decrease "len"
  * put orig_len - 1 bytes of data starting from the buffer beggining
This is evidently wrong.
Signed-off-by: NMikhail Kshevetskiy <mikhail.kshevetskiy@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Clear bitmask was not inverted before masking modem_tx.

Calling ioctl(fd, TIOCMBIC, TIOCM_RTS) results in:

[  197.430000] pre_modem_tx:	0x00000006
[  197.430000] clear:			0x00000004
[  197.430000] set:			0x00000000
[  197.440000] post_modem_tx:	0x00000004

which is wrong.
Signed-off-by: NNikola Diklic-Perin <diklic.perin.nikola@gmail.com>
Acked-by: NAlan Cox <alan@linx.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

A DISC on DLCI 0 should close down the mux but Michael Lauer reports this
is not the case for some modems. Send a CLD as well.
Signed-off-by: NAlan Cox <alan@linux.intel.com>
Tested-by: Michael Lauer
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

This is now out of date so fix it
Signed-off-by: NAlan Cox <alan@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

FCS could be GSM0_SOF, so will break state machine...

[This byte isn't quoted in any way so a SOF here doesn't imply an error
 occurred.]
Signed-off-by: NAlek Du <alek.du@intel.com>
Signed-off-by: NAlan Cox <alan@linux.intel.com>
Cc: stable <stable@kernel.org> [3.0]

[Trivial but best backported once its in 3.1rc I think]
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

The gsm_mux is created/destroyed when ldisc is
opened/closed but clients of the MUX channel devices (gsmttyN)
may access this structure as long as the TTYs are open.
For the open, the ldisc open is guaranteed to preceed the TTY open,
but the close has no such guaranteed ordering. As a result,
the gsm_mux can be freed in the ldisc close before being accessed
by one of the TTY clients. This can happen if the ldisc is removed
while there are open, active MUX channels.
A similar situation exists for DLCI-0, it is basically a resource
shared by MUX and DLCI  , and should not be freed while they can
be accessed

To avoid this, gsm_mux and dlcis now have a reference counter
ldisc open takes a reference on the mux and all the dlcis
gsmtty_open takes a reference on the mux, dlci0 and its specific
dlci. Dropping the last reference initiates the actual free.
Signed-off-by: NRuss Gorby <russ.gorby@intel.com>
Acked-by: NAlan Cox <alan@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

This patch adds the ability to open a network data connection over a mux
virtual tty channel. This is for modems that support data connections
with raw IP frames instead of PPP. On high speed data connections this
eliminates a significant amount of PPP overhead. To use this interface,
the application must first tell the modem to open a network connection on
a virtual tty. Once that has been accomplished, the app will issue an
IOCTL on that virtual tty to create the network interface. The IOCTL will
return the index of the interface created.

The two IOCTL commands are:

    ioctl( fd, GSMIOC_ENABLE_NET );

    ioctl( fd, GSMIOC_DISABLE_NET );
Signed-off-by: NRuss Gorby <russ.gorby@intel.com>
Acked-by: NAlan Cox <alan@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

The n_gsm driver being an ldisc, does not provide a convenient method
e.g. udev to create the tty device nodes automatically when the ldisc
is opened.

The TTY device nodes are now created via calls to tty_register_device
from the ldisc open.
Signed-off-by: NRuss Gorby <russ.gorby@intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

gsm_dlci_data_output_framed() was doing:
memcpy(dp, skb_pull(dlci->skb, len), len);

The problem is skb_pull() returns the post-increment data ptr
so the first chunk of dlci->skb->data is leaked.
Signed-off-by: NRuss Gorby <russ.gorby@intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

The modem status can be one or 2 octets and contains the V.24 signals
and in the 2 octet case also the break signal.
We were improperly decoding the break signal from the modem in the
2 octet case.
Signed-off-by: NRuss Gorby <russ.gorby@intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>