summaryrefslogtreecommitdiff
path: root/drivers/tty
AgeCommit message (Collapse)Author
2015-06-22serial: imx: Fix DMA handling for IDLE condition abortsPhilipp Zabel
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: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-06-22n_tty: Fix auditing support for cannonical modeLaura Abbott
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: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-06-06tty/n_gsm.c: fix a memory leak when gsmtty is removedPan Xinhui
commit 8f9cfeed3eae86c70d3b04445a6f2036b27b6304 upstream. when gsmtty_remove put dlci, it will cause memory leak if dlci->port's refcount is zero. So we do the cleanup work in .cleanup callback instead. dlci will be last put in two call chains. 1) gsmld_close -> gsm_cleanup_mux -> gsm_dlci_release -> dlci_put 2) gsmld_remove -> dlci_put so there is a race. the memory leak depends on the race. In call chain 2. we hit the memory leak. below comment tells. release_tty -> tty_driver_remove_tty -> gsmtty_remove -> dlci_put -> tty_port_destructor (WARN_ON(port->itty) and return directly) | tty->port->itty = NULL; | tty_kref_put ---> release_one_tty -> gsmtty_cleanup (added by our patch) So our patch fix the memory leak by doing the cleanup work after tty core did. Signed-off-by: Pan Xinhui <xinhuix.pan@intel.com> Fixes: dfabf7ffa30585 Acked-by: Jiri Slaby <jslaby@suse.cz> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-06-06xen/events: don't bind non-percpu VIRQs with percpu chipDavid Vrabel
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: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-05-17xen/console: Update console event channel on resumeBoris Ostrovsky
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: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-05-13tty/serial: at91: maxburst was missing for dma transfersLudovic Desroches
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: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-05-13serial: of-serial: Remove device_type = "serial" registrationMichal Simek
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: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-04-19n_tty: Fix read buffer overwrite when no newlinePeter Hurley
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: Greg Kroah-Hartman <gregkh@linuxfoundation.org> (backported from commit fb5ef9e7da39968fec6d6f37f20a23d23740c75e) Signed-off-by: Joseph Salisbury <joseph.salisbury@canonical.com>
2015-04-19tty: serial: fsl_lpuart: clear receive flag on FIFO flushStefan Agner
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: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-03-26Change email address for 8250_pciRussell King
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: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-03-18tty: fix up atime/mtime mess, take fourJiri Slaby
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: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-03-18TTY: fix tty_wait_until_sent on 64-bit machinesJohan Hovold
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: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-03-06vt: provide notifications on selection changesNicolas Pitre
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: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-03-06tty/serial: at91: fix error handling in atmel_serial_probe()Cyrille Pitchen
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: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-03-06tty: Prevent untrappable signals from malicious programPeter Hurley
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: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-01-29tty: Fix pty master poll() after slave closes v2Francesco Ruggeri
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> Cc: Peter Hurley <peter@hurleysoftware.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-01-16n_tty: Fix read_buf race condition, increment read_head after pushing dataChristian Riesch
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: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-01-16serial: samsung: wait for transfer completion before clock disableRobert Baldyga
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: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-11-14tty: Fix high cpu load if tty is unreleaseablePeter Hurley
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: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-11-14serial: Fix divide-by-zero fault in uart_get_divisor()Peter Hurley
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: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-10-30tty: omap-serial: fix division by zeroFrans Klaver
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: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-10-15serial: 8250: Add Quark X1000 to 8250_pci.cBryan O'Donoghue
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: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-10-05serial: 8250_dma: check the result of TX buffer mappingHeikki Krogerus
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: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-09-05serial: core: Preserve termios c_cflag for console resumePeter Hurley
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: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-08-14sunsab: Fix detection of BREAK on sunsab serial consoleChristopher Alexander Tobias Schulze
[ 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: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-07-09tty: Correct INPCK handlingPeter Hurley
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: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-07-09serial: Fix IGNBRK handlingPeter Hurley
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: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-06-11Staging: speakup: Update __speakup_paste_selection() tty (ab)usage to match vtBen Hutchings
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: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-06-078250_core: Fix unwanted TX chars writeLoic Poulain
commit b08c9c317e3f7764a91d522cd031639ba42b98cc upstream. On transmit-hold-register empty, serial8250_tx_chars should be called only if we don't use DMA. DMA has its own tx cycle. Signed-off-by: Loic Poulain <loic.poulain@intel.com> Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-06-07serial: 8250: Fix thread unsafe __dma_tx_complete functionLoic Poulain
commit f8fd1b0350d3a4581125f5eda6528f5a2c5f9183 upstream. __dma_tx_complete is not protected against concurrent call of serial8250_tx_dma. it can lead to circular tail index corruption or parallel call of serial_tx_dma on the same data portion. This patch fixes this issue by holding the port lock. Signed-off-by: Loic Poulain <loic.poulain@intel.com> Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-05-31serial: omap: Fix missing pm_runtime_resume handling by simplifying codeTony Lindgren
commit d758c9c1b36b4d9a141c2146c70398d756167ed1 upstream. The lack of pm_runtime_resume handling for the device state leads into device wake-up interrupts not working after a while for runtime PM. Also, serial-omap is confused about the use of device_may_wakeup. The checks for device_may_wakeup should only be done for suspend and resume, not for pm_runtime_suspend and pm_runtime_resume. The wake-up events for PM runtime should always be enabled. The lack of pm_runtime_resume handling leads into device wake-up interrupts not working after a while for runtime PM. Rather than try to patch over the issue of adding complex tests to the pm_runtime_resume, let's fix the issues properly: 1. Make serial_omap_enable_wakeup deal with all internal PM state handling so we don't need to test for up->wakeups_enabled elsewhere. Later on once omap3 boots in device tree only mode we can also remove the up->wakeups_enabled flag and rely on the wake-up interrupt enable/disable state alone. 2. Do the device_may_wakeup checks in suspend and resume only, for runtime PM the wake-up events need to be always enabled. 3. Finally just call serial_omap_enable_wakeup and make sure we call it also in pm_runtime_resume. 4. Note that we also have to use disable_irq_nosync as serial_omap_irq calls pm_runtime_get_sync. Fixes: 2a0b965cfb6e (serial: omap: Add support for optional wake-up) Signed-off-by: Tony Lindgren <tony@atomide.com> Acked-by: Felipe Balbi <balbi@ti.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-05-13n_tty: Fix n_tty_write crash when echoing in raw modePeter Hurley
commit 4291086b1f081b869c6d79e5b7441633dc3ace00 upstream. 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> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-05-13tty: Fix lockless tty buffer racePeter Hurley
commit 62a0d8d7c2b29f92850e4ee3c38e5dfd936e92b2 upstream. Commit 6a20dbd6caa2358716136144bf524331d70b1e03, "tty: Fix race condition between __tty_buffer_request_room and flush_to_ldisc" correctly identifies an unsafe race condition between __tty_buffer_request_room() and flush_to_ldisc(), where the consumer flush_to_ldisc() prematurely advances the head before consuming the last of the data committed. For example: CPU 0 | CPU 1 __tty_buffer_request_room | flush_to_ldisc ... | ... | count = head->commit - head->read n = tty_buffer_alloc() | b->commit = b->used | b->next = n | | if (!count) /* T */ | if (head->next == NULL) /* F */ | buf->head = head->next In this case, buf->head has been advanced but head->commit may have been updated with a new value. Instead of reintroducing an unnecessary lock, fix the race locklessly. Read the commit-next pair in the reverse order of writing, which guarantees the commit value read is the latest value written if the head is advancing. Reported-by: Manfred Schlaegl <manfred.schlaegl@gmx.at> Signed-off-by: Peter Hurley <peter@hurleysoftware.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-05-13tty: serial: 8250_core.c Bug fix for Exar chips.Michael Welling
commit b790f210fe8423eff881b2a8a93ba5dbc45534d0 upstream. The sleep function was updated to put the serial port to sleep only when necessary. This appears to resolve the errant behavior of the driver as described in Kernel Bug 61961 – "My Exar Corp. XR17C/D152 Dual PCI UART modem does not work with 3.8.0". Signed-off-by: Michael Welling <mwelling@ieee.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-05-13drivers/tty/hvc: don't free hvc_console_setup after initTomoki Sekiyama
commit 501fed45b7e8836ee9373f4d31e2d85e3db6103a upstream. When 'console=hvc0' is specified to the kernel parameter in x86 KVM guest, hvc console is setup within a kthread. However, that will cause SEGV and the boot will fail when the driver is builtin to the kernel, because currently hvc_console_setup() is annotated with '__init'. This patch removes '__init' to boot the guest successfully with 'console=hvc0'. Signed-off-by: Tomoki Sekiyama <tomoki.sekiyama@hds.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-05-06hvc: ensure hvc_init is only ever called once in hvc_console.cPaul Gortmaker
commit f76a1cbed18c86e2d192455f0daebb48458965f3 upstream. Commit 3e6c6f630a5282df8f3393a59f10eb9c56536d23 ("Delay creation of khcvd thread") moved the call of hvc_init from being a device_initcall into hvc_alloc, and used a non-null hvc_driver as indication of whether hvc_init had already been called. The problem with this is that hvc_driver is only assigned a value at the bottom of hvc_init, and so there is a window where multiple hvc_alloc calls can be in progress at the same time and hence try and call hvc_init multiple times. Previously the use of device_init guaranteed that hvc_init was only called once. This manifests itself as sporadic instances of two hvc_init calls racing each other, and with the loser of the race getting -EBUSY from tty_register_driver() and hence that virtual console fails: Couldn't register hvc console driver virtio-ports vport0p1: error -16 allocating hvc for port Here we add an atomic_t to guarantee we'll never run hvc_init twice. Cc: Rusty Russell <rusty@rustcorp.com.au> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Fixes: 3e6c6f630a52 ("Delay creation of khcvd thread") Reported-by: Jim Somerville <Jim.Somerville@windriver.com> Tested-by: Jim Somerville <Jim.Somerville@windriver.com> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-04-26tty: 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: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-04-26tty: 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: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-03-06sparc: 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-02-22Revert "tty: Set correct tty name in 'active' sysfs attribute"Greg Kroah-Hartman
This reverts commit d8a5dc3033af2fd6d16030d2ee4fbd073460fe54. This breaks plymouth installs, either because plymouth is using the file "incorrectly" or because the patch is incorrect. Either way, this needs to be reverted until it is all figured out. Reported-by: Josh Boyer <jwboyer@fedoraproject.org> Reported-by: Ray Strode <halfline@gmail.com> Cc: Lennart Poettering <lennart@poettering.net> Cc: Kay Sievers <kay@vrfy.org> Cc: Jiri Slaby <jslaby@suse.cz> Cc: David Herrmann <dh.herrmann@gmail.com> Cc: Werner Fink <werner@suse.de> Cc: Hannes Reinecke <hare@suse.de> Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-02-13vt: Fix secure clear screenPetr Písař
\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> Cc: stable <stable@vger.kernel.org> # 3.6 Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-02-13serial: 8250: Support XR17V35x fraction divisorJoe Schultz
The Exar XR17V35x family of UARTs have an additional fractional divisor register (DLD) which was not being used. Calculate and set this register for these devices to reduce their baud rate error. Signed-off-by: Joe Schultz <jschultz@xes-inc.com> Signed-off-by: Aaron Sierra <asierra@xes-inc.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-02-13n_tty: Fix stale echo outputPeter Hurley
When echoes cannot be flushed to output (usually because the tty has no more write room) and L_ECHO is subsequently turned off, then when L_ECHO is turned back on, stale echoes are output. Output completed echoes regardless of the L_ECHO setting: 1. before normal writes to that tty 2. if the tty was stopped by soft flow control and is being restarted Reported-by: Mikulas Patocka <mpatocka@redhat.com> Cc: <stable@vger.kernel.org> # 3.13.x Signed-off-by: Peter Hurley <peter@hurleysoftware.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-02-13serial: sirf: fix kernel panic caused by unpaired spinlockQipan Li
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> Cc: stable <stable@vger.kernel.org> # 3.12 Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-02-13serial: 8250_pci: unbreak last serial ports on NetMos 9865 cardsDmitry Eremin-Solenikov
Aparently 9865 uses standard BAR encoding scheme (unlike 99xx cards). Current pci_netmos_9900_setup() uses wrong BAR indices for the 9865 PCI device, function 2. Using standard BAR indices makes all 6 ports work for me. Thus disable the NetMos 9900 quirk for NetMos 9865 pci device. For the reference, here is the relevant part of lspci for my device: 02:07.0 Serial controller: MosChip Semiconductor Technology Ltd. PCI 9865 Multi-I/O Controller (prog-if 02 [16550]) Subsystem: Device a000:1000 Flags: bus master, medium devsel, latency 32, IRQ 17 I/O ports at ac00 [size=8] Memory at fcfff000 (32-bit, non-prefetchable) [size=4K] Memory at fcffe000 (32-bit, non-prefetchable) [size=4K] Capabilities: [48] Power Management version 2 Kernel driver in use: serial 02:07.1 Serial controller: MosChip Semiconductor Technology Ltd. PCI 9865 Multi-I/O Controller (prog-if 02 [16550]) Subsystem: Device a000:1000 Flags: bus master, medium devsel, latency 32, IRQ 18 I/O ports at a800 [size=8] Memory at fcffd000 (32-bit, non-prefetchable) [size=4K] Memory at fcffc000 (32-bit, non-prefetchable) [size=4K] Capabilities: [48] Power Management version 2 Kernel driver in use: serial 02:07.2 Communication controller: MosChip Semiconductor Technology Ltd. PCI 9865 Multi-I/O Controller Subsystem: Device a000:3004 Flags: bus master, medium devsel, latency 32, IRQ 19 I/O ports at a400 [size=8] I/O ports at a000 [size=8] I/O ports at 9c00 [size=8] I/O ports at 9800 [size=8] Memory at fcffb000 (32-bit, non-prefetchable) [size=4K] Capabilities: [48] Power Management version 2 Kernel driver in use: serial Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-02-13n_tty: Fix poll() when TIME_CHAR and MIN_CHAR == 0Peter Hurley
Commit eafbe67f84761d787802e5113d895a316b6292fe, n_tty: Refactor input_available_p() by call site broke poll() when TIME_CHAR(tty) and MIN_CHAR(tty) are both 0. When TIME_CHAR and MIN_CHAR are both 0, input is available if the read_cnt is 1 (not 0). Reported-by: Eric Dumazet <edumazet@google.com> Tested-by: Eric Dumazet <edumazet@google.com> Reported-by: Stephane Eranian <eranian@google.com> Tested-by: David Ahern <dsahern@gmail.com> Tested-by: Arnaldo Carvalho de Melo <acme@redhat.com> Signed-off-by: Peter Hurley <peter@hurleysoftware.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-02-13serial: omap: fix rs485 probe on defered pinctrlMichael Grzeschik
If the gpio is not yet available we better also defer the probing in the rs485 case. Signed-off-by: Michael Grzeschik <m.grzeschik@pengutronix.de> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-02-13serial: 8250_dw: fix compilation warning when !CONFIG_PM_SLEEPMika Westerberg
CONFIG_PM will be set if either or both CONFIG_PM_SLEEP and CONFIG_PM_RUNTIME is set. Compiling the driver with !CONFIG_PM_SLEEP causes following compilation warnings: drivers/tty/serial/8250/8250_dw.c:404:12: warning: ‘dw8250_suspend’ defined but not used [-Wunused-function] drivers/tty/serial/8250/8250_dw.c:413:12: warning: ‘dw8250_resume’ defined but not used [-Wunused-function] Fix this by using CONFIG_PM_SLEEP instead. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-02-13serial: omap-serial: Move info message to probe functionMarkus Pargmann
Currently the info message about a missing wakeirq for uart is printed every time the serial driver's startup function is called. This happens multiple times and not just once. This can cause lots of extra messages at boot time, slowing things down. It is caused by commit 2a0b965cfb6e (serial: omap: Add support for optional wake-up) which was applied for v3.13-rc1. This patch moves the infomessage to the probe function to display it only once. Reported-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Markus Pargmann <mpa@pengutronix.de> Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Cc: stable <stable@vger.kernel.org> # 3.13 Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-02-07tty: Set correct tty name in 'active' sysfs attributeHannes Reinecke
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. This resolves an issue on s390 platforms in determining the correct console device to use. Cc: Lennart Poettering <lennart@poettering.net> Cc: Kay Sievers <kay@vrfy.org> Cc: Jiri Slaby <jslaby@suse.cz> Cc: David Herrmann <dh.herrmann@gmail.com> Signed-off-by: Werner Fink <werner@suse.de> Signed-off-by: Hannes Reinecke <hare@suse.de> Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
generated by cgit v1.2.3 (git 2.0.4) at 2025-01-29 05:00:42 +0000