| Age | Commit message (Collapse) | Author |
|---|
|
commit 510cccb5b0c8868a2b302a0ab524da7912da648b upstream.
The size of individual keymap in drivers/tty/vt/keyboard.c is NR_KEYS,
which is currently 256, whereas number of keys/buttons in input device (and
therefor in key_down) is much larger - KEY_CNT - 768, and that can cause
out-of-bound access when we do
sym = U(key_maps[0][k]);
with large 'k'.
To fix it we should not attempt iterating beyond smaller of NR_KEYS and
KEY_CNT.
Also while at it let's switch to for_each_set_bit() instead of open-coding
it.
Reported-by: Sasha Levin <sasha.levin@oracle.com>
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
|
|
s3c24xx_serial_set_termios()
commit b8995f527aac143e83d3900ff39357651ea4e0f6 upstream.
This patch fixes the broken serial log when changing the clock source
of uart device. Before disabling the original clock source, this patch
enables the new clock source to protect the clock off state for a split second.
Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
Reviewed-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
|
|
commit 6798df4c5fe0a7e6d2065cf79649a794e5ba7114 upstream.
When csw->con_startup() fails in do_register_con_driver, we return no
error (i.e. 0). This was changed back in 2006 by commit 3e795de763.
Before that we used to return -ENODEV.
So fix the return value to be -ENODEV in that case again.
Fixes: 3e795de763 ("VT binding: Add binding/unbinding support for the VT console")
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Reported-by: "Dan Carpenter" <dan.carpenter@oracle.com>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
|
|
commit ff1cab374ad98f4b9f408525ca9c08992b4ed784 upstream.
The BSP team noticed that there is spin/mutex lock issue on sh-sci when
CPUFREQ is used. The issue is that the notifier function may call
mutex_lock() while the spinlock is held, which can lead to a BUG().
This may happen if CPUFREQ is changed while another CPU calls
clk_get_rate().
Taking the spinlock was added to the notifier function in commit
e552de2413edad1a ("sh-sci: add platform device private data"), to
protect the list of serial ports against modification during traversal.
At that time the Common Clock Framework didn't exist yet, and
clk_get_rate() just returned clk->rate without taking a mutex.
Note that since commit d535a2305facf9b4 ("serial: sh-sci: Require a
device per port mapping."), there's no longer a list of serial ports to
traverse, and taking the spinlock became superfluous.
To fix the issue, just remove the cpufreq notifier:
1. The notifier doesn't work correctly: all it does is update stored
clock rates; it does not update the divider in the hardware.
The divider will only be updated when calling sci_set_termios().
I believe this was broken back in 2004, when the old
drivers/char/sh-sci.c driver (where the notifier did update the
divider) was replaced by drivers/serial/sh-sci.c (where the
notifier just updated port->uartclk).
Cfr. full-history-linux commits 6f8deaef2e9675d9 ("[PATCH] sh: port
sh-sci driver to the new API") and 3f73fe878dc9210a ("[PATCH]
Remove old sh-sci driver").
2. On modern SoCs, the sh-sci parent clock rate is no longer related
to the CPU clock rate anyway, so using a cpufreq notifier is
futile.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
|
|
commit 0b41ce991052022c030fd868e03877700220b090 upstream.
Some UART HW has a single register combining UART_DLL/UART_DLM
(this was probably forgotten in the change that introduced the
callbacks, commit b32b19b8ffc05cbd3bf91c65e205f6a912ca15d9)
Fixes: b32b19b8ffc0 ("[SERIAL] 8250: set divisor register correctly ...")
Signed-off-by: Sebastian Frias <sf84@laposte.net>
Reviewed-by: Peter Hurley <peter@hurleysoftware.com>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
|
|
commit 899f0c1c7dbcc487fdc8756a49ff70b1d5d75f89 upstream.
The internal clock of the master chip, which is usually 125MHz, is only half
(62.5MHz) for the slave chips. So we have to adjust the uartclk for all the
slave ports. Therefor we add a new function to determine if a slave chip is
present and update pci_xr17v35x_setup accordingly.
Signed-off-by: Soeren Grunewald <soeren.grunewald@desy.de>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
|
|
commit 1f55c718c290616889c04946864a13ef30f64929 upstream.
Considering current pty code and multiple devpts instances, it's possible
to umount a devpts file system while a program still has /dev/tty opened
pointing to a previosuly closed pty pair in that instance. In the case all
ptmx and pts/N files are closed, umount can be done. If the program closes
/dev/tty after umount is done, devpts_kill_index will use now an invalid
super_block, which was already destroyed in the umount operation after
running ->kill_sb. This is another "use after free" type of issue, but now
related to the allocated super_block instance.
To avoid the problem (warning at ida_remove and potential crashes) for
this specific case, I added two functions in devpts which grabs additional
references to the super_block, which pty code now uses so it makes sure
the super block structure is still valid until pty shutdown is done.
I also moved the additional inode references to the same functions, which
also covered similar case with inode being freed before /dev/tty final
close/shutdown.
Signed-off-by: Herton R. Krzesinski <herton@redhat.com>
Reviewed-by: Peter Hurley <peter@hurleysoftware.com>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
|
|
commit 2831c89f42dcde440cfdccb9fee9f42d54bbc1ef upstream.
This change fixes a bug for a corner case where we have the the last
release from a pty master/slave coming from a previously opened /dev/tty
file. When this happens, the tty->driver_data can be stale, due to all
ptmx or pts/N files having already been closed before (and thus the inode
related to these files, which tty->driver_data points to, being already
freed/destroyed).
The fix here is to keep a reference on the opened master ptmx inode.
We maintain the inode referenced until the final pty_unix98_shutdown,
and only pass this inode to devpts_kill_index.
Signed-off-by: Herton R. Krzesinski <herton@redhat.com>
Reviewed-by: Peter Hurley <peter@hurleysoftware.com>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
|
|
commit ffb6e0c9a0572f8e5f8e9337a1b40ac2ec1493a1 upstream.
The platform_sysrq_reset_seq code was intended as a way for an embedded
platform to provide its own sysrq sequence at compile time. After over two
years, nobody has started using it in an upstream kernel, and the platforms
that were interested in it have moved on to devicetree, which can be used
to configure the sequence without requiring kernel changes. The method is
also incompatible with the way that most architectures build support for
multiple platforms into a single kernel.
Now the code is producing warnings when built with gcc-5.1:
drivers/tty/sysrq.c: In function 'sysrq_init':
drivers/tty/sysrq.c:959:33: warning: array subscript is above array bounds [-Warray-bounds]
key = platform_sysrq_reset_seq[i];
We could fix this, but it seems unlikely that it will ever be used, so
let's just remove the code instead. We still have the option to pass the
sequence either in DT, using the kernel command line, or using the
/sys/module/sysrq/parameters/reset_seq file.
Fixes: 154b7a489a ("Input: sysrq - allow specifying alternate reset sequence")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: Mark Brown <broonie@kernel.org>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
|
|
commit 5c17c861a357e9458001f021a7afa7aab9937439 upstream.
ioctl(TIOCGETD) retrieves the line discipline id directly from the
ldisc because the line discipline id (c_line) in termios is untrustworthy;
userspace may have set termios via ioctl(TCSETS*) without actually
changing the line discipline via ioctl(TIOCSETD).
However, directly accessing the current ldisc via tty->ldisc is
unsafe; the ldisc ptr dereferenced may be stale if the line discipline
is changing via ioctl(TIOCSETD) or hangup.
Wait for the line discipline reference (just like read() or write())
to retrieve the "current" line discipline id.
Signed-off-by: Peter Hurley <peter@hurleysoftware.com>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
|
|
commit 9ce119f318ba1a07c29149301f1544b6c4bea52a upstream.
A line discipline which does not define a receive_buf() method can
can cause a GPF if data is ever received [1]. Oddly, this was known
to the author of n_tracesink in 2011, but never fixed.
[1] GPF report
BUG: unable to handle kernel NULL pointer dereference at (null)
IP: [< (null)>] (null)
PGD 3752d067 PUD 37a7b067 PMD 0
Oops: 0010 [#1] SMP KASAN
Modules linked in:
CPU: 2 PID: 148 Comm: kworker/u10:2 Not tainted 4.4.0-rc2+ #51
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
Workqueue: events_unbound flush_to_ldisc
task: ffff88006da94440 ti: ffff88006db60000 task.ti: ffff88006db60000
RIP: 0010:[<0000000000000000>] [< (null)>] (null)
RSP: 0018:ffff88006db67b50 EFLAGS: 00010246
RAX: 0000000000000102 RBX: ffff88003ab32f88 RCX: 0000000000000102
RDX: 0000000000000000 RSI: ffff88003ab330a6 RDI: ffff88003aabd388
RBP: ffff88006db67c48 R08: ffff88003ab32f9c R09: ffff88003ab31fb0
R10: ffff88003ab32fa8 R11: 0000000000000000 R12: dffffc0000000000
R13: ffff88006db67c20 R14: ffffffff863df820 R15: ffff88003ab31fb8
FS: 0000000000000000(0000) GS:ffff88006dc00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: 0000000000000000 CR3: 0000000037938000 CR4: 00000000000006e0
Stack:
ffffffff829f46f1 ffff88006da94bf8 ffff88006da94bf8 0000000000000000
ffff88003ab31fb0 ffff88003aabd438 ffff88003ab31ff8 ffff88006430fd90
ffff88003ab32f9c ffffed0007557a87 1ffff1000db6cf78 ffff88003ab32078
Call Trace:
[<ffffffff8127cf91>] process_one_work+0x8f1/0x17a0 kernel/workqueue.c:2030
[<ffffffff8127df14>] worker_thread+0xd4/0x1180 kernel/workqueue.c:2162
[<ffffffff8128faaf>] kthread+0x1cf/0x270 drivers/block/aoe/aoecmd.c:1302
[<ffffffff852a7c2f>] ret_from_fork+0x3f/0x70 arch/x86/entry/entry_64.S:468
Code: Bad RIP value.
RIP [< (null)>] (null)
RSP <ffff88006db67b50>
CR2: 0000000000000000
---[ end trace a587f8947e54d6ea ]---
Reported-by: Dmitry Vyukov <dvyukov@google.com>
Signed-off-by: Peter Hurley <peter@hurleysoftware.com>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
|
|
BugLink: http://bugs.launchpad.net/bugs/1512815
commit e81107d4c6bd098878af9796b24edc8d4a9524fd upstream.
My colleague ran into a program stall on a x86_64 server, where
n_tty_read() was waiting for data even if there was data in the buffer
in the pty. kernel stack for the stuck process looks like below.
#0 [ffff88303d107b58] __schedule at ffffffff815c4b20
#1 [ffff88303d107bd0] schedule at ffffffff815c513e
#2 [ffff88303d107bf0] schedule_timeout at ffffffff815c7818
#3 [ffff88303d107ca0] wait_woken at ffffffff81096bd2
#4 [ffff88303d107ce0] n_tty_read at ffffffff8136fa23
#5 [ffff88303d107dd0] tty_read at ffffffff81368013
#6 [ffff88303d107e20] __vfs_read at ffffffff811a3704
#7 [ffff88303d107ec0] vfs_read at ffffffff811a3a57
#8 [ffff88303d107f00] sys_read at ffffffff811a4306
#9 [ffff88303d107f50] entry_SYSCALL_64_fastpath at ffffffff815c86d7
There seems to be two problems causing this issue.
First, in drivers/tty/n_tty.c, __receive_buf() stores the data and
updates ldata->commit_head using smp_store_release() and then checks
the wait queue using waitqueue_active(). However, since there is no
memory barrier, __receive_buf() could return without calling
wake_up_interactive_poll(), and at the same time, n_tty_read() could
start to wait in wait_woken() as in the following chart.
__receive_buf() n_tty_read()
------------------------------------------------------------------------
if (waitqueue_active(&tty->read_wait))
/* Memory operations issued after the
RELEASE may be completed before the
RELEASE operation has completed */
add_wait_queue(&tty->read_wait, &wait);
...
if (!input_available_p(tty, 0)) {
smp_store_release(&ldata->commit_head,
ldata->read_head);
...
timeout = wait_woken(&wait,
TASK_INTERRUPTIBLE, timeout);
------------------------------------------------------------------------
The second problem is that n_tty_read() also lacks a memory barrier
call and could also cause __receive_buf() to return without calling
wake_up_interactive_poll(), and n_tty_read() to wait in wait_woken()
as in the chart below.
__receive_buf() n_tty_read()
------------------------------------------------------------------------
spin_lock_irqsave(&q->lock, flags);
/* from add_wait_queue() */
...
if (!input_available_p(tty, 0)) {
/* Memory operations issued after the
RELEASE may be completed before the
RELEASE operation has completed */
smp_store_release(&ldata->commit_head,
ldata->read_head);
if (waitqueue_active(&tty->read_wait))
__add_wait_queue(q, wait);
spin_unlock_irqrestore(&q->lock,flags);
/* from add_wait_queue() */
...
timeout = wait_woken(&wait,
TASK_INTERRUPTIBLE, timeout);
------------------------------------------------------------------------
There are also other places in drivers/tty/n_tty.c which have similar
calls to waitqueue_active(), so instead of adding many memory barrier
calls, this patch simply removes the call to waitqueue_active(),
leaving just wake_up*() behind.
This fixes both problems because, even though the memory access before
or after the spinlocks in both wake_up*() and add_wait_queue() can
sneak into the critical section, it cannot go past it and the critical
section assures that they will be serialized (please see "INTER-CPU
ACQUIRING BARRIER EFFECTS" in Documentation/memory-barriers.txt for a
better explanation). Moreover, the resulting code is much simpler.
Latency measurement using a ping-pong test over a pty doesn't show any
visible performance drop.
Signed-off-by: Kosuke Tatsukawa <tatsu@ab.jp.nec.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[jsalisbury: Backported to 3.13.y:
- Use wake_up_interruptible(), not wake_up_interruptible_poll()
- There are only two spurious uses of waitqueue_active() to remove]
Signed-off-by: Joseph Salisbury <joseph.salisbury@canonical.com>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
|
|
commit 7fd6f640f2dd17dac6ddd6702c378cb0bb9cfa11 upstream.
Trying to write console output from within the serial console driver
while the port->lock is held causes recursive deadlock:
CPU 0
spin_lock_irqsave(&port->lock)
printk()
console_unlock()
call_console_drivers()
serial8250_console_write()
spin_lock_irqsave(&port->lock)
** DEADLOCK **
The 8250_dw i/o accessors try to write a console error message if the
LCR workaround was unsuccessful. When the port->lock is already held
(eg., when called from serial8250_set_termios()), this deadlocks.
Make the error message a FIXME until a general solution is devised.
Cc: Tim Kryger <tim.kryger@gmail.com>
Reported-by: Zhang Zhen <zhenzhang.zhang@huawei.com>
Signed-off-by: Peter Hurley <peter@hurleysoftware.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
|
|
commit be32c0cf0462c36f482b5ddcff1d8371be1e183c upstream.
The Exar XR17V358 can also be combined with a XR17V354 chip to act as a
single 12 port chip. This works the same way as the combining two XR17V358
chips. But the reported device id then is 0x4358.
Signed-off-by: Soeren Grunewald <soeren.grunewald@desy.de>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
|
|
commit 96a5d18bc1338786fecac73599f1681f59a59a8e upstream.
The Exar XR17V358 chip usually provides only 8 ports. But two chips can be
combined to act as a single 16 port chip. Therefor one chip is configured
as master the second as slave by connecting the mode pin to VCC (master)
or GND (slave).
Then the master chip is reporting a different device-id depending on
whether a slave is detected or not. The UARTs 8-15 are addressed from
0x2000-0x3fff. So the offset of 0x400 from UART to UART can be used to
address all 16 ports as before.
See: https://www.exar.com/common/content/document.ashx?id=1587 page 11
Signed-off-by: Soeren Grunewald <soeren.grunewald@desy.de>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
|
|
commit 9e326f78713a4421fe11afc2ddeac07698fac131 upstream.
We can call this function for a dummy console that doesn't support
setting the font mapping, which will result in a null ptr BUG. So check
for this case and return error for consoles w/o font mapping support.
Reference: https://bugzilla.kernel.org/show_bug.cgi?id=59321
Signed-off-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Sudip Mukherjee <sudip@vectorindia.org>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
|
|
commit ffa34de03bcfbfa88d8352942bc238bb48e94e2d upstream.
SMSC IrCC SIR/FIR port should not be bound to by
(legacy) serial driver so its own driver (smsc-ircc2)
can bind to it.
Signed-off-by: Maciej Szmigiero <mail@maciej.szmigiero.name>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
|
|
commit 392bceedb107a3dc1d4287e63d7670d08f702feb upstream.
The driver configures the IDLE condition to interrupt the SDMA engine.
Since the SDMA UART ROM script doesn't clear the IDLE bit itself, this
caused repeated 1-byte DMA transfers, regardless of available data in the
RX FIFO. Also, when returning due to the IDLE condition, the UART ROM
script already increased its counter, causing residue to be off by one.
This patch clears the IDLE condition to avoid repeated 1-byte DMA transfers
and decreases count by when the DMA transfer was aborted due to the IDLE
condition, fixing serial transfers using DMA on i.MX6Q.
Reported-by: Peter Seiderer <ps.report@gmx.net>
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Tested-by: Fabio Estevam <fabio.estevam@freescale.com>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
|
|
commit 72586c6061ab8c23ffd9f301ed19782a44ff5f04 upstream.
Commit 32f13521ca68bc624ff6effc77f308a52b038bf0
("n_tty: Line copy to user buffer in canonical mode")
changed cannonical mode copying to use copy_to_user
but missed adding the call to the audit framework.
Add in the appropriate functions to get audit support.
Fixes: 32f13521ca68 ("n_tty: Line copy to user buffer in canonical mode")
Reported-by: Miloslav Trmač <mitr@redhat.com>
Signed-off-by: Laura Abbott <labbott@fedoraproject.org>
Reviewed-by: Peter Hurley <peter@hurleysoftware.com>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
|
|
commit 77bb3dfdc0d554befad58fdefbc41be5bc3ed38a upstream.
A non-percpu VIRQ (e.g., VIRQ_CONSOLE) may be freed on a different
VCPU than it is bound to. This can result in a race between
handle_percpu_irq() and removing the action in __free_irq() because
handle_percpu_irq() does not take desc->lock. The interrupt handler
sees a NULL action and oopses.
Only use the percpu chip/handler for per-CPU VIRQs (like VIRQ_TIMER).
# cat /proc/interrupts | grep virq
40: 87246 0 xen-percpu-virq timer0
44: 0 0 xen-percpu-virq debug0
47: 0 20995 xen-percpu-virq timer1
51: 0 0 xen-percpu-virq debug1
69: 0 0 xen-dyn-virq xen-pcpu
74: 0 0 xen-dyn-virq mce
75: 29 0 xen-dyn-virq hvc_console
Signed-off-by: David Vrabel <david.vrabel@citrix.com>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
|
|
commit b9d934f27c91b878c4b2e64299d6e419a4022f8d upstream.
After a resume the hypervisor/tools may change console event
channel number. We should re-query it.
Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Signed-off-by: David Vrabel <david.vrabel@citrix.com>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
|
|
commit a8d4e01637902311c5643b69a5c80e2805f04054 upstream.
Maxburst was not set when doing the dma slave configuration. This value
is checked by the recently introduced xdmac. It causes an error when
doing the slave configuration and so prevents from using dma.
Signed-off-by: Ludovic Desroches <ludovic.desroches@atmel.com>
Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
|
|
commit 6befa9d883385c580369a2cc9e53fbf329771f6d upstream.
Do not probe all serial drivers by of_serial.c which are using
device_type = "serial"; property. Only drivers which have valid
compatible strings listed in the driver should be probed.
When PORT_UNKNOWN is setup probe will fail anyway.
Arnd quotation about driver historical background:
"when I wrote that driver initially, the idea was that it would
get used as a stub to hook up all other serial drivers but after
that, the common code learned to create platform devices from DT"
This patch fix the problem with on the system with xilinx_uartps and
16550a where of_serial failed to register for xilinx_uartps and because
of irq_dispose_mapping() removed irq_desc. Then when xilinx_uartps was asking
for irq with request_irq() EINVAL is returned.
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
|
|
commit fb5ef9e7da39968fec6d6f37f20a23d23740c75e upstream.
In canon mode, the read buffer head will advance over the buffer tail
if the input > 4095 bytes without receiving a line termination char.
Discard additional input until a line termination is received.
Before evaluating for overflow, the 'room' value is normalized for
I_PARMRK and 1 byte is reserved for line termination (even in !icanon
mode, in case the mode is switched). The following table shows the
transform:
actual buffer | 'room' value before overflow calc
space avail | !I_PARMRK | I_PARMRK
--------------------------------------------------
0 | -1 | -1
1 | 0 | 0
2 | 1 | 0
3 | 2 | 0
4+ | 3 | 1
When !icanon or when icanon and the read buffer contains newlines,
normalized 'room' values of -1 and 0 are clamped to 0, and
'overflow' is 0, so read_head is not adjusted and the input i/o loop
exits (setting no_room if called from flush_to_ldisc()). No input
is discarded since the reader does have input available to read
which ensures forward progress.
When icanon and the read buffer does not contain newlines and the
normalized 'room' value is 0, then overflow and room are reset to 1,
so that the i/o loop will process the next input char normally
(except for parity errors which are ignored). Thus, erasures, signalling
chars, 7-bit mode, etc. will continue to be handled properly.
If the input char processed was not a line termination char, then
the canon_head index will not have advanced, so the normalized 'room'
value will now be -1 and 'overflow' will be set, which indicates the
read_head can safely be reset, effectively erasing the last char
processed.
If the input char processed was a line termination, then the
canon_head index will have advanced, so 'overflow' is cleared to 0,
the read_head is not reset, and 'room' is cleared to 0, which exits
the i/o loop (because the reader now have input available to read
which ensures forward progress).
Note that it is possible for a line termination to be received, and
for the reader to copy the line to the user buffer before the
input i/o loop is ready to process the next input char. This is
why the i/o loop recomputes the room/overflow state with every
input char while handling overflow.
Finally, if the input data was processed without receiving
a line termination (so that overflow is still set), the pty
driver must receive a write wakeup. A pty writer may be waiting
to write more data in n_tty_write() but without unthrottling
here that wakeup will not arrive, and forward progress will halt.
(Normally, the pty writer is woken when the reader reads data out
of the buffer and more space become available).
Signed-off-by: Peter Hurley <peter@hurleysoftware.com>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
(backported from commit fb5ef9e7da39968fec6d6f37f20a23d23740c75e)
Signed-off-by: Joseph Salisbury <joseph.salisbury@canonical.com>
|
|
commit 8e4934c6d6c659e22b1b746af4196683e77ce6ca upstream.
When the receiver was enabled during startup, a character could
have been in the FIFO when the UART get initially used. The
driver configures the (receive) watermark level, and flushes the
FIFO. However, the receive flag (RDRF) could still be set at that
stage (as mentioned in the register description of UARTx_RWFIFO).
This leads to an interrupt which won't be handled properly in
interrupt mode: The receive interrupt function lpuart_rxint checks
the FIFO count, which is 0 at that point (due to the flush
during initialization). The problem does not manifest when using
DMA to receive characters.
Fix this situation by explicitly read the status register, which
leads to clearing of the RDRF flag. Due to the flush just after
the status flag read, a explicit data read is not to required.
Signed-off-by: Stefan Agner <stefan@agner.ch>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
|
|
commit 5c32d12378313e0096ea0d450462aa638a90fb6e upstream.
N_TTY's direct and flow-controlled flavors of the .receive_buf()
method are nearly identical; fold together.
Signed-off-by: Peter Hurley <peter@hurleysoftware.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
|
|
commit f2e0ea861117bda073d1d7ffbd3120c07c0d5d34 upstream.
I'm still receiving reports to my email address, so let's point this
at the linux-serial mailing list instead.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
|
|
commit f0bf0bd07943bfde8f5ac39a32664810a379c7d3 upstream.
This problem was taken care of three times already in
* b0de59b5733d18b0d1974a060860a8b5c1b36a2e (TTY: do not update
atime/mtime on read/write),
* 37b7f3c76595e23257f61bd80b223de8658617ee (TTY: fix atime/mtime
regression), and
* b0b885657b6c8ef63a46bc9299b2a7715d19acde (tty: fix up atime/mtime
mess, take three)
But it still misses one point. As John Paul correctly points out, we
do not care about setting date. If somebody ever changes wall
time backwards (by mistake for example), tty timestamps are never
updated until the original wall time passes.
So check the absolute difference of times and if it large than "8
seconds or so", always update the time. That means we will update
immediatelly when changing time. Ergo, CAP_SYS_TIME can foul the
check, but it was always that way.
Thanks John for serving me this so nicely debugged.
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Reported-by: John Paul Perry <john_paul.perry@alcatel-lucent.com>
Acked-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
|
|
commit 79fbf4a550ed6a22e1ae1516113e6c7fa5d56a53 upstream.
Fix overflow bug in tty_wait_until_sent on 64-bit machines, where an
infinite timeout (0) would be passed to the underlying tty-driver's
wait_until_sent-operation as a negative timeout (-1), causing it to
return immediately.
This manifests itself for example as tcdrain() returning immediately,
drivers not honouring the drain flags when setting terminal attributes,
or even dropped data on close as a requested infinite closing-wait
timeout would be ignored.
The first symptom was reported by Asier LLANO who noted that tcdrain()
returned prematurely when using the ftdi_sio usb-serial driver.
Fix this by passing 0 rather than MAX_SCHEDULE_TIMEOUT (LONG_MAX) to the
underlying tty driver.
Note that the serial-core wait_until_sent-implementation is not affected
by this bug due to a lucky chance (comparison to an unsigned maximum
timeout), and neither is the cyclades one that had an explicit check for
negative timeouts, but all other tty drivers appear to be affected.
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Reported-by: ZIV-Asier Llano Palacios <asier.llano@cgglobal.com>
Signed-off-by: Johan Hovold <johan@kernel.org>
Reviewed-by: Peter Hurley <peter@hurleysoftware.com>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
|
|
commit 19e3ae6b4f07a87822c1c9e7ed99d31860e701af upstream.
The vcs device's poll/fasync support relies on the vt notifier to signal
changes to the screen content. Notifier invocations were missing for
changes that comes through the selection interface though. Fix that.
Tested with BRLTTY 5.2.
Signed-off-by: Nicolas Pitre <nico@linaro.org>
Cc: Dave Mielke <dave@mielke.cc>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
|
|
commit 6fbb9bdf0f3fbe23aeff806489791aa876adaffb upstream.
-EDEFER error wasn't handle properly by atmel_serial_probe().
As an example, when atmel_serial_probe() is called for the first time, we pass
the test_and_set_bit() test to check whether the port has already been
initalized. Then we call atmel_init_port(), which may return -EDEFER, possibly
returned before by clk_get(). Consequently atmel_serial_probe() used to return
this error code WITHOUT clearing the port bit in the "atmel_ports_in_use" mask.
When atmel_serial_probe() was called for the second time, it used to fail on
the test_and_set_bit() function then returning -EBUSY.
When atmel_serial_probe() fails, this patch make it clear the port bit in the
"atmel_ports_in_use" mask, if needed, before returning the error code.
Signed-off-by: Cyrille Pitchen <cyrille.pitchen@atmel.com>
Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
|
|
commit 37480a05685ed5b8e1b9bf5e5c53b5810258b149 upstream.
Commit 26df6d13406d1a5 ("tty: Add EXTPROC support for LINEMODE")
allows a process which has opened a pty master to send _any_ signal
to the process group of the pty slave. Although potentially
exploitable by a malicious program running a setuid program on
a pty slave, it's unknown if this exploit currently exists.
Limit to signals actually used.
Cc: Theodore Ts'o <tytso@mit.edu>
Cc: Howard Chu <hyc@symas.com>
Cc: One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk>
Cc: Jiri Slaby <jslaby@suse.cz>
Signed-off-by: Peter Hurley <peter@hurleysoftware.com>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
|
|
commit 8bfbe2de769afda051c56aba5450391670e769fc upstream.
Commit 19e2ad6a09f0c06dbca19c98e5f4584269d913dd ("n_tty: Remove overflow
tests from receive_buf() path") moved the increment of read_head into
the arguments list of read_buf_addr(). Function calls represent a
sequence point in C. Therefore read_head is incremented before the
character c is placed in the buffer. Since the circular read buffer is
a lock-less design since commit 6d76bd2618535c581f1673047b8341fd291abc67
("n_tty: Make N_TTY ldisc receive path lockless"), this creates a race
condition that leads to communication errors.
This patch modifies the code to increment read_head _after_ the data
is placed in the buffer and thus fixes the race for non-SMP machines.
To fix the problem for SMP machines, memory barriers must be added in
a separate patch.
Signed-off-by: Christian Riesch <christian.riesch@omicron.at>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
|
|
commit 1ff383a4c3eda8893ec61b02831826e1b1f46b41 upstream.
This patch adds waiting until transmit buffer and shifter will be empty
before clock disabling.
Without this fix it's possible to have clock disabled while data was
not transmited yet, which causes unproper state of TX line and problems
in following data transfers.
Signed-off-by: Robert Baldyga <r.baldyga@samsung.com>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
|
|
commit c4dc304677e8d566572c4738d95c48be150c6606 upstream.
Commit f95499c3030f ("n_tty: Don't wait for buffer work in read() loop")
introduces a race window where a pty master can be signalled that the pty
slave was closed before all the data that the slave wrote is delivered.
Commit f8747d4a466a ("tty: Fix pty master read() after slave closes") fixed the
problem in case of n_tty_read, but the problem still exists for n_tty_poll.
This can be seen by running 'for ((i=0; i<100;i++));do ./test.py ;done'
where test.py is:
import os, select, pty
(pid, pty_fd) = pty.fork()
if pid == 0:
os.write(1, 'This string should be received by parent')
else:
poller = select.epoll()
poller.register( pty_fd, select.EPOLLIN )
ready = poller.poll( 1 * 1000 )
for fd, events in ready:
if not events & select.EPOLLIN:
print 'missed POLLIN event'
else:
print os.read(fd, 100)
poller.close()
The string from the slave is missed several times.
This patch takes the same approach as the fix for read and special cases
this condition for poll.
Tested on 3.16.
Signed-off-by: Francesco Ruggeri <fruggeri@arista.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
|
|
commit feb5814254094c306429fe6d7b9c534fa0250f4c upstream.
This Multi-IO card has one serial 16550-like and one parallel port connector.
Here's the lspci output, after this commit is applied:
03:07.0 Serial controller: Device 4348:5053 (rev 10) (prog-if 02 [16550])
Subsystem: Device 4348:5053
Control: I/O+ Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Interrupt: pin A routed to IRQ 21
Region 0: I/O ports at cf00 [size=8]
Region 1: I/O ports at ce00 [size=8]
Kernel driver in use: parport_serial
Kernel modules: 8250_pci, parport_serial
This commit adds an entry with the device ID to the blacklist declared in
8250_pci to prevent the driver from taking ownership. Also, and as was done
for the 2S/1P variant, add a quirk to skip autodetection and set the correct
type to 16550A clone.
Proper entries are added to parport_serial, to support the device parallel
and serial ports.
Cc: Gianluca Anzolin <gianluca@sottospazio.it>
Cc: Alan Cox <alan@linux.intel.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
|
|
commit 37b164578826406a173ca7c20d9ba7430134d23e upstream.
Kernel oops can cause the tty to be unreleaseable (for example, if
n_tty_read() crashes while on the read_wait queue). This will cause
tty_release() to endlessly loop without sleeping.
Use a killable sleep timeout which grows by 2n+1 jiffies over the interval
[0, 120 secs.) and then jumps to forever (but still killable).
NB: killable just allows for the task to be rewoken manually, not
to be terminated.
Signed-off-by: Peter Hurley <peter@hurleysoftware.com>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
|
|
commit 547039ec502076e60034eeb79611df3433a99b7d upstream.
uart_get_baud_rate() will return baud == 0 if the max rate is set
to the "magic" 38400 rate and the SPD_* flags are also specified.
On the first iteration, if the current baud rate is higher than the
max, the baud rate is clamped at the max (which in the degenerate
case is 38400). On the second iteration, the now-"magic" 38400 baud
rate selects the possibly higher alternate baud rate indicated by
the SPD_* flag. Since only two loop iterations are performed, the
loop is exited, a kernel WARNING is generated and a baud rate of
0 is returned.
Reproducible with:
setserial /dev/ttyS0 spd_hi base_baud 38400
Only perform the "magic" 38400 -> SPD_* baud transform on the first
loop iteration, which prevents the degenerate case from recognizing
the clamped baud rate as the "magic" 38400 value.
Reported-by: Robert Święcki <robert@swiecki.net>
Signed-off-by: Peter Hurley <peter@hurleysoftware.com>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
|
|
commit dc3187564e61260f49eceb21a4e7eb5e4428e90a upstream.
If the chosen baud rate is large enough (e.g. 3.5 megabaud), the
calculated n values in serial_omap_is_baud_mode16() may become 0. This
causes a division by zero when calculating the difference between
calculated and desired baud rates. To prevent this, cap the n13 and n16
values on 1.
Division by zero in kernel.
[<c00132e0>] (unwind_backtrace) from [<c00112ec>] (show_stack+0x10/0x14)
[<c00112ec>] (show_stack) from [<c01ed7bc>] (Ldiv0+0x8/0x10)
[<c01ed7bc>] (Ldiv0) from [<c023805c>] (serial_omap_baud_is_mode16+0x4c/0x68)
[<c023805c>] (serial_omap_baud_is_mode16) from [<c02396b4>] (serial_omap_set_termios+0x90/0x8d8)
[<c02396b4>] (serial_omap_set_termios) from [<c0230a0c>] (uart_change_speed+0xa4/0xa8)
[<c0230a0c>] (uart_change_speed) from [<c0231798>] (uart_set_termios+0xa0/0x1fc)
[<c0231798>] (uart_set_termios) from [<c022bb44>] (tty_set_termios+0x248/0x2c0)
[<c022bb44>] (tty_set_termios) from [<c022c17c>] (set_termios+0x248/0x29c)
[<c022c17c>] (set_termios) from [<c022c3e4>] (tty_mode_ioctl+0x1c8/0x4e8)
[<c022c3e4>] (tty_mode_ioctl) from [<c0227e70>] (tty_ioctl+0xa94/0xb18)
[<c0227e70>] (tty_ioctl) from [<c00cf45c>] (do_vfs_ioctl+0x4a0/0x560)
[<c00cf45c>] (do_vfs_ioctl) from [<c00cf568>] (SyS_ioctl+0x4c/0x74)
[<c00cf568>] (SyS_ioctl) from [<c000e480>] (ret_fast_syscall+0x0/0x30)
Signed-off-by: Frans Klaver <frans.klaver@xsens.com>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
|
|
commit 1ede7dcca3c4fa15a518ab0473126f9c3e621e4c upstream.
Quark X1000 contains two designware derived 8250 serial ports.
Each port has a unique PCI configuration space consisting of
BAR0:UART BAR1:DMA respectively.
Unlike the standard 8250 the register width is 32 bits for RHR,IER etc
The Quark UART has a fundamental clock @ 44.2368 MHz allowing for a
bitrate of up to about 2.76 megabits per second.
This patch enables standard 8250 mode
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
|
|
commit d4089a332883ad969700aac5dd4dd5f1c4fee825 upstream.
Using dma_mapping_error() to make sure the mapping did not
fail.
Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Cc: "Petallo, MauriceX R" <mauricex.r.petallo@intel.com>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
|
|
commit ae84db9661cafc63d179e1d985a2c5b841ff0ac4 upstream.
When a tty is opened for the serial console, the termios c_cflag
settings are inherited from the console line settings.
However, if the tty is subsequently closed, the termios settings
are lost. This results in a garbled console if the console is later
suspended and resumed.
Preserve the termios c_cflag for the serial console when the tty
is shutdown; this reflects the most recent line settings.
Fixes: Bugzilla #69751, 'serial console does not wake from S3'
Reported-by: Valerio Vanni <valerio.vanni@inwind.it>
Acked-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Peter Hurley <peter@hurleysoftware.com>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
|
|
[ Upstream commit fe418231b195c205701c0cc550a03f6c9758fd9e ]
Fix detection of BREAK on sunsab serial console: BREAK detection was only
performed when there were also serial characters received simultaneously.
To handle all BREAKs correctly, the check for BREAK and the corresponding
call to uart_handle_break() must also be done if count == 0, therefore
duplicate this code fragment and pull it out of the loop over the received
characters.
Patch applies to 3.16-rc6.
Signed-off-by: Christopher Alexander Tobias Schulze <cat.schulze@alice-dsl.net>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
|
|
commit 58eb97c99da6a82c556ddec70683eb3863d4f617 upstream.
After 07d410e0) serial: sirf: fix spinlock deadlock issue it is no longer
possiblet to compile this driver. The rename of one of the spinlocks is
faulty. After looking at the original patch I believe this is the correct
fix.
Compile tested using ARM's multi_v7_defconfig
Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Cc: Jiri Slaby <jslaby@suse.cz>
Cc: Qipan Li <Qipan.Li@csr.com>
Signed-off-by: Daniel Thompson <daniel.thompson@linaro.org>
Acked-by: Barry Song <baohua@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
|
|
commit 07d410e06463f3c1c106e2bb2a7ff23eff1e71c9 upstream.
commit fb78b811422cd2d8c8605949cc4cc13618347ad5 provide a workaround for
kernel panic, but bring potential deadlock risk. that is in
sirfsoc_rx_tmo_process_tl while enter into sirfsoc_uart_pio_rx_chars
cpu hold uart_port->lock, if uart interrupt comes cpu enter into
sirfsoc_uart_isr and deadlock occurs in getting uart_port->lock.
the patch replace spin_lock version to spin_lock_irq* version to avoid
spinlock dead lock issue. let function tty_flip_buffer_push in tasklet
outof spin_lock_irq* protect area to avoid add the pair of spin_lock and
spin_unlock for tty_flip_buffer_push.
BTW drop self defined unused spinlock protect of tx_lock/rx_lock.
56274.220464] BUG: spinlock lockup suspected on CPU#0, swapper/0/0
[56274.223648] lock: 0xc05d9db0, .magic: dead4ead, .owner: swapper/0/0,
.owner_cpu: 0
[56274.231278] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G
O 3.10.35 #1
[56274.238241] [<c0015530>] (unwind_backtrace+0x0/0xf4) from
[<c00120d8>] (show_stack+0x10/0x14)
[56274.246742] [<c00120d8>] (show_stack+0x10/0x14) from
[<c01b11b0>] (do_raw_spin_lock+0x110/0x184)
[56274.255501] [<c01b11b0>] (do_raw_spin_lock+0x110/0x184) from
[<c02124c8>] (sirfsoc_uart_isr+0x20/0x42c)
[56274.264874] [<c02124c8>] (sirfsoc_uart_isr+0x20/0x42c) from
[<c0075790>] (handle_irq_event_percpu+0x54/0x17c)
[56274.274758] [<c0075790>] (handle_irq_event_percpu+0x54/0x17c)
from [<c00758f4>] (handle_irq_event+0x3c/0x5c)
[56274.284561] [<c00758f4>] (handle_irq_event+0x3c/0x5c) from
[<c0077fa0>] (handle_level_irq+0x98/0xfc)
[56274.293670] [<c0077fa0>] (handle_level_irq+0x98/0xfc) from
[<c0074f44>] (generic_handle_irq+0x2c/0x3c)
[56274.302952] [<c0074f44>] (generic_handle_irq+0x2c/0x3c) from
[<c000ef80>] (handle_IRQ+0x40/0x90)
[56274.311706] [<c000ef80>] (handle_IRQ+0x40/0x90) from
[<c000dc80>] (__irq_svc+0x40/0x70)
[56274.319697] [<c000dc80>] (__irq_svc+0x40/0x70) from
[<c038113c>] (_raw_spin_unlock_irqrestore+0x10/0x48)
[56274.329158] [<c038113c>]
(_raw_spin_unlock_irqrestore+0x10/0x48) from [<c0200034>]
(tty_port_tty_get+0x58/0x90)
[56274.339213] [<c0200034>] (tty_port_tty_get+0x58/0x90) from
[<c0212008>] (sirfsoc_uart_pio_rx_chars+0x1c/0xc8)
[56274.349097] [<c0212008>]
(sirfsoc_uart_pio_rx_chars+0x1c/0xc8) from [<c0212ef8>]
(sirfsoc_rx_tmo_process_tl+0xe4/0x1fc)
[56274.359853] [<c0212ef8>]
(sirfsoc_rx_tmo_process_tl+0xe4/0x1fc) from [<c0027c04>]
(tasklet_action+0x84/0x114)
[56274.369739] [<c0027c04>] (tasklet_action+0x84/0x114) from
[<c0027db4>] (__do_softirq+0x120/0x200)
[56274.378585] [<c0027db4>] (__do_softirq+0x120/0x200) from
[<c0027f44>] (do_softirq+0x54/0x5c)
[56274.386998] [<c0027f44>] (do_softirq+0x54/0x5c) from
[<c00281ec>] (irq_exit+0x9c/0xd0)
[56274.394899] [<c00281ec>] (irq_exit+0x9c/0xd0) from
[<c000ef84>] (handle_IRQ+0x44/0x90)
[56274.402790] [<c000ef84>] (handle_IRQ+0x44/0x90) from
[<c000dc80>] (__irq_svc+0x40/0x70)
[56274.410774] [<c000dc80>] (__irq_svc+0x40/0x70) from
[<c0288af4>] (cpuidle_enter_state+0x50/0xe0)
[56274.419532] [<c0288af4>] (cpuidle_enter_state+0x50/0xe0) from
[<c0288c34>] (cpuidle_idle_call+0xb0/0x148)
[56274.429080] [<c0288c34>] (cpuidle_idle_call+0xb0/0x148) from
[<c000f3ac>] (arch_cpu_idle+0x8/0x38)
[56274.438016] [<c000f3ac>] (arch_cpu_idle+0x8/0x38) from
[<c0059344>] (cpu_startup_entry+0xfc/0x140)
[56274.446956] [<c0059344>] (cpu_startup_entry+0xfc/0x140) from
[<c04a3a54>] (start_kernel+0x2d8/0x2e4)
Signed-off-by: Qipan Li <Qipan.Li@csr.com>
Signed-off-by: Barry Song <Baohua.Song@csr.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
|
|
commit 66528f90669691c85c73bea4f0c9f4a5857c4cab upstream.
If INPCK is not set, input parity detection should be disabled. This means
parity errors should not be received from the tty driver, and the data
received should be treated normally.
SUS v3, 11.2.2, General Terminal Interface - Input Modes, states:
"If INPCK is set, input parity checking shall be enabled. If INPCK is
not set, input parity checking shall be disabled, allowing output parity
generation without input parity errors. Note that whether input parity
checking is enabled or disabled is independent of whether parity detection
is enabled or disabled (see Control Modes). If parity detection is enabled
but input parity checking is disabled, the hardware to which the terminal
is connected shall recognize the parity bit, but the terminal special file
shall not check whether or not this bit is correctly set."
Ignore parity errors reported by the tty driver when INPCK is not set, and
handle the received data normally.
Fixes: Bugzilla #71681, 'Improvement of n_tty_receive_parity_error from n_tty.c'
Reported-by: Ivan <athlon_@mail.ru>
Signed-off-by: Peter Hurley <peter@hurleysoftware.com>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
|
|
commit ef8b9ddcb45fa3b1e11acd72be2398001e807d14 upstream.
If IGNBRK is set without either BRKINT or PARMRK set, some uart
drivers send a 0x00 byte for BREAK without the TTYBREAK flag to the
line discipline, when it should send either nothing or the TTYBREAK flag
set. This happens because the read_status_mask masks out the BI
condition, which uart_insert_char() then interprets as a normal 0x00 byte.
SUS v3 is clear regarding the meaning of IGNBRK; Section 11.2.2, General
Terminal Interface - Input Modes, states:
"If IGNBRK is set, a break condition detected on input shall be ignored;
that is, not put on the input queue and therefore not read by any
process."
Fix read_status_mask to include the BI bit if IGNBRK is set; the
lsr status retains the BI bit if a BREAK is recv'd, which is
subsequently ignored in uart_insert_char() when masked with the
ignore_status_mask.
Affected drivers:
8250 - all
serial_txx9
mfd
amba-pl010
amba-pl011
atmel_serial
bfin_uart
dz
ip22zilog
max310x
mxs-auart
netx-serial
pnx8xxx_uart
pxa
sb1250-duart
sccnxp
serial_ks8695
sirfsoc_uart
st-asc
vr41xx_siu
zs
sunzilog
fsl_lpuart
sunsab
ucc_uart
bcm63xx_uart
sunsu
efm32-uart
pmac_zilog
mpsc
msm_serial
m32r_sio
Unaffected drivers:
omap-serial
rp2
sa1100
imx
icom
Annotated for fixes:
altera_uart
mcf
Drivers without break detection:
21285
xilinx-uartps
altera_jtaguart
apbuart
arc-uart
clps711x
max3100
uartlite
msm_serial_hs
nwpserial
lantiq
vt8500_serial
Unknown:
samsung
mpc52xx_uart
bfin_sport_uart
cpm_uart/core
Fixes: Bugzilla #71651, '8250_core.c incorrectly handles IGNBRK flag'
Reported-by: Ivan <athlon_@mail.ru>
Signed-off-by: Peter Hurley <peter@hurleysoftware.com>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
|
|
commit 6979f8d28049879e6147767d93ba6732c8bd94f4 upstream.
Commit c49436b657d0 (serial: 8250_dw: Improve unwritable LCR workaround)
caused a regression. It added a check that the LCR was written properly
to detect and workaround the busy quirk, but the behaviour of bit 5
(UART_LCR_SPAR) differs between IP versions 3.00a and 3.14c per the
docs. On older versions this caused the check to fail and it would
repeatedly force idle and rewrite the LCR register, causing delays and
preventing any input from serial being received.
This is fixed by masking out UART_LCR_SPAR before making the comparison.
Signed-off-by: James Hogan <james.hogan@imgtec.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Jiri Slaby <jslaby@suse.cz>
Cc: Tim Kryger <tim.kryger@linaro.org>
Cc: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
Cc: Matt Porter <matt.porter@linaro.org>
Cc: Markus Mayer <markus.mayer@linaro.org>
Tested-by: Tim Kryger <tim.kryger@linaro.org>
Tested-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
Tested-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
|
|
commit c49436b657d0a56a6ad90d14a7c3041add7cf64d upstream.
When configured with UART_16550_COMPATIBLE=NO or in versions prior to
the introduction of this option, the Designware UART will ignore writes
to the LCR if the UART is busy. The current workaround saves a copy of
the last written LCR and re-writes it in the ISR for a special interrupt
that is raised when a write was ignored.
Unfortunately, interrupts are typically disabled prior to performing a
sequence of register writes that include the LCR so the point at which
the retry occurs is too late. An example is serial8250_do_set_termios()
where an ignored LCR write results in the baud divisor not being set and
instead a garbage character is sent out the transmitter.
Furthermore, since serial_port_out() offers no way to indicate failure,
a serious effort must be made to ensure that the LCR is actually updated
before returning back to the caller. This is difficult, however, as a
UART that was busy during the first attempt is likely to still be busy
when a subsequent attempt is made unless some extra action is taken.
This updated workaround reads back the LCR after each write to confirm
that the new value was accepted by the hardware. Should the hardware
ignore a write, the TX/RX FIFOs are cleared and the receive buffer read
before attempting to rewrite the LCR out of the hope that doing so will
force the UART into an idle state. While this may seem unnecessarily
aggressive, writes to the LCR are used to change the baud rate, parity,
stop bit, or data length so the data that may be lost is likely not
important. Admittedly, this is far from ideal but it seems to be the
best that can be done given the hardware limitations.
Lastly, the revised workaround doesn't touch the LCR in the ISR, so it
avoids the possibility of a "serial8250: too much work for irq" lock up.
This problem is rare in real situations but can be reproduced easily by
wiring up two UARTs and running the following commands.
# stty -F /dev/ttyS1 echo
# stty -F /dev/ttyS2 echo
# cat /dev/ttyS1 &
[1] 375
# echo asdf > /dev/ttyS1
asdf
[ 27.700000] serial8250: too much work for irq96
[ 27.700000] serial8250: too much work for irq96
[ 27.710000] serial8250: too much work for irq96
[ 27.710000] serial8250: too much work for irq96
[ 27.720000] serial8250: too much work for irq96
[ 27.720000] serial8250: too much work for irq96
[ 27.730000] serial8250: too much work for irq96
[ 27.730000] serial8250: too much work for irq96
[ 27.740000] serial8250: too much work for irq96
Signed-off-by: Tim Kryger <tim.kryger@linaro.org>
Reviewed-by: Matt Porter <matt.porter@linaro.org>
Reviewed-by: Markus Mayer <markus.mayer@linaro.org>
Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Conflicts:
drivers/tty/serial/8250/8250_dw.c
|
|
commit 28a821c306889b9f2c3fff49abedc9b2c743eb73 upstream.
This function is largely a duplicate of paste_selection() in
drivers/tty/vt/selection.c, but with its own selection state. The
speakup selection mechanism should really be merged with vt.
For now, apply the changes from 'TTY: vt, fix paste_selection ldisc
handling', 'tty: Make ldisc input flow control concurrency-friendly',
and 'tty: Fix unsafe vt paste_selection()'.
References: https://bugs.debian.org/735202
References: https://bugs.debian.org/744015
Reported-by: Paul Gevers <elbrus@debian.org>
Reported-and-tested-by: Jarek Czekalski <jarekczek@poczta.onet.pl>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
|
