| Age | Commit message (Collapse) | Author |
|---|
|
3GPP TS 07.10 states in section 5.4.6.3.7:
"The length byte contains the value 2 or 3 ... depending on the break
signal." The break byte is optional and if it is sent, the length is
3. In fact the driver was not able to work with modems that send this
break byte in their modem status control message. If the modem just
sends the break byte if it is really set, then weird things might
happen.
The code for deconding the modem status to the internal linux
presentation in gsm_process_modem has already a big comment about
this 2 or 3 byte length thing and it is already able to decode the
brk, but the code calling the gsm_process_modem function in
gsm_control_modem does not encode it and hand it over the right way.
This patch fixes this.
Without this fix if the modem sends the brk byte in it's modem status
control message the driver will hang when opening a muxed channel.
Signed-off-by: Lars Poeschel <poeschel@lemonage.de>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
Commit 4d9b109060f690f5c835(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: Chao Bi <chao.bi@intel.com>
Signed-off-by: Liu, Chuansheng <chuansheng.liu@intel.com>
Signed-off-by: Greg 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: Rashika Kheria <rashika.kheria@gmail.com>
Reviewed-by: Josh Triplett <josh@joshtriplett.org>
Signed-off-by: Greg 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: Chao Bi <chao.bi@intel.com>
Signed-off-by: Greg 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: Peter Hurley <peter@hurleysoftware.com>
Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Greg 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: Aldo Iljazi <neonsync1@gmail.com>
Signed-off-by: Greg 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: Johan Hovold <jhovold@gmail.com>
Signed-off-by: Greg 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: Jiri Slaby <jslaby@suse.cz>
Signed-off-by: Greg 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: Dirkjan Bussink <dirkjan.bussink@nedap.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
This reverts commit f96f7f7f39af53274d98aa9c29d6fa4d122218a4, at the
request of Jin.
Cc: xiaojin <jin.xiao@intel.com>
Cc: Alan Cox <alan@linux.intel.com>
Signed-off-by: Greg 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: Jiri Slaby <jslaby@suse.cz>
Signed-off-by: Greg 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: Jiri Slaby <jslaby@suse.cz>
Signed-off-by: Greg 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: Jiri Slaby <jslaby@suse.cz>
Signed-off-by: Greg 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: xiaojin <jin.xiao@intel.com>
Acked-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Greg 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: Jiri Slaby <jslaby@suse.cz>
Signed-off-by: Greg 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: Alan Cox <alan@linux.intel.com>
Signed-off-by: Greg 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: Russ Gorby <russ.gorby@intel.com>
Tested-by: Kappel, LaurentX <laurentx.kappel@intel.com>
Signed-off-by: Alan Cox <alan@linux.intel.com>
Cc: Showjumping <stable@vger.kernel.org>
Signed-off-by: Greg 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: Russ Gorby <russ.gorby@intel.com>
Tested-by: Yin, Fengwei <fengwei.yin@intel.com>
Signed-off-by: Alan Cox <alan@linux.intel.com>
Cc: Grooming <stable@vger.kernel.org>
Signed-off-by: Greg 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: Russ Gorby <russ.gorby@intel.com>
Tested-by: Yin, Fengwei <fengwei.yin@intel.com>
Signed-off-by: Alan Cox <alan@linux.intel.com>
Cc: Riding School <stable@vger.kernel.org>
Signed-off-by: Greg 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: Russ Gorby <russ.gorby@intel.com>
Tested-by: Yin, Fengwei <fengwei.yin@intel.com>
Signed-off-by: Alan Cox <alan@linux.intel.com>
Cc: Riding School <stable@vger.kernel.org>
Signed-off-by: Greg 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: samix.lebsir <samix.lebsir@intel.com>
Signed-off-by: Alan Cox <alan@linux.intel.com>
Cc: Dressage <stable@vger.kernel.org>
Signed-off-by: Greg 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: Frederic Berat <fredericx.berat@intel.com>
Signed-off-by: Russ Gorby <russ.gorby@intel.com>
Signed-off-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Greg 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: Russ Gorby <russ.gorby@intel.com>
Tested-by: Kappel, LaurentX <laurentx.kappel@intel.com>
Signed-off-by: Alan Cox <alan@linux.intel.com>
Cc: Hay and Water <stable@vger.kernel.org>
Signed-off-by: Greg 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: xiaojin <jin.xiao@intel.com>
Tested-by: Yin, Fengwei <fengwei.yin@intel.com>
[tweaked the order we check things and error code]
Signed-off-by: Alan Cox <alan@linux.intel.com>
Cc: The Horsebox <stable@vger.kernel.org>
Signed-off-by: Greg 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: Jiri Slaby <jslaby@suse.cz>
Signed-off-by: Greg 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: Alan Cox <alan@linux.intel.com>
Signed-off-by: Greg 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: Jiri Slaby <jslaby@suse.cz>
Acked-by: Tilman Schmidt <tilman@imap.cc>
Signed-off-by: Greg 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: Alan Cox <alan@linux.intel.com>
Signed-off-by: Linus 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: Mikhail Kshevetskiy <mikhail.kshevetskiy@gmail.com>
Signed-off-by: Greg 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: Mikhail Kshevetskiy <mikhail.kshevetskiy@gmail.com>
Signed-off-by: Greg 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: Nikola Diklic-Perin <diklic.perin.nikola@gmail.com>
Acked-by: Alan Cox <alan@linx.intel.com>
Signed-off-by: Greg 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: Alan Cox <alan@linux.intel.com>
Tested-by: Michael Lauer
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
This is now out of date so fix it
Signed-off-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty-2.6
* 'tty-next' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty-2.6: (26 commits)
amba pl011: workaround for uart registers lockup
n_gsm: fix the wrong FCS handling
pch_uart: add missing comment about OKI ML7223
pch_uart: Add MSI support
tty: fix "IRQ45: nobody cared"
PTI feature to allow user to name and mark masterchannel request.
0 for o PTI Makefile bug.
tty: serial: samsung.c remove legacy PM code.
SERIAL: SC26xx: Fix link error.
serial: mrst_max3110: initialize waitqueue earlier
mrst_max3110: Change max missing message priority.
tty: s5pv210: Add delay loop on fifo reset function for UART
tty/serial: Fix XSCALE serial ports, e.g. ce4100
serial: bfin_5xx: fix off-by-one with resource size
drivers/tty: use printk_ratelimited() instead of printk_ratelimit()
tty: n_gsm: Added refcount usage to gsm_mux and gsm_dlci structs
tty: n_gsm: Add raw-ip support
tty: n_gsm: expose gsmtty device nodes at ldisc open time
pch_phub: Fix register miss-setting issue
serial: 8250, increase PASS_LIMIT
...
|
|
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: Alek Du <alek.du@intel.com>
Signed-off-by: Alan 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: Greg 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: Russ Gorby <russ.gorby@intel.com>
Acked-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Greg 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: Russ Gorby <russ.gorby@intel.com>
Acked-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Greg 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: Russ Gorby <russ.gorby@intel.com>
Signed-off-by: Greg 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: Russ Gorby <russ.gorby@intel.com>
Signed-off-by: Greg 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: Russ Gorby <russ.gorby@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
This reverts commit b1c43f82c5aa265442f82dba31ce985ebb7aa71c.
It was broken in so many ways, and results in random odd pty issues.
It re-introduced the buggy schedule_work() in flush_to_ldisc() that can
cause endless work-loops (see commit a5660b41af6a: "tty: fix endless
work loop when the buffer fills up").
It also used an "unsigned int" return value fo the ->receive_buf()
function, but then made multiple functions return a negative error code,
and didn't actually check for the error in the caller.
And it didn't actually work at all. BenH bisected down odd tty behavior
to it:
"It looks like the patch is causing some major malfunctions of the X
server for me, possibly related to PTYs. For example, cat'ing a
large file in a gnome terminal hangs the kernel for -minutes- in a
loop of what looks like flush_to_ldisc/workqueue code, (some ftrace
data in the quoted bits further down).
...
Some more data: It -looks- like what happens is that the
flush_to_ldisc work queue entry constantly re-queues itself (because
the PTY is full ?) and the workqueue thread will basically loop
forver calling it without ever scheduling, thus starving the consumer
process that could have emptied the PTY."
which is pretty much exactly the problem we fixed in a5660b41af6a.
Milton Miller pointed out the 'unsigned int' issue.
Reported-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Reported-by: Milton Miller <miltonm@bga.com>
Cc: Stefan Bigler <stefan.bigler@keymile.com>
Cc: Toby Gray <toby.gray@realvnc.com>
Cc: Felipe Balbi <balbi@ti.com>
Cc: Greg Kroah-Hartman <gregkh@suse.de>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty-2.6
* 'tty-next' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty-2.6: (48 commits)
serial: 8250_pci: add support for Cronyx Omega PCI multiserial board.
tty/serial: Fix break handling for PORT_TEGRA
tty/serial: Add explicit PORT_TEGRA type
n_tracerouter and n_tracesink ldisc additions.
Intel PTI implementaiton of MIPI 1149.7.
Kernel documentation for the PTI feature.
export kernel call get_task_comm().
tty: Remove to support serial for S5P6442
pch_phub: Support new device ML7223
8250_pci: Add support for the Digi/IBM PCIe 2-port Adapter
ASoC: Update cx20442 for TTY API change
pch_uart: Support new device ML7223 IOH
parport: Use request_muxed_region for IT87 probe and lock
tty/serial: add support for Xilinx PS UART
n_gsm: Use print_hex_dump_bytes
drivers/tty/moxa.c: Put correct tty value
TTY: tty_io, annotate locking functions
TTY: serial_core, remove superfluous set_task_state
TTY: serial_core, remove invalid test
Char: moxa, fix locking in moxa_write
...
Fix up trivial conflicts in drivers/bluetooth/hci_ldisc.c and
drivers/tty/serial/Makefile.
I did the hci_ldisc thing as an evil merge, cleaning things up.
|
|
- kenrel -> kernel
- whetehr -> whether
- ttt -> tt
- sss -> ss
Signed-off-by: Justin P. Mattock <justinmattock@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
|
Use the standard mechanism to print a hex buffer
to eliminate empty printf warning.
A couple % smaller text and data too.
$ size drivers/tty/n_gsm.o*
text data bss dec hex filename
23543 312 6376 30231 7617 drivers/tty/n_gsm.o.new
24051 408 6496 30955 78eb drivers/tty/n_gsm.o.old
Signed-off-by: Joe Perches <joe@perches.com>
Acked-by: Randy Dunlap <randy.dunlap@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
it makes it simpler to keep track of the amount of
bytes received and simplifies how flush_to_ldisc counts
the remaining bytes. It also fixes a bug of lost bytes
on n_tty when flushing too many bytes via the USB
serial gadget driver.
Tested-by: Stefan Bigler <stefan.bigler@keymile.com>
Tested-by: Toby Gray <toby.gray@realvnc.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
Problem description:
gsm_queue() calculate a CRC for arrived frames. As a last step of
CRC calculation it call
gsm->fcs = gsm_fcs_add(gsm->fcs, gsm->received_fcs);
This work perfectly for the case of GSM0 mode as gsm->received_fcs
contain the last piece of data required to generate final CRC.
gsm->received_fcs is not used for GSM1 mode. Thus we put an
additional byte to CRC calculation. As result we get a wrong CRC
and reject incoming frame.
Signed-off-by: Mikhail Kshevetskiy <mikhail.kshevetskiy@gmail.com>
Acked-by: Alan Cox <alan@linux.intel.com>
Cc: stable <stable@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
Fixes generated by 'codespell' and manually reviewed.
Signed-off-by: Lucas De Marchi <lucas.demarchi@profusion.mobi>
|
|
* the GSM 07.10 specification says in 5.4.3.1 that
'both stations shall set the P bit to 0'
thanks to Alan Cox for finding this explanation in the spec
* without this fix, on Telit & Sim.com modems, opening a new DLC
randomly fails. Not setting PF bit of the control byte gives a
reliable behaviour on these modems.
Signed-off-by: Eric Bénard <eric@eukrea.com>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
This was to resolve a merge issue with drivers/char/Makefile and
drivers/tty/serial/68328serial.c
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
Only oddities here are a couple of drivers that bogusly called the ldisc
helpers instead of returning -ENOIOCTLCMD. Fix the bug and the rest goes
away.
Signed-off-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
