summaryrefslogtreecommitdiff
path: root/drivers/tty
AgeCommit message (Collapse)Author
2014-12-11serial: fsl-lpuart: add lpuart32 Power Management supportJingchang Lu
This adds 32-bit register lpuart32 power management support, this also updates the 8-bit register lpuart resume function. Signed-off-by: Jingchang Lu <jingchang.lu@freescale.com> --- This patch has been sent upstream for review: https://patchwork.kernel.org/patch/5145341/ Change-Id: I0ed49f80d48407394cb0788f422374236da171b1 Reviewed-on: http://git.am.freescale.net:8181/21931 Tested-by: Review Code-CDREVIEW <CDREVIEW@freescale.com> Reviewed-by: Zhengxiong Jin <Jason.Jin@freescale.com>
2014-12-11tty: of-serial: fixup info uninitialized bugJingchang Lu
The kmalloc space may cause info->clk have random value if the dts node doesn't define clk property, thus cause all if(info->clk) condition wrong. Signed-off-by: Jingchang Lu <jingchang.lu@freescale.com> Change-Id: I309ff5cc881e00dc4475649e050263243027326c Reviewed-on: http://git.am.freescale.net:8181/21934 Tested-by: Review Code-CDREVIEW <CDREVIEW@freescale.com> Reviewed-by: Zhengxiong Jin <Jason.Jin@freescale.com>
2014-12-11qe-uart: modify qe-uart to adapt both powerpc and armZhao Qiang
qe has been supported by arm board ls1021, qe-uart need to be supported by ls1021. modify the code to make qe-uart can work on both powerpc and ls1021. Signed-off-by: Zhao Qiang <B45475@freescale.com> --- upstream link: http://patchwork.ozlabs.org/patch/398471/ it is under discussion. Change-Id: I07a9a091882cd572330b38e7a6e0632aea9a9042 Reviewed-on: http://git.am.freescale.net:8181/21119 Tested-by: Review Code-CDREVIEW <CDREVIEW@freescale.com> Reviewed-by: Xiaobo Xie <X.Xie@freescale.com> Reviewed-by: Zhengxiong Jin <Jason.Jin@freescale.com>
2014-12-11qe: move qe from arch/powerpc/sysdev/ to drivers/soc/Zhao Qiang
ls1 has qe ip block too, so move qe code from platform directory to public directory. Signed-off-by: Zhao Qiang <B45475@freescale.com> --- patch on upstream can be found with this link: http://patchwork.ozlabs.org/patch/385724/, it is under discussion Change-Id: I39aed531a4792990e3bb8ecc6f4e57f8d9b41bae Reviewed-on: http://git.am.freescale.net:8181/15818 Tested-by: Review Code-CDREVIEW <CDREVIEW@freescale.com> Reviewed-by: Xiaobo Xie <X.Xie@freescale.com> Reviewed-by: Zhengxiong Jin <Jason.Jin@freescale.com>
2014-12-11serial: of-serial: add PM suspend/resume supportJingchang Lu
This adds PM suspend/resume support for the of-serial driver to provide power management support on devices attatched to it. Signed-off-by: Jingchang Lu <jingchang.lu@freescale.com> This patch has been sent to upstream for review: https://patchwork.kernel.org/patch/4954521/ Change-Id: I06905237f7d7ef51bf5a1c135cd0880d92c4c104 Reviewed-on: http://git.am.freescale.net:8181/19728 Tested-by: Review Code-CDREVIEW <CDREVIEW@freescale.com> Reviewed-by: Chenhui Zhao <chenhui.zhao@freescale.com> Reviewed-by: Li Xiubo <Li.Xiubo@freescale.com> Reviewed-by: Zhengxiong Jin <Jason.Jin@freescale.com>
2014-12-11tty: of_serial: add of support for Freescale 64-byte FIFO UARTJingchang Lu
Signed-off-by: Jingchang Lu <jingchang.lu@freescale.com> Change-Id: I667cb31ce4b5e8f5c2a4c5f2b88e677eb991b9b3 Reviewed-on: http://git.am.freescale.net:8181/17834 Tested-by: Review Code-CDREVIEW <CDREVIEW@freescale.com> Reviewed-by: Huan Wang <alison.wang@freescale.com> Reviewed-by: Li Xiubo <Li.Xiubo@freescale.com> Reviewed-by: Zhengxiong Jin <Jason.Jin@freescale.com>
2014-12-11tty: serial: fsl_lpuart: add 32-bit register interface supportJingchang Lu
This add the big-endian 32-bit register version LPUART support. Signed-off-by: Jingchang Lu <jingchang.lu@freescale.com> --- This patch has been sent to upstream: https://patchwork.kernel.org/patch/4544291/
2014-05-22n_tty: Fix n_tty_write crash when echoing in raw modePeter Hurley
The tty atomic_write_lock does not provide an exclusion guarantee for the tty driver if the termios settings are LECHO & !OPOST. And since it is unexpected and not allowed to call TTY buffer helpers like tty_insert_flip_string concurrently, this may lead to crashes when concurrect writers call pty_write. In that case the following two writers: * the ECHOing from a workqueue and * pty_write from the process race and can overflow the corresponding TTY buffer like follows. If we look into tty_insert_flip_string_fixed_flag, there is: int space = __tty_buffer_request_room(port, goal, flags); struct tty_buffer *tb = port->buf.tail; ... memcpy(char_buf_ptr(tb, tb->used), chars, space); ... tb->used += space; so the race of the two can result in something like this: A B __tty_buffer_request_room __tty_buffer_request_room memcpy(buf(tb->used), ...) tb->used += space; memcpy(buf(tb->used), ...) ->BOOM B's memcpy is past the tty_buffer due to the previous A's tb->used increment. Since the N_TTY line discipline input processing can output concurrently with a tty write, obtain the N_TTY ldisc output_lock to serialize echo output with normal tty writes. This ensures the tty buffer helper tty_insert_flip_string is not called concurrently and everything is fine. Note that this is nicely reproducible by an ordinary user using forkpty and some setup around that (raw termios + ECHO). And it is present in kernels at least after commit d945cb9cce20ac7143c2de8d88b187f62db99bdc (pty: Rework the pty layer to use the normal buffering logic) in 2.6.31-rc3. js: add more info to the commit log js: switch to bool js: lock unconditionally js: lock only the tty->ops->write call References: CVE-2014-0196 Reported-and-tested-by: Jiri Slaby <jslaby@suse.cz> Signed-off-by: Peter Hurley <peter@hurleysoftware.com> Signed-off-by: Jiri Slaby <jslaby@suse.cz> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Alan Cox <alan@lxorguk.ukuu.org.uk> Cc: <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> (cherry picked from commit 4291086b1f081b869c6d79e5b7441633dc3ace00) Signed-off-by: Scott Wood <scottwood@freescale.com> Change-Id: Ia026d31182516be7ff8e70017422a3522cfeb425 Reviewed-on: http://git.am.freescale.net:8181/12529 Tested-by: Review Code-CDREVIEW <CDREVIEW@freescale.com> Reviewed-by: Yusong Sun <yorksun@freescale.com> Reviewed-by: Jose Rivera <German.Rivera@freescale.com>
2014-05-14Merge remote-tracking branch 'stable/linux-3.12.y' into sdk-v1.6.xScott Wood
Signed-off-by: Scott Wood <scottwood@freescale.com> Conflicts: arch/sparc/Kconfig drivers/tty/tty_buffer.c
2014-05-05tty: Fix low_latency BUGPeter Hurley
commit a9c3f68f3cd8d55f809fbdb0c138ed061ea1bd25 upstream. The user-settable knob, low_latency, has been the source of several BUG reports which stem from flush_to_ldisc() running in interrupt context. Since 3.12, which added several sleeping locks (termios_rwsem and buf->lock) to the input processing path, the frequency of these BUG reports has increased. Note that changes in 3.12 did not introduce this regression; sleeping locks were first added to the input processing path with the removal of the BKL from N_TTY in commit a88a69c91256418c5907c2f1f8a0ec0a36f9e6cc, 'n_tty: Fix loss of echoed characters and remove bkl from n_tty' and later in commit 38db89799bdf11625a831c5af33938dcb11908b6, 'tty: throttling race fix'. Since those changes, executing flush_to_ldisc() in interrupt_context (ie, low_latency set), is unsafe. However, since most devices do not validate if the low_latency setting is appropriate for the context (process or interrupt) in which they receive data, some reports are due to misconfiguration. Further, serial dma devices for which dma fails, resort to interrupt receiving as a backup without resetting low_latency. Historically, low_latency was used to force wake-up the reading process rather than wait for the next scheduler tick. The effect was to trim multiple milliseconds of latency from when the process would receive new data. Recent tests [1] have shown that the reading process now receives data with only 10's of microseconds latency without low_latency set. Remove the low_latency rx steering from tty_flip_buffer_push(); however, leave the knob as an optional hint to drivers that can tune their rx fifos and such like. Cleanup stale code comments regarding low_latency. [1] https://lkml.org/lkml/2014/2/20/434 "Yay.. thats an annoying historical pain in the butt gone." -- Alan Cox Reported-by: Beat Bolli <bbolli@ewanet.ch> Reported-by: Pavel Roskin <proski@gnu.org> Acked-by: David Sterba <dsterba@suse.cz> Cc: Grant Edwards <grant.b.edwards@gmail.com> Cc: Stanislaw Gruszka <sgruszka@redhat.com> Cc: Hal Murray <murray+fedora@ip-64-139-1-69.sjc.megapath.net> Signed-off-by: Peter Hurley <peter@hurleysoftware.com> Signed-off-by: Alan Cox <alan@linux.intel.com> Signed-off-by: Jiri Slaby <jslaby@suse.cz>
2014-05-05tty: Set correct tty name in 'active' sysfs attributeHannes Reinecke
commit 723abd87f6e536f1353c8f64f621520bc29523a3 upstream. The 'active' sysfs attribute should refer to the currently active tty devices the console is running on, not the currently active console. The console structure doesn't refer to any device in sysfs, only the tty the console is running on has. So we need to print out the tty names in 'active', not the console names. There is one special-case, which is tty0. If the console is directed to it, we want 'tty0' to show up in the file, so user-space knows that the messages get forwarded to the active VT. The ->device() callback would resolve tty0, though. Hence, treat it special and don't call into the VT layer to resolve it (plymouth is known to depend on it). Cc: Lennart Poettering <lennart@poettering.net> Cc: Kay Sievers <kay@vrfy.org> Cc: Jiri Slaby <jslaby@suse.cz> Signed-off-by: Werner Fink <werner@suse.de> Signed-off-by: Hannes Reinecke <hare@suse.de> Signed-off-by: David Herrmann <dh.herrmann@gmail.com> Signed-off-by: Jiri Slaby <jslaby@suse.cz>
2014-04-10Merge branch 'rtmerge' into sdk-v1.6.xScott Wood
This merges 3.12.15-rt25. Signed-off-by: Scott Wood <scottwood@freescale.com> Conflicts: drivers/misc/Makefile drivers/net/ethernet/freescale/gianfar.c drivers/net/ethernet/freescale/gianfar_ethtool.c drivers/net/ethernet/freescale/gianfar_sysfs.c
2014-04-10kgdb/serial: Short term workaroundJason Wessel
On 07/27/2011 04:37 PM, Thomas Gleixner wrote: > - KGDB (not yet disabled) is reportedly unusable on -rt right now due > to missing hacks in the console locking which I dropped on purpose. > To work around this in the short term you can use this patch, in addition to the clocksource watchdog patch that Thomas brewed up. Comments are welcome of course. Ultimately the right solution is to change separation between the console and the HW to have a polled mode + work queue so as not to introduce any kind of latency. Thanks, Jason.
2014-04-10rt: Improve the serial console PASS_LIMITIngo Molnar
Beyond the warning: drivers/tty/serial/8250/8250.c:1613:6: warning: unused variable ‘pass_counter’ [-Wunused-variable] the solution of just looping infinitely was ugly - up it to 1 million to give it a chance to continue in some really ugly situation. Signed-off-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2014-04-10drivers-tty-pl011-irq-disable-madness.patchThomas Gleixner
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2014-04-10drivers-tty-fix-omap-lock-crap.patchThomas Gleixner
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2014-04-10serial: 8250: Call flush_to_ldisc when the irq is threadedIngo Molnar
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2014-04-10sparc: serial: Clean up the locking for -rtDavid Miller
Signed-off-by: David S. Miller <davem@davemloft.net> Tested-by: Allen Pais <allen.pais@oracle.com>
2014-04-10serial: 8250: Clean up the locking for -rtIngo Molnar
In -RT the spin_lock_irqsave() does not spin but sleep if the lock is taken. Before that, local_irq_save() is invoked which disables interrupts even on -RT. Therefore local_irq_save() + spin_lock() does not work. In the ->sysrq and oops_in_progress case it is save to trylock the lock i.e. this is what we do now anyway except for ->sysrq where we assume that the lock is already taken. The spin_lock_irqsave() grabs the lock and disables the interrupts on vanilla (the same behavior) and on -RT it won't disable interrupts. Signed-off-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> [bigeasy: add a patch description] Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
2014-04-08Merge remote-tracking branch 'stable/linux-3.12.y' into sdk-v1.6.xScott Wood
Signed-off-by: Scott Wood <scottwood@freescale.com> Conflicts: drivers/mmc/card/block.c
2014-04-08Merge branch 'merge' into sdk-v1.6.xScott Wood
This reverts v3.13-rc3+ (78fd82238d0e5716) to v3.12, except for commits which I noticed which appear relevant to the SDK. Signed-off-by: Scott Wood <scottwood@freescale.com> Conflicts: arch/powerpc/include/asm/kvm_host.h arch/powerpc/kvm/book3s_hv_rmhandlers.S arch/powerpc/kvm/book3s_interrupts.S arch/powerpc/kvm/e500.c arch/powerpc/kvm/e500mc.c arch/powerpc/sysdev/fsl_soc.h drivers/Kconfig drivers/cpufreq/ppc-corenet-cpufreq.c drivers/dma/fsldma.c drivers/dma/s3c24xx-dma.c drivers/misc/Makefile drivers/mmc/host/sdhci-of-esdhc.c drivers/mtd/devices/m25p80.c drivers/net/ethernet/freescale/gianfar.h drivers/platform/Kconfig drivers/platform/Makefile drivers/spi/spi-fsl-espi.c include/crypto/algapi.h include/linux/netdev_features.h include/linux/skbuff.h include/net/ip.h net/core/ethtool.c
2014-04-07Rewind v3.13-rc3+ (78fd82238d0e5716) to v3.12Scott Wood
2014-03-25Add 64byte FiFo mode UART support for FSL platformsPriyanka Jain
T1040 FSL SoC has new version of UART controller which can support 64byte FiFo. Add suuport to enable 64byte FiFO mode -FCR[EN64] needs to be programmed to 1 to enable it. -Also, when FCR[EN64]==1, RTL bits to be used as below to define various Receive Trigger Levels: -FCR[RTL] = 00 1 byte -FCR[RTL] = 01 16 bytes -FCR[RTL] = 10 32 bytes -FCR[RTL] = 11 56 bytes -tx_loadsz is set tp 32bytes, As some issues are observed with 64-byte mode which looks to be Si issue. Signed-off-by: Priyanka Jain <Priyanka.Jain@freescale.com> Signed-off-by: Poonam Aggrwal <poonam.aggrwal@freescale.com> Signed-off-by: Prabhakar Kushwaha <prabhakar@freescale.com> Change-Id: I0b32f3230bd1c9674a2e85cc4e5a16869dbaa9af Reviewed-on: http://git.am.freescale.net:8181/10215 Tested-by: Review Code-CDREVIEW <CDREVIEW@freescale.com> Reviewed-by: Jose Rivera <German.Rivera@freescale.com>
2014-02-22vt: Fix secure clear screenPetr Písař
commit 0930b0950a8996aa88b0d2ba4bb2bab27cc36bc7 upstream. \E[3J console code (secure clear screen) needs to update_screen(vc) in order to write-through blanks into off-screen video memory. This has been removed accidentally in 3.6 by: commit 81732c3b2fede049a692e58a7ceabb6d18ffb18c Author: Jean-François Moine <moinejf@free.fr> Date: Thu Sep 6 19:24:13 2012 +0200 tty vt: Fix line garbage in virtual console on command line edition Signed-off-by: Petr Písař <petr.pisar@atlas.cz> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-02-22tty: n_gsm: Fix for modems with brk in modem status controlLars Poeschel
commit 3ac06b905655b3ef2fd2196bab36e4587e1e4e4f upstream. 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> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-02-22serial: sirf: fix kernel panic caused by unpaired spinlockQipan Li
commit fb78b811422cd2d8c8605949cc4cc13618347ad5 upstream. commit 8b9ade9f74f8a279 coming from Viresh Kumar "tty: serial: sirfsoc: drop uart_port->lock before calling tty_flip_buffer_push()" broke sirfsoc uart driver by knic: [ 5.129122] BUG: spinlock already unlocked on CPU#0, ip6tables/1331 [ 5.132554] lock: sirfsoc_uart_ports+0x4/0x8a0, .magic: dead4ead, .owner: <none>/-1, .owner_cpu: -1 [ 5.141651] CPU: 0 PID: 1331 Comm: ip6tables Tainted: G W O 3.10.16 #3 [ 5.148866] [<c0013528>] (unwind_backtrace+0x0/0xe0) from [<c0010e70>] (show_stack+0x10/0x14) [ 5.157362] [<c0010e70>] (show_stack+0x10/0x14) from [<c01a5e68>] (do_raw_spin_unlock+0x40/0xc8) [ 5.166125] [<c01a5e68>] (do_raw_spin_unlock+0x40/0xc8) from [<c03ff8b4>] (_raw_spin_unlock+0x8/0x40) [ 5.175322] [<c03ff8b4>] (_raw_spin_unlock+0x8/0x40) from [<c0203fcc>] (sirfsoc_uart_pio_rx_chars+0xa4/0xc0) [ 5.185120] [<c0203fcc>] (sirfsoc_uart_pio_rx_chars+0xa4/0xc0) from [<c0204fb8>] (sirfsoc_rx_tmo_process_tl+0xdc/0x1e0) [ 5.195875] [<c0204fb8>] (sirfsoc_rx_tmo_process_tl+0xdc/0x1e0) from [<c0024b50>] (tasklet_action+0x8c/0xec) [ 5.205673] [<c0024b50>] (tasklet_action+0x8c/0xec) from [<c00242a8>] (__do_softirq+0xec/0x1d4) [ 5.214347] [<c00242a8>] (__do_softirq+0xec/0x1d4) from [<c0024428>] (do_softirq+0x48/0x54) [ 5.222674] [<c0024428>] (do_softirq+0x48/0x54) from [<c0024690>] (irq_exit+0x74/0xc0) [ 5.230573] [<c0024690>] (irq_exit+0x74/0xc0) from [<c000e1e8>] (handle_IRQ+0x6c/0x90) [ 5.238465] [<c000e1e8>] (handle_IRQ+0x6c/0x90) from [<c000d500>] (__irq_svc+0x40/0x70) [ 5.246446] [<c000d500>] (__irq_svc+0x40/0x70) from [<c0092e7c>] (mark_page_accessed+0xc/0x68) [ 5.255034] [<c0092e7c>] (mark_page_accessed+0xc/0x68) from [<c00a2a4c>] (unmap_single_vma+0x3bc/0x550) [ 5.264402] [<c00a2a4c>] (unmap_single_vma+0x3bc/0x550) from [<c00a3b4c>] (unmap_vmas+0x44/0x54) [ 5.273164] [<c00a3b4c>] (unmap_vmas+0x44/0x54) from [<c00a81a8>] (exit_mmap+0xc4/0x1e0) [ 5.281233] [<c00a81a8>] (exit_mmap+0xc4/0x1e0) from [<c001bb78>] (mmput+0x3c/0xdc) [ 5.288868] [<c001bb78>] (mmput+0x3c/0xdc) from [<c0021b0c>] (do_exit+0x30c/0x828) [ 5.296413] [<c0021b0c>] (do_exit+0x30c/0x828) from [<c0022dac>] (do_group_exit+0x4c/0xb0) [ 5.304653] [<c0022dac>] (do_group_exit+0x4c/0xb0) from [<c0022e20>] (__wake_up_parent+0x0/0x18) Root cause: the commit dropped uart_port->lock before calling tty_flip_buffer_push(), but in sirfsoc-uart, sirfsoc_uart_pio_rx_chars() can be called by sirfsoc_rx_tmo_process_tl(). here uart_port->lock has not been taken yet. so that caused unpaired lock/unlock. Solution: This patch is doing a quick fix for that, it adds spin_lock/unlock(&port->lock) protect to sirfsoc_uart_pio_rx_chars() in sirfsoc_rx_tmo_process_tl() to keep spin_lock/unlock in pair. 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>
2014-02-06serial: 8250: enable UART_BUG_NOMSR for TegraStephen Warren
commit 3685f19e07802ec4207b52465c408f185b66490e upstream. Tegra chips have 4 or 5 identical UART modules embedded. UARTs C..E have their MODEM-control signals tied off to a static state. However UARTs A and B can optionally route those signals to/from package pins, depending on the exact pinmux configuration. When these signals are not routed to package pins, false interrupts may trigger either temporarily, or permanently, all while not showing up in the IIR; it will read as NO_INT. This will eventually lead to the UART IRQ being disabled due to unhandled interrupts. When this happens, the kernel may print e.g.: irq 68: nobody cared (try booting with the "irqpoll" option) In order to prevent this, enable UART_BUG_NOMSR. This prevents UART_IER_MSI from being enabled, which prevents the false interrupts from triggering. In practice, this is not needed under any of the following conditions: * On Tegra chips after Tegra30, since the HW bug has apparently been fixed. * On UARTs C..E since their MODEM control signals are tied to the correct static state which doesn't trigger the issue. * On UARTs A..B if the MODEM control signals are routed out to package pins, since they will then carry valid signals. However, we ignore these exceptions for now, since they are only relevant if a board actually hooks up more than a 4-wire UART, and no currently supported board does this. If we ever support a board that does, we can refine the algorithm that enables UART_BUG_NOMSR to take those exceptions into account, and/or read a flag from DT/... that indicates that the board has hooked up and pinmux'd more than a 4-wire UART. Reported-by: Olof Johansson <olof@lixom.net> # autotester Signed-off-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-02-06serial: 8250: Fix initialisation of Quatech cards with the AMCC PCI chipJonathan Woithe
commit 9c5320f8d7d9a2cf623e65d50e1113f34d9b9eb1 upstream. Fix the initialisation of older Quatech serial cards which are fitted with the AMCC PCI Matchmaker interface chip. Signed-off-by: Jonathan Woithe (jwoithe@just42.net) Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-02-06serial: add support for 200 v3 series Titan cardYegor Yefremov
commit 48c0247d7b7bf58abb85a39021099529df365c4d upstream. Signed-off-by: Yegor Yefremov <yegorslists@googlemail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-02-06tty/serial: at91: disable uart timer at start of shutdownMarek Roszko
commit 8bc661bfc0c2d221e209f4205bdaaf574d50100c upstream. The uart timer will schedule a tasklet when it fires. It is possible that it can fire inside _shutdown before it is killed in the dma and pdc cleanup routines. This causes a tasklet that exists after the port is shutdown, so when the kernel finally executes it, it panics as the tty port is NULL. This is a somewhat rare condition but its possible if a program keeps on opening/closing the port. It has been observed in particular with systemd boot messages that were causing a kernel panic because of this behavior. Moving the timer deletion to the beginning of the function stops a tasklet from being scheduled unexpectedly. Signed-off-by: Marek Roszko <mark.roszko@gmail.com> [nicolas.ferre@atmel.com: modify commit message, call setup_timer() in any case] Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-02-06tty/serial: at91: reset rx_ring when port is shutdownMark Deneen
commit bb7e73c598fb226c75f7625088a8f6a45a0fc892 upstream. When using RX DMA, the driver won't pass any data to the uart layer until the buffer is flipped. When the port is shutdown, the dma buffers are unmapped, but the head and tail of the ring buffer are not reseted. Since the serial console will keep the port open, this will only present itself when the uart is not shared. To reproduce the issue, with an unpatched driver, run a getty on /dev/ttyS0 with no serial console and exit. Getty will exit, and when the new one returns you will be unable to log in. If you hold down a key long enough to fill the DMA buffer and flip it, you can then log in. Signed-off-by: Mark Deneen <mdeneen@gmail.com> Acked-by: Leilei Zhao <leilei.zhao@atmel.com> [nicolas.ferre@atmel.com: adapt to mainline kernel, handle !DMA case] Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-02-06tty/serial: at91: fix race condition in atmel_serial_removeMarek Roszko
commit f50c995f9ebf064cea1368bf361c4e29679415b4 upstream. The _remove callback could be called when a tasklet is scheduled. tasklet_kill was called inside the function in order to free up any scheduled tasklets. However it was called after uart_remove_one_port which destroys tty references needed in the port for atmel_tasklet_func. Simply putting the tasklet_kill at the start of the function will prevent this conflict. Signed-off-by: Marek Roszko <mark.roszko@gmail.com> Acked-by: Leilei Zhao <leilei.zhao@atmel.com> Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-02-06tty/serial: at91: Handle shutdown more safelyMarek Roszko
commit 0cc7c6c7916b1b6f34350ff1473b80b9f7e459c0 upstream. Interrupts were being cleaned up late in the shutdown handler, it is possible that an interrupt can occur and schedule a tasklet that runs after the port is cleaned up. There is a null dereference due to this race condition with the following stacktrace: [<c02092b0>] (atmel_tasklet_func+0x514/0x814) from [<c001fd34>] (tasklet_action+0x70/0xa8) [<c001fd34>] (tasklet_action+0x70/0xa8) from [<c001f60c>] (__do_softirq+0x90/0x144) [<c001f60c>] (__do_softirq+0x90/0x144) from [<c001fa18>] (irq_exit+0x40/0x4c) [<c001fa18>] (irq_exit+0x40/0x4c) from [<c000e298>] (handle_IRQ+0x64/0x84) [<c000e298>] (handle_IRQ+0x64/0x84) from [<c000d6c0>] (__irq_svc+0x40/0x50) [<c000d6c0>] (__irq_svc+0x40/0x50) from [<c0208060>] (atmel_rx_dma_release+0x88/0xb8) [<c0208060>] (atmel_rx_dma_release+0x88/0xb8) from [<c0209740>] (atmel_shutdown+0x104/0x160) [<c0209740>] (atmel_shutdown+0x104/0x160) from [<c0205e8c>] (uart_port_shutdown+0x2c/0x38) Signed-off-by: Marek Roszko <mark.roszko@gmail.com> Acked-by: Leilei Zhao <leilei.zhao@atmel.com> Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-01-25serial: amba-pl011: use port lock to guard control register accessJon Medhurst
commit fe43390702a1b5741fdf217063b05c7612b38303 upstream. When the pl011 is being used for a console, pl011_console_write forces the control register (CR) to enable the UART for transmission and then restores this to the original value afterwards. It does this while holding the port lock. Unfortunately, when the uart is started or shutdown - say in response to userland using the serial device for a terminal - then this updates the control register without any locking. This means we can have pl011_console_write Save CR pl011_startup Initialise CR, e.g. enable receive pl011_console_write Restore old CR with receive not enabled this result is a serial port which doesn't respond to any input. A similar race in reverse could happen when the device is shutdown. We can fix these problems by taking the port lock when updating CR. Signed-off-by: Jon Medhurst <tixy@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-01-09serial: 8250_dw: add new ACPI IDsMika Westerberg
commit d24c195f90cb1adb178d26d84c722d4b9e551e05 upstream. Newer Intel PCHs with LPSS have the same Designware controllers than Haswell but ACPI IDs are different. Add these IDs to the driver list. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-01-09TTY: pmac_zilog, check existence of ports in pmz_console_init()Geert Uytterhoeven
commit dc1dc2f8a5dd863bf2e79f338fc3ae29e99c683a upstream. When booting a multi-platform m68k kernel on a non-Mac with "console=ttyS0" on the kernel command line, it crashes with: Unable to handle kernel NULL pointer dereference at virtual address (null) Oops: 00000000 PC: [<0013ad28>] __pmz_startup+0x32/0x2a0 ... Call Trace: [<002c5d3e>] pmz_console_setup+0x64/0xe4 The normal tty driver doesn't crash, because init_pmz() checks pmz_ports_count again after calling pmz_probe(). In the serial console initialization path, pmz_console_init() doesn't do this, causing the driver to crash later. Add a check for pmz_ports_count to fix this. Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org> Cc: Finn Thain <fthain@telegraphics.com.au> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-01-09n_tty: Fix apparent order of echoed outputPeter Hurley
commit 1075a6e2dc7e2a96efc417b98dd98f57fdae985d upstream. With block processing of echoed output, observed output order is still required. Push completed echoes and echo commands prior to output. Introduce echo_mark echo buffer index, which tracks completed echo commands; ie., those submitted via commit_echoes but which may not have been committed. Ensure that completed echoes are output prior to subsequent terminal writes in process_echoes(). Fixes newline/prompt output order in cooked mode shell. Reported-by: Karl Dahlke <eklhad@comcast.net> Reported-by: Mikulas Patocka <mpatocka@redhat.com> Signed-off-by: Peter Hurley <peter@hurleysoftware.com> Tested-by: Karl Dahlke <eklhad@comcast.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-01-09tty: Fix hang at ldsem_down_read()Peter Hurley
commit cf872776fc84128bb779ce2b83a37c884c3203ae upstream. When a controlling tty is being hung up and the hang up is waiting for a just-signalled tty reader or writer to exit, and a new tty reader/writer tries to acquire an ldisc reference concurrently with the ldisc reference release from the signalled reader/writer, the hangup can hang. The new reader/writer is sleeping in ldsem_down_read() and the hangup is sleeping in ldsem_down_write() [1]. The new reader/writer fails to wakeup the waiting hangup because the wrong lock count value is checked (the old lock count rather than the new lock count) to see if the lock is unowned. Change helper function to return the new lock count if the cmpxchg was successful; document this behavior. [1] edited dmesg log from reporter SysRq : Show Blocked State task PC stack pid father systemd D ffff88040c4f0000 0 1 0 0x00000000 ffff88040c49fbe0 0000000000000046 ffff88040c4a0000 ffff88040c49ffd8 00000000001d3980 00000000001d3980 ffff88040c4a0000 ffff88040593d840 ffff88040c49fb40 ffffffff810a4cc0 0000000000000006 0000000000000023 Call Trace: [<ffffffff810a4cc0>] ? sched_clock_cpu+0x9f/0xe4 [<ffffffff810a4cc0>] ? sched_clock_cpu+0x9f/0xe4 [<ffffffff810a4cc0>] ? sched_clock_cpu+0x9f/0xe4 [<ffffffff810a4cc0>] ? sched_clock_cpu+0x9f/0xe4 [<ffffffff817a6649>] schedule+0x24/0x5e [<ffffffff817a588b>] schedule_timeout+0x15b/0x1ec [<ffffffff810a4cc0>] ? sched_clock_cpu+0x9f/0xe4 [<ffffffff817aa691>] ? _raw_spin_unlock_irq+0x24/0x26 [<ffffffff817aa10c>] down_read_failed+0xe3/0x1b9 [<ffffffff817aa26d>] ldsem_down_read+0x8b/0xa5 [<ffffffff8142b5ca>] ? tty_ldisc_ref_wait+0x1b/0x44 [<ffffffff8142b5ca>] tty_ldisc_ref_wait+0x1b/0x44 [<ffffffff81423f5b>] tty_write+0x7d/0x28a [<ffffffff814241f5>] redirected_tty_write+0x8d/0x98 [<ffffffff81424168>] ? tty_write+0x28a/0x28a [<ffffffff8115d03f>] do_loop_readv_writev+0x56/0x79 [<ffffffff8115e604>] do_readv_writev+0x1b0/0x1ff [<ffffffff8116ea0b>] ? do_vfs_ioctl+0x32a/0x489 [<ffffffff81167d9d>] ? final_putname+0x1d/0x3a [<ffffffff8115e6c7>] vfs_writev+0x2e/0x49 [<ffffffff8115e7d3>] SyS_writev+0x47/0xaa [<ffffffff817ab822>] system_call_fastpath+0x16/0x1b bash D ffffffff81c104c0 0 5469 5302 0x00000082 ffff8800cf817ac0 0000000000000046 ffff8804086b22a0 ffff8800cf817fd8 00000000001d3980 00000000001d3980 ffff8804086b22a0 ffff8800cf817a48 000000000000b9a0 ffff8800cf817a78 ffffffff81004675 ffff8800cf817a44 Call Trace: [<ffffffff81004675>] ? dump_trace+0x165/0x29c [<ffffffff810a4cc0>] ? sched_clock_cpu+0x9f/0xe4 [<ffffffff8100edda>] ? save_stack_trace+0x26/0x41 [<ffffffff817a6649>] schedule+0x24/0x5e [<ffffffff817a588b>] schedule_timeout+0x15b/0x1ec [<ffffffff810a4cc0>] ? sched_clock_cpu+0x9f/0xe4 [<ffffffff817a9f03>] ? down_write_failed+0xa3/0x1c9 [<ffffffff817aa691>] ? _raw_spin_unlock_irq+0x24/0x26 [<ffffffff817a9f0b>] down_write_failed+0xab/0x1c9 [<ffffffff817aa300>] ldsem_down_write+0x79/0xb1 [<ffffffff817aada3>] ? tty_ldisc_lock_pair_timeout+0xa5/0xd9 [<ffffffff817aada3>] tty_ldisc_lock_pair_timeout+0xa5/0xd9 [<ffffffff8142bf33>] tty_ldisc_hangup+0xc4/0x218 [<ffffffff81423ab3>] __tty_hangup+0x2e2/0x3ed [<ffffffff81424a76>] disassociate_ctty+0x63/0x226 [<ffffffff81078aa7>] do_exit+0x79f/0xa11 [<ffffffff81086bdb>] ? get_signal_to_deliver+0x206/0x62f [<ffffffff810b4bfb>] ? lock_release_holdtime.part.8+0xf/0x16e [<ffffffff81079b05>] do_group_exit+0x47/0xb5 [<ffffffff81086c16>] get_signal_to_deliver+0x241/0x62f [<ffffffff810020a7>] do_signal+0x43/0x59d [<ffffffff810f2af7>] ? __audit_syscall_exit+0x21a/0x2a8 [<ffffffff810b4bfb>] ? lock_release_holdtime.part.8+0xf/0x16e [<ffffffff81002655>] do_notify_resume+0x54/0x6c [<ffffffff817abaf8>] int_signal+0x12/0x17 Reported-by: Sami Farin <sami.farin@gmail.com> Signed-off-by: Peter Hurley <peter@hurleysoftware.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-12-12n_tty: Fix missing newline echoPeter Hurley
commit 39434abd942c8e4b9c14c06a03b3245beaf8467f upstream. When L_ECHONL is on, newlines are echoed regardless of the L_ECHO state; if set, ensure accumulated echoes are flushed before finishing the current input processing and before more output. Reported-by: Jason Gunthorpe <jgunthorpe@obsidianresearch.com Tested-by: Jason Gunthorpe <jgunthorpe@obsidianresearch.com> Signed-off-by: Peter Hurley <peter@hurleysoftware.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-12-04n_tty: Ensure reader restarts worker for next readerPeter Hurley
commit 42458f41d08f0873299e830464c1232a6839297d upstream. A departing reader must restart a flush_to_ldisc() worker _before_ the next reader enters the read loop; this is to avoid the new reader concluding no more i/o is available and prematurely exiting, when the old reader simply hasn't re-started the worker yet. Signed-off-by: Peter Hurley <peter@hurleysoftware.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-12-04tty: Reset hupped state on openPeter Hurley
commit d4855e1fc03c2bb32dd64badf51cec5a2a26ab2a upstream. A common security idiom is to hangup the current tty (via vhangup()) after forking but before execing a root shell. This hangs up any existing opens which other processes may have and ensures subsequent opens have the necessary permissions to open the root shell tty/pty. Reset the TTY_HUPPED state after the driver has successfully returned the opened tty (perform the reset while the tty is locked to avoid racing with concurrent hangups). Reported-by: Heorhi Valakhanovich <valahanovich@tut.by> Signed-off-by: Peter Hurley <peter@hurleysoftware.com> Tested-by: Heorhi Valakhanovich <valahanovich@tut.by> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-12-04n_tty: Fix echo overrun tail computationPeter Hurley
commit 6f2225363c205e186c1465c2c7c84f17c1635504 upstream. Commit cbfd0340ae1993378fd47179db949e050e16e697, 'n_tty: Process echoes in blocks', introduced an error when consuming the echo buffer tail to prevent buffer overrun, where the incorrect operation code byte is checked to determine how far to advance the tail to the next echo byte. Check the correct byte for the echo operation code byte. Signed-off-by: Peter Hurley <peter@hurleysoftware.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-12-04tty: incorrect test of echo_buf() result for ECHO_OP_STARTRoel Kluin
commit c476f6584b0011741b4f0316f1ac4aa3a99403e1 upstream. test echo_buf() result for ECHO_OP_START Signed-off-by: Roel Kluin <roel.kluin@gmail.com> Acked-by: Peter Hurley <peter@hurleysoftware.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-12-04n_tty: Fix 4096-byte canonical readsPeter Hurley
commit c77569d2f3ef7844ee4ac7005a57da6898b302a8 upstream. Although the maximum allowable canonical line is specified to be 255 bytes (MAX_CANON), the practical limit has actually been the size of the line discipline read buffer (N_TTY_BUF_SIZE == 4096). Commit 32f13521ca68bc624ff6effc77f308a52b038bf0, n_tty: Line copy to user buffer in canonical mode, limited the line copy to 4095 bytes. With a completely full line discipline read buffer and a userspace buffer > 4095, _no_ data was copied, and the read() syscall returned 0, indicating EOF. Fix the interval arithmetic to compute the correct number of bytes to copy to userspace in the range [1..4096]. Signed-off-by: Peter Hurley <peter@hurleysoftware.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-11-29n_tty: Fix missing newline echoPeter Hurley
When L_ECHONL is on, newlines are echoed regardless of the L_ECHO state; if set, ensure accumulated echoes are flushed before finishing the current input processing and before more output. Cc: <stable@vger.kernel.org> # 3.12.x Reported-by: Jason Gunthorpe <jgunthorpe@obsidianresearch.com Tested-by: Jason Gunthorpe <jgunthorpe@obsidianresearch.com> Signed-off-by: Peter Hurley <peter@hurleysoftware.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-11-26Revert "n_gsm: race between ld close and gsmtty open"Greg Kroah-Hartman
This reverts commit c284ee2cf12b55fa8496b2d098bf0938688f1c1c. Turns out the locking was incorrect. Reported-by: Fengguang Wu <fengguang.wu@intel.com> Cc: Chao Bi <chao.bi@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-11-25n_tty: Protect minimum_to_wake reset for concurrent readersPeter Hurley
With multiple, concurrent readers (each waiting to acquire the atomic_read_lock mutex), a departing reader may mistakenly reset minimum_to_wake after a new reader has already set a new value. Protect the minimum_to_wake reset with the atomic_read_lock critical section. Signed-off-by: Peter Hurley <peter@hurleysoftware.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-11-25tty: Reset hupped state on openPeter Hurley
A common security idiom is to hangup the current tty (via vhangup()) after forking but before execing a root shell. This hangs up any existing opens which other processes may have and ensures subsequent opens have the necessary permissions to open the root shell tty/pty. Reset the TTY_HUPPED state after the driver has successfully returned the opened tty (perform the reset while the tty is locked to avoid racing with concurrent hangups). Reported-by: Heorhi Valakhanovich <valahanovich@tut.by> Signed-off-by: Peter Hurley <peter@hurleysoftware.com> Cc: stable <stable@vger.kernel.org> # 3.12 Tested-by: Heorhi Valakhanovich <valahanovich@tut.by> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-11-25TTY: amiserial, add missing platform checkGeert Uytterhoeven
When booting a multi-platform m68k kernel on a non-Amiga with "console=ttyS0" on the kernel command line, it crashes with: Unable to handle kernel access at virtual address 81dff01c Oops: 00000000 PC: [<001e09a8>] serial_console_write+0xc/0x70 Add the missing platform check to amiserial_console_init() to fix this. Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-11-25TTY: pmac_zilog, check existence of ports in pmz_console_init()Geert Uytterhoeven
When booting a multi-platform m68k kernel on a non-Mac with "console=ttyS0" on the kernel command line, it crashes with: Unable to handle kernel NULL pointer dereference at virtual address (null) Oops: 00000000 PC: [<0013ad28>] __pmz_startup+0x32/0x2a0 ... Call Trace: [<002c5d3e>] pmz_console_setup+0x64/0xe4 The normal tty driver doesn't crash, because init_pmz() checks pmz_ports_count again after calling pmz_probe(). In the serial console initialization path, pmz_console_init() doesn't do this, causing the driver to crash later. Add a check for pmz_ports_count to fix this. Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org> Cc: Finn Thain <fthain@telegraphics.com.au> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>