An error occurred fetching the project authors.
- 24 Jul, 2015 1 commit
-
-
Peter Hurley authored
While closing, new rx data may be received after the input buffers have been flushed but before stop_rx() halts receiving [1]. The new data might not be processed by flush_to_ldisc() until after uart_shutdown() and normal input processing is re-enabled (ie., tty->closing = 0). The race is outlined below: CPU 0 | CPU 1 | uart_close() | tty_port_close_start() | tty->closing = 1 | tty_ldisc_flush() | | => IRQ | while (LSR & data ready) | uart_insert_char() | tty_flip_buffer_push() | <= EOI stop_rx() | . uart_shutdown() | . free xmit.buf | . tty_port_tty_set(NULL) | . tty->closing = 0 | . | flush_to_ldisc() | n_tty_receive_buf_common() | __receive_buf() | ... | commit_echoes() | uart_flush_chars() | __uart_start() | ** OOPS on port.tty deref ** tty_ldisc_flush() | Input processing must be prevented from echoing (tty->closing = 1) until _after_ the input buffers have been flushed again at the end of uart_close(). [1] In fact, some input may actually be buffered _after_ stop_rx() since the rx interrupt may have already triggered but not yet been handled when stop_rx() disables rx interrupts. Fixes: 2e758910 ("serial: core: Flush ldisc after dropping port mutex in uart_close()") Reported-by:Robert Elliott <elliott@hp.com> Signed-off-by:
Peter Hurley <peter@hurleysoftware.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 13 Jun, 2015 1 commit
-
-
Joakim Nordell authored
Align with coding guidelines: Replaced a chain of "else if" by a switch case. Signed-off-by:
Joakim Nordell <joakim.nordell@intel.com> Signed-off-by:
-
- 31 May, 2015 1 commit
-
-
Noam Camus authored
Support command line parameters of the form: earlycon=<name>,io|mmio|mmio32|mmio32be,<addr>,<options> This commit seem to be needed even after commit: serial: 8250: Add support for big-endian MMIO accesses c627f2ceSigned-off-by:
Noam Camus <noamc@ezchip.com> Signed-off-by:
-
- 06 May, 2015 1 commit
-
-
Rasmus Villemoes authored
tty_name no longer uses the buf parameter, so remove it along with all the 64 byte stack buffers that used to be passed in. Mostly generated by the coccinelle script @depends on patch@ identifier buf; constant C; expression tty; @@ - char buf[C]; <+... - tty_name(tty, buf) + tty_name(tty) ...+> allmodconfig compiles, so I'm fairly confident the stack buffers weren't used for other purposes as well. Signed-off-by:
Rasmus Villemoes <linux@rasmusvillemoes.dk> Reviewed-by:
Jesper Nilsson <jesper.nilsson@axis.com> Acked-by:
Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by:
-
- 28 Apr, 2015 1 commit
-
-
Peter Hurley authored
Fix uart_console_write() kernel-doc build warnings. Warning(drivers/tty/serial/serial_core.c:1778): No description found for parameter 'putchar' Warning(drivers/tty/serial/serial_core.c:1778): Excess function parameter 'write' description in 'uart_console_write' Fixes: 1cfe42b7 ("serial: core: Fix kernel doc for uart_console_write()") Reported-by:
Fengguang Wu <fengguang.wu@intel.com> Signed-off-by:
-
- 26 Mar, 2015 2 commits
-
-
Peter Hurley authored
'/**' is required to start a kernel-doc comment block. Acked-by:
Rob Herring <robh@kernel.org> Signed-off-by:
-
Peter Hurley authored
UART drivers that share ttyS namespace cannot trivially compute the ttyS index from the port->line value since the minor_start may be offset from minor 64. Further, to do so requires a pointer to the uart driver since there is no back pointer from uart_port to uart_driver. Rather than have UART drivers computing the minor value by themselves, encapsulate within the serial core at port registration time. Signed-off-by:
-
- 07 Mar, 2015 2 commits
-
-
Peter Hurley authored
Prepare to support console-defined matching; refactor the command line parameter string processing from parse_options() into a new core function, uart_parse_earlycon(), which decodes command line parameters of the form: earlycon=<name>,io|mmio|mmio32,<addr>,<options> console=<name>,io|mmio|mmio32,<addr>,<options> earlycon=<name>,0x<addr>,<options> console=<name>,0x<addr>,<options> Signed-off-by:
-
Fabian Frederick authored
Use helper functions to access current->state. Direct assignments are prone to races and therefore buggy. Thanks to Peter Zijlstra for the exact definition of the problem. Suggested-By:
Peter Zijlstra <peterz@infradead.org> Signed-off-by:
Fabian Frederick <fabf@skynet.be> Signed-off-by:
-
- 02 Feb, 2015 2 commits
-
-
Peter Hurley authored
hw-assisted flow control support was added to the serial core in v3.8 with commits, dba05832 ("SERIAL: core: add hardware assisted h/w flow control support") 2cbacafd ("SERIAL: core: add hardware assisted s/w flow control support") 9aba8d5b ("SERIAL: core: add throttle/unthrottle callbacks for hardware assisted flow control") Since then, additional requirements for serial core support have arisen. Specifically, 1. Separate tx and rx flow control settings for UARTs which only support tx flow control (ie., autoCTS). 2. Disable sw-assisted CTS flow control in autoCTS mode 3. Support for RTS flow control by serial core and userspace in autoRTS mode Distinguish mode from capability; introduce UPSTAT_AUTORTS, UPSTAT_AUTOCTS and UPSTAT_AUTOXOFF which, when set by the uart driver, enable serial core support for hw-assisted rx, hw-assisted tx and hw-assisted in-band/IXOFF rx flow control, respectively. [Note: hw-assisted in-band/IXON tx flow control does not require serial core support/intervention and can be enabled by the uart driver when required.] These modes must be set/reset in the driver's set_termios() method, based on termios settings, and thus can be safely queried in any context in which one of the port lock, port mutex or termios rwsem are held. Set these modes in the 2 in-tree drivers, omap-serial and 8250_omap, which currently use UPF_HARD_FLOW/UPF_SOFT_FLOW support. Retain UPF_HARD_FLOW and UPF_SOFT_FLOW as capabilities; re-define UPF_HARD_FLOW as both UPF_AUTO_RTS and UPF_AUTO_CTS to allow for distinct and separate rx and tx flow control capabilities. Disable sw-assisted CTS flow control when UPSTAT_AUTOCTS is enabled. Signed-off-by:
-
Peter Hurley authored
When the uart port being suspended is a console and consoles are not suspending (kernel command line contains no_console_suspend), then no action is performed for that port, and the function can return early. If the function has not returned early, then one of the conditions is not true, so the expression (console_suspend_enabled || !uart_console(uport)) must be true and can be eliminated. Similarly, the expression (console_suspend_enabled && uart_console(uport)) simplifies to just uart_console(uport). Signed-off-by:
-
- 02 Jan, 2015 1 commit
-
-
James Bottomley authored
This is a partial revert of 2f2dafe7 (serial: serial_core.c: printk replacement) which gets us booting again. The real problem seems to be the _emit path in early boot. However, until we can root cause it, we need at least to get boot working. Fixes: 2f2dafe7 Cc: stable@vger.kernel.org Signed-off-by:
James Bottomley <JBottomley@Parallels.com> Signed-off-by:
-
- 26 Nov, 2014 1 commit
-
-
Kevin Cernekee authored
Since most drivers interpret UPIO_MEM32 to mean "little-endian" and use readl/writel to access the registers, add a parallel UPIO_MEM32BE to request the use of big-endian MMIO accessors (ioread32be/iowrite32be). Signed-off-by:
Kevin Cernekee <cernekee@gmail.com> Signed-off-by:
-
- 06 Nov, 2014 16 commits
-
-
Ricardo Ribalda Delgado authored
Introduce an homogeneous lock system between setting and using the rs485 data of the uart_port. This patch should not be split into multiple ones in order to avoid leaving the tree in an unstable state. Acked-by:
Nicolas Ferre <nicolas.ferre@atmel.com> Reviewed-by:
Alan Cox <alan@linux.intel.com> Suggested-by:
Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com> Signed-off-by:
-
Ricardo Ribalda Delgado authored
Once there is no more handlers for TIOC[GS]RS485 there is no need to call the driver specific ioctl when the generic implementation is missing. Reviewed-by:
-
Ricardo Ribalda Delgado authored
The following drivers: 8250_core, atmel_serial, max310x, mcf, omap-serial and sci16is7xx implement code to handle RS485 ioctls. In order to avoid code duplication, we implement a simple ioctl handler on the serial_core layer. This handler can be used by all the other drivers instead of duplicating code. Until this is the only RS485 ioctl handler, it will try first the rs485_config callback and if it is not present it will call the driver specific ioctl. Reviewed-by:
-
Peter Hurley authored
UART drivers which enable modem status interrupts when switching to N_PPS line discipline need to determine if modem status interrupts should be disabled when switching from N_PPS. Specifically, the set_ldisc() notification needs to evaluate UART_ENABLE_MS() which requires termios->c_cflag. Convert in-tree UART drivers to new interface. Signed-off-by:
-
Peter Hurley authored
Three UART drivers (8250, atmel & amba-pl010) enable modem status interrupts if the line discipline is changed to N_PPS. However, the uart port flags may only be safely modified while holding the port mutex. Signed-off-by:
-
Peter Hurley authored
A port count mismatch occurs if mutex_lock_interruptible() exits uart_open() and the port has already been opened. This may prematurely close a port on an open tty. Since uart_close() is _always_ called if uart_open() fails, the port count must be corrected if errors occur. Always increment the port count in uart_open(), regardless of errors; always decrement the port count in uart_close(). Note that tty_port_close_start() decrements the port count when uart_open() was successful. Signed-off-by:
-
Peter Hurley authored
uart_start() only claims the port->lock to call __uart_start(), which does the actual processing. Eliminate the extra acquire/release in uart_write(); call __uart_start() directly with port->lock already held. Signed-off-by:
-
Peter Hurley authored
The key function of uart_add_one_port() is to cross-reference the UART driver's port structure with the serial core's state table; keep the assignments together and document this crucial association. Signed-off-by:
-
Peter Hurley authored
tty_port_init() initializes close_delay and closing_wait to these same values; remove. Signed-off-by:
-
Peter Hurley authored
The wrapped line looks wrong and out-of-place; leave it as >80 char line. Signed-off-by:
-
Peter Hurley authored
The low-level uart driver may modify termios settings to override settings that are not compatible with the uart, such as CRTSCTS. Thus, callers of the low-level uart driver's set_termios() method must hold termios_rwsem write lock to prevent concurrent access to termios, in case such override occurs. The termios_rwsem lock requirement does not extend to console setup (ie., uart_set_options), as console setup cannot race with tty operations. Nor does this lock requirement extend to functions which cannot be concurrent with tty ioctls (ie., uart_port_startup() and uart_resume_port()). Further, always claim the port mutex to protect hardware re-reprogramming in the set_termios() uart driver method. Note this is unnecessary for console initialization in uart_set_options() which cannot be concurrent with other uart operations. Signed-off-by:
-
Peter Hurley authored
The tty buffers (and any line discipline buffers) must be flushed after the UART hardware has shutdown; otherwise, a racing open on the same tty may receive data from the previous session, which is a security hazard. However, holding the port mutex while flushing the line discipline buffers creates a lock inversion if the set_termios() handler takes the port mutex (as it does in the followup patch, 'serial: Fix locking for uart driver set_termios method'. Flush the ldisc buffers after dropping the port mutex; the tty lock is still held which prevents a concurrent open() from advancing while flushing. Since no new rx data is possible after uart_shutdown() until a new open reinitializes the port, the later flush has no impact on what data is being discarded. Signed-off-by:
-
Peter Hurley authored
In the context of the final tty & port close, flushing the tx ring buffer after the hardware has already been shutdown and the ring buffer freed is neither required nor desirable. uart_flush_buffer() performs 3 operations: 1. Resets tx ring buffer indices, but the tx ring buffer has already been freed and the indices are reset if the port is re-opened. 2. Calls uart driver's flush_buffer() method 5 in-tree uart drivers define flush_buffer() methods: amba-pl011, atmel-serial, imx, serial-tegra, timbuart These have been refactored into the shutdown() method, if required. 3. Kicks the ldisc for more writing, but this is undesirable. The file handle is being released; any waiting writer will will be kicked out by tty_release() with a warning. Further, the N_TTY ldisc may generate SIGIO for a file handle which is no longer valid. Cc: Nicolas Ferre <nicolas.ferre@atmel.com> Cc: Russell King <linux@arm.linux.org.uk> Cc: Laxman Dewangan <ldewangan@nvidia.com> Signed-off-by: -
Peter Hurley authored
The struct uart_port.flags field is type upf_t, as are the matching bit definitions. Change local mask variable to type upf_t. Fixes sparse warnings: drivers/tty/serial/serial_core.c:620:22: warning: invalid assignment: |= drivers/tty/serial/serial_core.c:620:22: left side has type unsigned int drivers/tty/serial/serial_core.c:620:22: right side has type restricted upf_t drivers/tty/serial/serial_core.c:622:22: warning: invalid assignment: |= drivers/tty/serial/serial_core.c:622:22: left side has type unsigned int drivers/tty/serial/serial_core.c:622:22: right side has type restricted upf_t drivers/tty/serial/serial_core.c:624:17: warning: restricted upf_t degrades to integer drivers/tty/serial/serial_core.c:626:22: warning: invalid assignment: &= drivers/tty/serial/serial_core.c:626:22: left side has type unsigned int drivers/tty/serial/serial_core.c:626:22: right side has type restricted upf_t drivers/tty/serial/serial_core.c:629:20: warning: restricted upf_t degrades to integer drivers/tty/serial/serial_core.c:632:20: warning: restricted upf_t degrades to integer drivers/tty/serial/serial_core.c:643:22: warning: invalid assignment: |= drivers/tty/serial/serial_core.c:643:22: left side has type unsigned int drivers/tty/serial/serial_core.c:643:22: right side has type restricted upf_t drivers/tty/serial/serial_core.c:645:22: warning: invalid assignment: |= drivers/tty/serial/serial_core.c:645:22: left side has type unsigned int drivers/tty/serial/serial_core.c:645:22: right side has type restricted upf_t drivers/tty/serial/serial_core.c:647:17: warning: restricted upf_t degrades to integer drivers/tty/serial/serial_core.c:649:22: warning: invalid assignment: &= drivers/tty/serial/serial_core.c:649:22: left side has type unsigned int drivers/tty/serial/serial_core.c:649:22: right side has type restricted upf_t drivers/tty/serial/serial_core.c:652:20: warning: restricted upf_t degrades to integer drivers/tty/serial/serial_core.c:655:20: warning: restricted upf_t degrades to integer Signed-off-by:
-
Peter Hurley authored
Commit 299245a1, serial: core: Privatize modem status enable flags, introduced the upstat_t type and matching bit definitions. The purpose is to produce sparse warnings if the wrong bit definitions are used (by warning of implicit integer conversions). Fix implicit conversion to integer return type from uart_cts_enabled() and uart_dcd_enabled(). Fixes the following sparse warnings: drivers/tty/serial/serial_core.c:63:30: warning: incorrect type in return expression (different base types) drivers/tty/serial/serial_core.c:63:30: expected int drivers/tty/serial/serial_core.c:63:30: got restricted upstat_t include/linux/serial_core.h:364:30: warning: incorrect type in return expression (different base types) include/linux/serial_core.h:364:30: expected bool include/linux/serial_core.h:364:30: got restricted upstat_t include/linux/serial_core.h:364:30: warning: incorrect type in return expression (different base types) include/linux/serial_core.h:364:30: expected bool include/linux/serial_core.h:364:30: got restricted upstat_t Reported-by:
-
Peter Hurley authored
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> Cc: <stable@vger.kernel.org> # all Signed-off-by:
-
- 03 Oct, 2014 1 commit
-
-
Greg Kroah-Hartman authored
This reverts commit a86713b1. Kevin Hilman writes: Multiple boot failures on ARM[1] were bisected down to this patch. How was this patch tested, and on which platforms? Also, the changelog states that this should be done only for UART_CAP_SLEEP, but the patch does it for every UART. Greg, I suggest this patch be dropped from tty-next until it has been better described and tested. [1] http://lists.linaro.org/pipermail/kernel-build-reports/2014-October/005550.htmlReported-by:
Kevin Hilman <khilman@kernel.org> Cc: Sudhir Sreedharan <ssreedharan@mvista.com> Signed-off-by:
-
- 29 Sep, 2014 1 commit
-
-
Sudhir Sreedharan authored
For console devices having UART_CAP_SLEEP capability, the uart_pm_state has to be initialized to UART_PM_STATE_ON. Otherwise the LCR regiser values are reinitialized when uart_change_pm is called from uart_configure_port. Signed-off-by:
Sudhir Sreedharan <ssreedharan@mvista.com> Signed-off-by:
-
- 24 Sep, 2014 4 commits
-
-
Peter Hurley authored
uart_set_termios() is called with interrupts enabled; no need to save and restore the interrupt state when taking the uart port lock. Signed-off-by:
-
Peter Hurley authored
tty->hw_stopped is not used by the tty core and is thread-unsafe; hw_stopped is a member of a bitfield whose fields are updated non-atomically and no lock is suitable for serializing updates. Replace serial core usage of tty->hw_stopped with uport->hw_stopped. Use int storage which works around Alpha EV4/5 non-atomic byte storage, since uart_port uses different locks to protect certain fields within the structure. Signed-off-by:
-
Peter Hurley authored
The serial core uses the tty port flags, ASYNC_CTS_FLOW and ASYNC_CD_CHECK, to track whether CTS and DCD changes should be ignored or handled. However, the tty port flags are not safe for atomic bit operations and no lock provides serialized updates. Introduce the struct uart_port status field to track CTS and DCD enable states, and serialize access with uart port lock. Substitute uart_cts_enabled() helper for tty_port_cts_enabled(). Signed-off-by:
-
Peter Hurley authored
The serial core provides two helper functions, uart_handle_dcd_change() and uart_handle_cts_change(), for UART drivers to use at interrupt time. The serial core expects the UART driver to hold the uart port lock when calling these helpers to prevent state corruption. If lockdep enabled, trigger a warning if the uart port lock is not held when calling these helper functions. Signed-off-by:
-
- 08 Sep, 2014 5 commits
-
-
Peter Hurley authored
Prepare for spin lock assertion; move non-trivial assignment into function body. Signed-off-by:
-
Peter Hurley authored
uart_unthrottle() attempts to avoid sending START and the previous x_char if the previous x_char has not yet been sent. However, this optimization could leave the sender in a throttled state; for example, if the sender is throttled and this unthrottle coincides with a manual tcflow(TCION) from user-space, then neither START would be sent. Signed-off-by:
-
Peter Hurley authored
The UART driver is expected to clear port->x_char after transmission while holding the port->lock. However, the serial core fails to take the port->lock before assigning port->xchar. This allows for the following race CPU 0 | CPU 1 | | serial8250_handle_irq | ... | serial8250_tx_chars | if (port->x_char) | serial_out(up, UART_TX, port->x_char) uart_send_xchar | port->x_char = ch | | port->x_char = 0 port->ops->start_tx() | | The x_char on CPU 0 will never be sent. Take the port->lock in uart_send_xchar() before assigning port->x_char. Signed-off-by: -
Peter Hurley authored
Unwrap if() conditional; no functional change. Signed-off-by:
-
Peter Hurley authored
This reverts commit 06aa82e4. This commit purports to enable auto CTS flow control for the 8250 UART driver. However, the 8250 UART driver already supports auto CTS flow control via UART_CAP_AFE and UART_CAP_EFR. Indeed, this patch introduces another DT attribute for which an existing firmware flag already exists ("auto-flow-control"). Furthermore, the use of UPF_HARD_FLOW requires the UART driver to define .throttle and .unthrottle methods, neither of which are defined for the 8250 UART driver (which will result in a NULL ptr dereference). Finally, this patch supposes to fix existing bugs in the serial core for auto CTS-enabled hardware, but does not include the class of hardware for which these bugs exist. CC: Murali Karicheri <m-karicheri2@ti.com> CC: Rob Herring <robh+dt@kernel.org> Signed-off-by:
-
