summaryrefslogtreecommitdiff
path: root/drivers/tty
AgeCommit message (Collapse)Author
2019-02-19tty: serial: samsung: Enable baud clock during initialisationStuart Menefy
The Exynos 5260, like the 5433, appears to require baud clock as well as pclk to be running before accessing any of the registers, otherwise an external abort is raised. The serial driver already enables baud clock when required, but only if it knows which clock is baud clock. On older SoCs baud clock may be selected from a number of possible clocks so to support this the driver only selects which clock to use for baud clock when a port is opened, at which point the desired baud rate is known and the best clock can be selected. The result is that there are a number of circumstances in which registers are accessed without first explicitly enabling baud clock: - while the driver is being initialised - the initial parts of opening a port for the first time - when resuming if the port hasn't been already opened The 5433 overcomes this currently by marking the baud clock as CLK_IGNORE_UNUSED, so the clock is always enabled, however for the 5260 I've been trying to avoid this. This change adds code to pick the first available clock to use as baud clock and enables it while initialising the driver. This code wouldn't be sufficient on a SoC which supports multiple possible baud clock sources _and_ requires the correct baud clock to be enabled before accessing any of the serial port registers (in particular the register which selects which clock to use as the baud clock). As far as I know such hardware doesn't exist. Signed-off-by: Stuart Menefy <stuart.menefy@mathembedded.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-02-19serial: uartps: Fix stuck ISR if RX disabled with non-empty FIFOAnssi Hannula
If RX is disabled while there are still unprocessed bytes in RX FIFO, cdns_uart_handle_rx() called from interrupt handler will get stuck in the receive loop as read bytes will not get removed from the RX FIFO and CDNS_UART_SR_RXEMPTY bit will never get set. Avoid the stuck handler by checking first if RX is disabled. port->lock protects against race with RX-disabling functions. This HW behavior was mentioned by Nathan Rossi in 43e98facc4a3 ("tty: xuartps: Fix RX hang, and TX corruption in termios call") which fixed a similar issue in cdns_uart_set_termios(). The behavior can also be easily verified by e.g. setting CDNS_UART_CR_RX_DIS at the beginning of cdns_uart_handle_rx() - the following loop will then get stuck. Resetting the FIFO using RXRST would not set RXEMPTY either so simply issuing a reset after RX-disable would not work. I observe this frequently on a ZynqMP board during heavy RX load at 1M baudrate when the reader process exits and thus RX gets disabled. Fixes: 61ec9016988f ("tty/serial: add support for Xilinx PS UART") Signed-off-by: Anssi Hannula <anssi.hannula@bitwise.fi> Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-02-19tty: serial: remove redundant likely annotationChengguang Xu
unlikely has already included in IS_ERR(), so just remove redundant likely annotation. Signed-off-by: Chengguang Xu <cgxu519@gmx.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-02-14tty/n_hdlc: mark expected switch fall-throughGustavo A. R. Silva
In preparation to enabling -Wimplicit-fallthrough, mark switch cases where we are expecting to fall through. This patch fixes the following warning: drivers/tty/n_hdlc.c: In function ‘n_hdlc_tty_ioctl’: drivers/tty/n_hdlc.c:775:3: warning: this statement may fall through [-Wimplicit-fallthrough=] switch (arg) { ^~~~~~ drivers/tty/n_hdlc.c:782:2: note: here default: ^~~~~~~ Warning level 3 was used: -Wimplicit-fallthrough=3 Notice that, in this particular case, the code comment is modified in accordance with what GCC is expecting to find. This patch is part of the ongoing efforts to enable -Wimplicit-fallthrough. Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-02-13serial: 8250_pci: Have ACCES cards that use the four port Pericom PI7C9X7954 ↵Jay Dolan
chip use the pci_pericom_setup() The four port Pericom chips have the fourth port at the wrong address. Make use of quirk to fix it. Fixes: c8d192428f52 ("serial: 8250: added acces i/o products quad and octal serial cards") Cc: stable <stable@vger.kernel.org> Signed-off-by: Jay Dolan <jay.dolan@accesio.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-02-13serial: 8250_pci: Fix number of ports for ACCES serial cardsJay Dolan
Have the correct number of ports created for ACCES serial cards. Two port cards show up as four ports, and four port cards show up as eight. Fixes: c8d192428f52 ("serial: 8250: added acces i/o products quad and octal serial cards") Signed-off-by: Jay Dolan <jay.dolan@accesio.com> Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-02-12vt: perform safe console erase in the right orderNicolas Pitre
Commit 4b4ecd9cb853 ("vt: Perform safe console erase only once") removed what appeared to be an extra call to scr_memsetw(). This missed the fact that set_origin() must be called before clearing the screen otherwise old screen content gets restored on the screen when using vgacon. Let's fix that by moving all the scrollback handling to flush_scrollback() where it logically belongs, and invoking it before the actual screen clearing in csi_J(), making the code simpler in the end. Reported-by: Matthew Whitehead <tedheadster@gmail.com> Signed-off-by: Nicolas Pitre <nico@linaro.org> Tested-by: Matthew Whitehead <tedheadster@gmail.com> Fixes: 4b4ecd9cb853 ("vt: Perform safe console erase only once") Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-02-12tty/nozomi: use pci_iomap instead of ioremap_nocacheHugo Lefeuvre
Use pci_iomap instead of ioremap_nocache in nozomi_card_init(). This is a cleaner way to do PCI MMIO (performs additional checks) and allows to drop the manual call to pci_resource_start. pci_iomap relies on ioremap for MMIO and thus has uncached behavior. Signed-off-by: Hugo Lefeuvre <hle@owl.eu.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-02-12tty/synclink: remove ISA supportChristoph Hellwig
The ISA support in this driver is horribly outdated and the last driver that passes a NULL dev argument to the DMA mapping routines. Drop the support, if someone wants to go through the work of converting it to a proper isa_driver we can resurrect it. Signed-off-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-02-11serial: 8250_pci: Replace custom code with pci_match_id()Heikki Krogerus
serial_pci_is_blacklisted() is very similar to pci_match_id() implementation. Replace it with the latter. Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-02-11Merge 5.0-rc6 into tty-nextGreg Kroah-Hartman
We need the tty fixes in here for other patches to be based on. Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-02-08Merge tag 'tty-5.0-rc6' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty Pull tty/serial fixes from Greg KH: "Here are some small tty and serial fixes for 5.0-rc6. Nothing huge, just a few small fixes for reported issues. The speakup fix is in here as it is a tty operation issue. All of these have been in linux-next for a while with no reported problems" * tag 'tty-5.0-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty: serial: fix race between flush_to_ldisc and tty_open staging: speakup: fix tty-operation NULL derefs serial: sh-sci: Do not free irqs that have already been freed serial: 8250_pci: Make PCI class test non fatal tty: serial: 8250_mtk: Fix potential NULL pointer dereference
2019-02-08serial: max310x: Correction of the initial setting of the MODE1 bits for ↵Alexander Shiyan
various supported ICs. The MODE1 register bits have different values for different ICs. This patch corrects the initial setting of this register in accordance with the datasheets, which will allow you to get the expected values when debugging the driver. Signed-off-by: Alexander Shiyan <shc_work@mail.ru> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-02-07audit: join tty records to their syscallRichard Guy Briggs
AUDIT_TTY records were logged as seperate events from their syscall records. Join them so they are logged as the single event that they are. Please see the github issue https://github.com/linux-audit/audit-kernel/issues/106 Signed-off-by: Richard Guy Briggs <rgb@redhat.com> Signed-off-by: Paul Moore <paul@paul-moore.com>
2019-02-02Merge tag 'riscv-for-linus-5.0-rc5' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/palmer/riscv-linux Pull RISC-V fixes from Palmer Dabbelt: "This contains a handful of mostly-independent patches: - make our port respect TIF_NEED_RESCHED, which fixes CONFIG_PREEMPT=y kernels - fix double-put of OF nodes - fix a misspelling of target in our Kconfig - generic PCIe is enabled in our defconfig - fix our SBI early console to properly handle line endings - fix max_low_pfn being counted in PFNs - a change to TASK_UNMAPPED_BASE to match what other arches do This has passed my standard 'boot Fedora' flow" * tag 'riscv-for-linus-5.0-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/palmer/riscv-linux: riscv: Adjust mmap base address at a third of task size riscv: fixup max_low_pfn with PFN_DOWN. tty/serial: use uart_console_write in the RISC-V SBL early console RISC-V: defconfig: Add CRYPTO_DEV_VIRTIO=y RISC-V: defconfig: Enable Generic PCIE by default RISC-V: defconfig: Move CONFIG_PCI{,E_XILINX} RISC-V: Kconfig: fix spelling mistake "traget" -> "target" RISC-V: asm/page.h: fix spelling mistake "CONFIG_64BITS" -> "CONFIG_64BIT" RISC-V: fix bad use of of_node_put RISC-V: Add _TIF_NEED_RESCHED check for kernel thread when CONFIG_PREEMPT=y
2019-02-01PCI: Move Rohm Vendor ID to generic listAndy Shevchenko
Move the Rohm Vendor ID to pci_ids.h instead of defining it in several drivers. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Mark Brown <broonie@kernel.org> Acked-by: Linus Walleij <linus.walleij@linaro.org>
2019-01-31serial: fix race between flush_to_ldisc and tty_openGreg Kroah-Hartman
There still is a race window after the commit b027e2298bd588 ("tty: fix data race between tty_init_dev and flush of buf"), and we encountered this crash issue if receive_buf call comes before tty initialization completes in tty_open and tty->driver_data may be NULL. CPU0 CPU1 ---- ---- tty_open tty_init_dev tty_ldisc_unlock schedule flush_to_ldisc receive_buf tty_port_default_receive_buf tty_ldisc_receive_buf n_tty_receive_buf_common __receive_buf uart_flush_chars uart_start /*tty->driver_data is NULL*/ tty->ops->open /*init tty->driver_data*/ it can be fixed by extending ldisc semaphore lock in tty_init_dev to driver_data initialized completely after tty->ops->open(), but this will lead to get lock on one function and unlock in some other function, and hard to maintain, so fix this race only by checking tty->driver_data when receiving, and return if tty->driver_data is NULL, and n_tty_receive_buf_common maybe calls uart_unthrottle, so add the same check. Because the tty layer knows nothing about the driver associated with the device, the tty layer can not do anything here, it is up to the tty driver itself to check for this type of race. Fix up the serial driver to correctly check to see if it is finished binding with the device when being called, and if not, abort the tty calls. [Description and problem report and testing from Li RongQing, I rewrote the patch to be in the serial layer, not in the tty core - gregkh] Reported-by: Li RongQing <lirongqing@baidu.com> Tested-by: Li RongQing <lirongqing@baidu.com> Signed-off-by: Wang Li <wangli39@baidu.com> Signed-off-by: Zhang Yu <zhangyu31@baidu.com> Signed-off-by: Li RongQing <lirongqing@baidu.com> Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-01-31serial: mps2-uart: Add parentheses around conditional in mps2_uart_shutdownNathan Chancellor
Clang warns: drivers/tty/serial/mps2-uart.c:351:6: warning: logical not is only applied to the left hand side of this bitwise operator [-Wlogical-not-parentheses] if (!mps_port->flags & UART_PORT_COMBINED_IRQ) { ^ ~ drivers/tty/serial/mps2-uart.c:351:6: note: add parentheses after the '!' to evaluate the bitwise operator first if (!mps_port->flags & UART_PORT_COMBINED_IRQ) { ^ ( ) drivers/tty/serial/mps2-uart.c:351:6: note: add parentheses around left hand side expression to silence this warning if (!mps_port->flags & UART_PORT_COMBINED_IRQ) { ^ ( ) 1 warning generated. As it was intended for this check to be the inverse of the one at the bottom of mps2_init_port, add parentheses around the whole conditional. Fixes: 775ea4ea2fd9 ("serial: mps2-uart: support combined irq") Signed-off-by: Nathan Chancellor <natechancellor@gmail.com> Acked-by: Vladimir Murzin <vladimir.murzin@arm.com> Link: https://github.com/ClangBuiltLinux/linux/issues/344 Reviewed-by: Nick Desaulniers <ndesaulniers@google.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-01-30tty: increase the default flip buffer limit to 2*640KManfred Schlaegl
We increase the default limit for buffer memory allocation by a factor of 10 to 640K to prevent data loss when using fast serial interfaces. For example when using RS485 without flow-control at speeds of 1Mbit/s an upwards we've run into problems such as applications being too slow to read out this buffer (on embedded devices based on imx53 or imx6). If you want to write transmitted data to a slow SD card and thus have realtime requirements, this limit can become a problem. That shouldn't be the case and 640K buffers fix such problems for us. This value is a maximum limit for allocation only. It has no effect on systems that currently run fine. When transmission is slow enough applications and hardware can keep up and increasing this limit doesn't change anything. It only _allows_ to allocate more than 2*64K in cases we currently fail to allocate memory despite having some. Signed-off-by: Manfred Schlaegl <manfred.schlaegl@ginzinger.com> Signed-off-by: Martin Kepplinger <martin.kepplinger@ginzinger.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-01-30tty: ipwireless: Fix potential NULL pointer dereferenceYueHaibing
There is a potential NULL pointer dereference in case alloc_ctrl_packet() fails and returns NULL. Fixes: 099dc4fb6265 ("ipwireless: driver for PC Card 3G/UMTS modem") Signed-off-by: YueHaibing <yuehaibing@huawei.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-01-30serial: mps2-uart: support combined irqVladimir Murzin
It turns out that some designs went for implementing only combined interrupt for rx, tx and overrun, which is currently not supported by the driver. Support of combined irq is built on top of existent irq handlers and activated automatically if only single irq was specified in device tree. Signed-off-by: Vladimir Murzin <vladimir.murzin@arm.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-01-30serial: mps2-uart: move to dynamic port allocationVladimir Murzin
Some designs, like MPS3, expose number of virtual serial ports which already close or exceeds MPS2_MAX_PORTS. Increasing MPS2_MAX_PORTS would have negative impact (in terms of memory consumption) on tiny MPS2 platform which, in fact, has only one physically populated UART. Start with converting existent static port array to idr. As a bonus it make driver not to fail in case when no alias was specified in device tree. Note: there is no need in idr_destroy() because code doesn't unload since ce87122911f8 ("serial: mps2-uart: make driver explicitly non-modular") Signed-off-by: Vladimir Murzin <vladimir.murzin@arm.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-01-30serdev: ttyport: call tiocmget and tiocmset ops directlyJohan Hovold
The tty struct holds a pointer to the driver's tty operations so drop the unnecessary driver dereference when calling tiocmget and tiocmset. Note that this also makes the calls match the preceding sanity checks as expected. Signed-off-by: Johan Hovold <johan@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-01-30serial: sh-sci: Do not free irqs that have already been freedChris Brandt
Since IRQs might be muxed on some parts, we need to pay attention when we are freeing them. Otherwise we get the ugly WARNING "Trying to free already-free IRQ 20". Fixes: 628c534ae735 ("serial: sh-sci: Improve support for separate TEI and DRI interrupts") Cc: stable <stable@vger.kernel.org> Signed-off-by: Chris Brandt <chris.brandt@renesas.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-01-30serial: 8250_pci: Make PCI class test non fatalAndy Shevchenko
As has been reported the National Instruments serial cards have broken PCI class. The commit 7d8905d06405 ("serial: 8250_pci: Enable device after we check black list") made the PCI class check mandatory for the case when device is listed in a quirk list. Make PCI class test non fatal to allow broken card be enumerated. Fixes: 7d8905d06405 ("serial: 8250_pci: Enable device after we check black list") Cc: stable <stable@vger.kernel.org> Reported-by: Guan Yung Tseng <guan.yung.tseng@ni.com> Tested-by: Guan Yung Tseng <guan.yung.tseng@ni.com> Tested-by: KHUENY.Gerhard <Gerhard.KHUENY@bachmann.info> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-01-30tty: serial: 8250_mtk: Fix potential NULL pointer dereferenceGustavo A. R. Silva
There is a potential NULL pointer dereference in case devm_kzalloc() fails and returns NULL. Fix this by adding a NULL check on data->dma This bug was detected with the help of Coccinelle. Fixes: 85b5c1dd0456 ("serial: 8250-mtk: add uart DMA support") Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-01-30serial: Add Tegra Combined UART driverThierry Reding
The Tegra Combined UART (TCU) is a mailbox-based mechanism that allows multiplexing multiple "virtual UARTs" into a single hardware serial port. The TCU is the primary serial port on Tegra194 devices. Add a TCU driver utilizing the mailbox framework, as the used mailboxes are part of Tegra HSP blocks that are already controlled by the Tegra HSP mailbox driver. Based on work by Mikko Perttunen <mperttunen@nvidia.com>. Signed-off-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-01-30Serial: Ingenic: Add support for the X1000.Zhou Yanjie
Add support for probing the 8250_ingenic driver on the X1000 Soc from Ingenic. Signed-off-by: Zhou Yanjie <zhouyanjie@zoho.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-01-30serial: 8250: Add OF support for Xscale variantLinus Walleij
This adds support for device tree probing for the Intel Xscale 8250 variant needed to support device tree on the Intel IXP4xx platforms. Cc: devicetree@vger.kernel.org Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-01-30serial: fsl_lpuart: DMA support for 32-bit variantAtsushi Nemoto
Add DMA support for 32-bit variant of the LPUART, such as LS1021A. Signed-off-by: Tomonori Sakita <tomonori.sakita@sord.co.jp> Signed-off-by: Atsushi Nemoto <atsushi.nemoto@sord.co.jp> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-01-30tty: ldisc: add sysctl to prevent autoloading of ldiscsGreg Kroah-Hartman
By default, the kernel will automatically load the module of any line dicipline that is asked for. As this sometimes isn't the safest thing to do, provide a sysctl to disable this feature. By default, we set this to 'y' as that is the historical way that Linux has worked, and we do not want to break working systems. But in the future, perhaps this can default to 'n' to prevent this functionality. Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Reviewed-by: Theodore Ts'o <tytso@mit.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-01-28Merge 5.0-rc4 into tty-nextGreg Kroah-Hartman
We need the tty and serial fixes in here as well. Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-01-23tty/serial: use uart_console_write in the RISC-V SBL early consoleAndreas Schwab
This enables proper NLCR processing. Suggested-by: Anup Patel <anup@brainfault.org> Signed-off-by: Andreas Schwab <schwab@suse.de> Reviewed-by: Anup Patel <anup@brainfault.org> Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Palmer Dabbelt <palmer@sifive.com>
2019-01-22sysrq: Remove duplicated sysrq messagePetr Mladek
The commit 97f5f0cd8cd0a0544 ("Input: implement SysRq as a separate input handler") added pr_fmt() definition. It caused a duplicated message prefix in the sysrq header messages, for example: [ 177.053931] sysrq: SysRq : Show backtrace of all active CPUs [ 742.864776] sysrq: SysRq : HELP : loglevel(0-9) reboot(b) crash(c) Fixes: 97f5f0cd8cd0a05 ("Input: implement SysRq as a separate input handler") Signed-off-by: Petr Mladek <pmladek@suse.com> Reviewed-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-01-22sysrq: Restore original console_loglevel when sysrq disabledPetr Mladek
The sysrq header line is printed with an increased loglevel to provide users some positive feedback. The original loglevel is not restored when the sysrq operation is disabled. This bug was introduced in 2.6.12 (pre-git-history) by the commit ("Allow admin to enable only some of the Magic-Sysrq functions"). Signed-off-by: Petr Mladek <pmladek@suse.com> Reviewed-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com> Reviewed-by: Steven Rostedt (VMware) <rostedt@goodmis.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-01-22serial: fsl_lpuart: consider TX FIFO too in lpuart32_tx_emptyAtsushi Nemoto
The commit 3876a00fcb6b ("tty: serial: fsl_lpuart: consider TX FIFO too in tx_empty") fixed lpuart_tx_empty only. Fix lpuart32_tx_empty too. Signed-off-by: Atsushi Nemoto <atsushi.nemoto@sord.co.jp> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-01-22serial: fsl_lpuart: specify transmit FIFO size for 32-bit variantAtsushi Nemoto
The commit 4e8f24593709 ("tty: serial: fsl_lpuart: specify transmit FIFO size") fixed lpuart_startup only. Fix lpuart32_startup too. Signed-off-by: Atsushi Nemoto <atsushi.nemoto@sord.co.jp> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-01-22serial: fsl_lpuart: fix maximum acceptable baud rate with over-samplingTomonori Sakita
Using over-sampling ratio, lpuart can accept baud rate upto uartclk / 4. Signed-off-by: Tomonori Sakita <tomonori.sakita@sord.co.jp> Signed-off-by: Atsushi Nemoto <atsushi.nemoto@sord.co.jp> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-01-22tty: serial: qcom_geni_serial: Allow mctrl when flow control is disabledMatthias Kaehlcke
The geni set/get_mctrl() functions currently do nothing unless hardware flow control is enabled. Remove this arbitrary limitation. Suggested-by: Johan Hovold <johan@kernel.org> Fixes: 8a8a66a1a18a ("tty: serial: qcom_geni_serial: Add support for flow control") Signed-off-by: Matthias Kaehlcke <mka@chromium.org> Reviewed-by: Johan Hovold <johan@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-01-21tty: Handle problem if line discipline does not have receive_bufGreg Kroah-Hartman
Some tty line disciplines do not have a receive buf callback, so properly check for that before calling it. If they do not have this callback, just eat the character quietly, as we can't fail this call. Reported-by: Jann Horn <jannh@google.com> Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-01-18vt: ignore sequences that contain ':' in parameters.Martin Hostettler
csi sequences can contain subparameters delimited by ':' characters. For now just ignore the whole sequence in this case. Such sequences are used by more capable terminal implementations with T.416 high color modes or extended underline rendition attributes. Also ignore sequences with private use characters '?', '>', '=' and '>' that are not at the initial position. Signed-off-by: Martin Hostettler <textshell@uchuujin.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-01-18vt: ignore csi sequences with intermediate characters.Martin Hostettler
Various csi sequences contain intermediate characters between the parameters and the final character. Introduce a additional state that cleanly ignores these sequences. This allows the vt to ignore these sequences used by more capable terminal implementations such as "request mode", etc. Signed-off-by: Martin Hostettler <textshell@uchuujin.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-01-18vt: Implement parsing for >, =, < private sequences.Martin Hostettler
Private sequences can start with '>', '=' and (in theory) '<'. Implement correct parsing for these. The newly parsable sequences are cleanly ignored as it is customary with terminal emulators. This allows the vt to ignore various sequences used by more capable terminal implementations such as "Secondary Device Attributes", "Tertiary Device Attributes" and various advanced configuration commands that don't have dedicated terminfo entries. Signed-off-by: Martin Hostettler <textshell@uchuujin.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-01-18vt: refactor vc_ques to allow of other private sequences.Martin Hostettler
The vc_ques keeps track if a csi sequence is a private DEC control function beginning with '?'. Nowadays some private control functions begin with '>' and '='. Switch the code to instead use a new 3-bit vc_priv that allows for all private use parameter prefixes. Signed-off-by: Martin Hostettler <textshell@uchuujin.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-01-18vt: annotate implicit fall throughsMathieu Malaterre
There is a plan to build the kernel with -Wimplicit-fallthrough and these places in the code produced warnings (W=1). Fix them up. This commit remove the following warning: drivers/tty/vt/vt.c:2112:6: warning: this statement may fall through [-Wimplicit-fallthrough=] drivers/tty/vt/vt.c:2237:6: warning: this statement may fall through [-Wimplicit-fallthrough=] Signed-off-by: Mathieu Malaterre <malat@debian.org> Acked-by: Gustavo A. R. Silva <gustavo@embeddedor.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-01-18vcs: restore and document initial POLLPRI eventNicolas Pitre
Restore and document the forced initial POLLPRI event reporting when poll() is used for the first time. This used to be the implemented behavior before recent changes. Because of the way poll() is implemented, this prevents losing an event happening between the last read() and the first poll() invocation. Since poll() for /dev/vcs* was not always supported, user space probes for its availability as follows: int fd = open("/dev/vcsa", O_RDONLY); struct pollfd p = { .fd = fd, .events = POLLPRI }; available = (poll(&p, 1, 0) == 1); Semantically, it makes sense to signal the first event as such even if it might be spurious. The screen could be modified, and modified back to its initial state before we get to read it, so users must be prepared for that anyway. Signed-off-by: Nicolas Pitre <nico@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-01-18vcs: fasync(): make it consistent with poll()Nicolas Pitre
We use POLLPRI not POLLIN to wait for data with poll() as there is never any incoming data stream per se. Let's use the same semantic with fasync() for consistency, including the fact that a vt may go away. No known user space ever relied on the SIGIO reason so far, let alone FASYNC, so the risk of breakage is pretty much nonexistent. Signed-off-by: Nicolas Pitre <nico@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-01-18vcs: poll(): cope with a deallocated vtNicolas Pitre
When VT_DISALLOCATE is used on a vt, user space waiting with poll() on the corresponding /dev/vcs device is not awakened. This is now fixed by returning POLLHUP|POLLERR to user space. Also, in the normal screen update case, we don't set POLLERR anymore as POLLPRI alone is a much more logical response in a non-error situation, saving some confusion on the user space side. The only known user app making use of poll() on /dev/vcs* is BRLTTY which is known to cope with that change already, so the risk of breakage is pretty much nonexistent. Signed-off-by: Nicolas Pitre <nico@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-01-18vcsa: clamp header values when they don't fitNicolas Pitre
The /dev/vcsa* devices have a fixed char-sized header that stores the screen geometry and cursor location. Let's make sure it doesn't contain random garbage when those values exceed 255. If ever it becomes necessary to convey larger screen info to user space then a larger header in the not-yet-implemented /dev/vcsua* devices should be considered. Signed-off-by: Nicolas Pitre <nico@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-01-18vt: invoke notifier on screen size changeNicolas Pitre
User space using poll() on /dev/vcs devices are not awaken when a screen size change occurs. Let's fix that. Signed-off-by: Nicolas Pitre <nico@linaro.org> Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>