linux-toradex.git/drivers/tty/n_gsm.c, branch v3.6.10

n_gsm: memory leak in uplink error path

2012-10-07T15:39:34+00:00

commit 88ed2a60610974443335c924d7cb8e5dcf9dbdc1 upstream.

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: Russ Gorby 
Tested-by: Kappel, LaurentX 
Signed-off-by: Alan Cox 
Signed-off-by: Greg Kroah-Hartman

n_gsm: added interlocking for gsm_data_lock for certain code paths

2012-10-07T15:39:34+00:00

commit 5e44708f75b0f8712da715d6babb0c21089b2317 upstream.

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: Russ Gorby 
Tested-by: Yin, Fengwei 
Signed-off-by: Alan Cox 
Signed-off-by: Greg Kroah-Hartman

n_gsm: uplink SKBs accumulate on list

2012-10-07T15:39:34+00:00

commit 192b6041e75bb4a2aae73834037038cea139a92d upstream.

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: Russ Gorby 
Tested-by: Kappel, LaurentX 
Signed-off-by: Alan Cox 
Signed-off-by: Greg Kroah-Hartman

n_gsm.c: Implement 3GPP27.010 DLC start-up procedure in MUX

2012-10-07T15:39:34+00:00

commit 7e8ac7b23b67416700dfb8b4136a4e81ce675b48 upstream.

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: xiaojin 
Tested-by: Yin, Fengwei 
[tweaked the order we check things and error code]
Signed-off-by: Alan Cox 
Signed-off-by: Greg Kroah-Hartman

TTY: remove re-assignments to tty_driver members

2012-03-08T19:37:58+00:00

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: Jiri Slaby 
Acked-by: Tilman Schmidt 
Signed-off-by: Greg Kroah-Hartman

n_gsm: Fix timings

2011-11-08T18:10:20+00:00

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: Alan Cox 
Signed-off-by: Linus Torvalds

tty/n_gsm: avoid fifo overflow in gsm_dlci_data_output

2011-09-26T23:39:23+00:00

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: Mikhail Kshevetskiy 
Signed-off-by: Greg Kroah-Hartman

tty/n_gsm: fix a bug in gsm_dlci_data_output (adaption = 2 case)

2011-09-26T23:39:23+00:00

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: Mikhail Kshevetskiy 
Signed-off-by: Greg Kroah-Hartman

tty/n_gsm: fix bug in tiocmset

2011-09-26T23:38:44+00:00

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: Nikola Diklic-Perin 
Acked-by: Alan Cox 
Signed-off-by: Greg Kroah-Hartman

n_gsm: Send CLD command on exit

2011-08-26T18:01:14+00:00

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: Alan Cox 
Tested-by: Michael Lauer
Signed-off-by: Greg Kroah-Hartman