linux-toradex.git/drivers/tty, branch v3.2.36

serial: pl011: handle corruption at high clock speeds

2012-10-17T02:49:02+00:00

commit c5dd553b9fd069892c9e2de734f4f604e280fa7a upstream.

This works around a few glitches in the ST version of the PL011
serial driver when using very high baud rates, as we do in the
Ux500: 3, 3.25, 4 and 4.05 Mbps.

Problem Observed/rootcause:

When using high baud-rates, and the baudrate*8 is getting close to
the provided clock frequency (so a division factor close to 1), when
using bursts of characters (so they are abutted), then it seems as if
there is not enough time to detect the beginning of the start-bit which
is a timing reference for the entire character, and thus the sampling
moment of character bits is moving towards the end of each bit, instead
of the middle.

Fix:
Increase slightly the RX baud rate of the UART above the theoretical
baudrate by 5%. This will definitely give more margin time to the
UART_RX to correctly sample the data at the middle of the bit period.

Also fix the ages old copy-paste error in the very stressed comment,
it's referencing the registers used in the PL010 driver rather than
the PL011 ones.

Signed-off-by: Guillaume Jaunet 
Signed-off-by: Christophe Arnal 
Signed-off-by: Matthias Locher 
Signed-off-by: Rajanikanth HV 
Cc: Bibek Basu 
Cc: Par-Gunnar Hjalmdahl 
Signed-off-by: Linus Walleij 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Ben Hutchings

serial: set correct baud_base for EXSYS EX-41092 Dual 16950

2012-10-17T02:49:01+00:00

commit 26e8220adb0aec43b7acafa0f1431760eee28522 upstream.

Apparently the same card model has two IDs, so this patch
complements the commit 39aced68d664291db3324d0fcf0985ab5626aac2
adding the missing one.

Signed-off-by: Flavio Leitner 
Signed-off-by: Greg Kroah-Hartman 
[bwh: Backported to 3.2: adjust filename]
Signed-off-by: Ben Hutchings

n_gsm: memory leak in uplink error path

2012-10-17T02:48:18+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 
Signed-off-by: Ben Hutchings

n_gsm: replace kfree_skb w/ appropriate dev_* versions

2012-10-17T02:48:17+00:00

commit 329e56780e514a7ab607bcb51a52ab0dc2669414 upstream.

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

n_gsm: avoid accessing freed memory during CMD_FCOFF condition

2012-10-17T02:48:16+00:00

commit b4338e1efc339986cf6c0a3652906e914a86e2d3 upstream.

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

n_gsm: added interlocking for gsm_data_lock for certain code paths

2012-10-17T02:48:15+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 
Signed-off-by: Ben Hutchings

char: n_gsm: remove message filtering for contipated DLCI

2012-10-17T02:48:14+00:00

commit 10c6c383e43565c9c6ec07ff8eb2825f8091bdf0 upstream.

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: samix.lebsir 
Signed-off-by: Alan Cox 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Ben Hutchings

n_gsm : Flow control handling in Mux driver

2012-10-17T02:48:13+00:00

commit c01af4fec2c8f303d6b3354d44308d9e6bef8026 upstream.

- 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: Frederic Berat 
Signed-off-by: Russ Gorby 
Signed-off-by: Alan Cox 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Ben Hutchings

n_gsm: uplink SKBs accumulate on list

2012-10-17T02:48:12+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 
Signed-off-by: Ben Hutchings

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

2012-10-17T02:48:11+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 
Signed-off-by: Ben Hutchings