This is the last missing piece to get a kernel booting to a prompt in qemu-cris.
Signed-off-by: Niklas Cassel <nks@flawful.org>
Acked-by: Jesper Nilsson <jesper.nilsson@axis.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
sprop is unused in find_console_handle() since commit a752ee56ad
("tty: Update hypervisor tty drivers to use core stdout parsing code.")
Signed-off-by: Fabian Frederick <fabf@skynet.be>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The general agreed way to specify a fixed line number
for a serial console is to provide a "serial" alias
in the devicetree. Start parsing this property in
of_serial.
Signed-off-by: Lucas Stach <dev@lynxeye.de>
Acked-by: Olof Johansson <olof@lixom.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
EarlyCon support depends on serial console infrastructure, so the code
implementing it should depend on CONFIG_SERIAL_SAMSUNG_CONSOLE.
This patch fixes the following build break:
CC [M] drivers/tty/serial/samsung.o
drivers/tty/serial/samsung.c:2468:1: error: expected declaration specifiers or ‘...’ before string constant
drivers/tty/serial/samsung.c:2468:1: error: expected declaration specifiers or ‘...’ before ‘s3c2410_setup_earlycon’
drivers/tty/serial/samsung.c:2487:1: error: expected declaration specifiers or ‘...’ before string constant
drivers/tty/serial/samsung.c:2487:1: error: expected declaration specifiers or ‘...’ before ‘s3c2412_setup_earlycon’
drivers/tty/serial/samsung.c:2488:1: error: expected declaration specifiers or ‘...’ before string constant
drivers/tty/serial/samsung.c:2488:1: error: expected declaration specifiers or ‘...’ before ‘s3c2440_setup_earlycon’
drivers/tty/serial/samsung.c:2489:1: error: expected declaration specifiers or ‘...’ before string constant
drivers/tty/serial/samsung.c:2489:1: error: expected declaration specifiers or ‘...’ before ‘s3c6400_setup_earlycon’
drivers/tty/serial/samsung.c:2506:1: error: expected declaration specifiers or ‘...’ before string constant
drivers/tty/serial/samsung.c:2506:1: error: expected declaration specifiers or ‘...’ before ‘s5pv210_setup_earlycon’
drivers/tty/serial/samsung.c:2507:1: error: expected declaration specifiers or ‘...’ before string constant
drivers/tty/serial/samsung.c:2507:1: error: expected declaration specifiers or ‘...’ before ‘exynos4210_setup_earlycon’
drivers/tty/serial/samsung.c:2468:1: warning: ‘s3c2410_setup_earlycon’ defined but not used [-Wunused-function]
drivers/tty/serial/samsung.c:2487:1: warning: ‘s3c2412_setup_earlycon’ defined but not used [-Wunused-function]
drivers/tty/serial/samsung.c:2488:1: warning: ‘s3c2440_setup_earlycon’ defined but not used [-Wunused-function]
drivers/tty/serial/samsung.c:2489:1: warning: ‘s3c6400_setup_earlycon’ defined but not used [-Wunused-function]
drivers/tty/serial/samsung.c:2506:1: warning: ‘s5pv210_setup_earlycon’ defined but not used [-Wunused-function]
drivers/tty/serial/samsung.c:2507:1: warning: ‘exynos4210_setup_earlycon’ defined but not used [-Wunused-function]
make[3]: *** [drivers/tty/serial/samsung.o] Error 1
Reported-by: kbuild test robot <fengguang.wu@intel.com>
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
drivers/tty/serial/8250/8250_core.c:2503:6: sparse: symbol 'serial8250_set_divisor' was not declared. Should it be static?
Signed-off-by: Fengguang Wu <fengguang.wu@intel.com>
Cc: Peter Hurley <peter@hurleysoftware.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Add a full sc9836-uart driver for SC9836 SoC which is based on the
spreadtrum sharkl64 platform.
This driver also support earlycon.
Originally-by: Lanqing Liu <lanqing.liu@spreadtrum.com>
Signed-off-by: Orson Zhai <orson.zhai@spreadtrum.com>
Signed-off-by: Chunyan Zhang <chunyan.zhang@spreadtrum.com>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: Peter Hurley <peter@hurleysoftware.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Function s3c24xx_serial_start_tx_pio() enables interrupts if needed,
so we don't have to (or even we shouldn't) enable them before.
Signed-off-by: Robert Baldyga <r.baldyga@samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
tty_set_termios() is an internal helper intended for file scope use.
UART drivers which are capable of driving the RTS pin must
properly handle the tiocmset() method, regardless of termios settings.
A failure to do so is a UART driver bug and should be fixed there.
Do not use this interface to workaround UART driver bugs.
Cc: Johan Hedberg <johan.hedberg@gmail.com>
Cc: <linux-bluetooth@vger.kernel.org>
Signed-off-by: Peter Hurley <peter@hurleysoftware.com>
Acked-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The OMAP UART ignores MCR[1] (ie., RTS) when in autoRTS mode. This
makes it impossible for either the serial core or userspace to
manually flow control the sender.
Disable autoRTS mode when RTS is lowered and restore the previous
mode when RTS is raised.
Signed-off-by: Peter Hurley <peter@hurleysoftware.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Commit 88838d3112702 ("serial: omap_8250: Fix RTS handling") fixed
RTS pin control when in autoRTS mode.
New support added in "serial: core: Rework hw-assisted flow control support"
enables a much simpler approach; rather than masking out autoRTS
whenever writing the EFR register, use the UPSTAT_* mode to determine if
autoRTS should be enabled when raising RTS (in omap8250_set_mctrl()).
Signed-off-by: Peter Hurley <peter@hurleysoftware.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
hw-assisted flow control support was added to the serial core
in v3.8 with commits,
dba05832cb ("SERIAL: core: add hardware assisted h/w flow control support")
2cbacafd7a ("SERIAL: core: add hardware assisted s/w flow control support")
9aba8d5b01 ("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 <peter@hurleysoftware.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The PXA variant of the 8250 UART adds a UART enable bit which must not
be cleared. Make the earlycon support maintain this bit if it is set.
This implies some initialization of the UART, but we cannot
unconditionally set the bit as some other variants require this bit to
be clear for other functions.
Signed-off-by: Rob Herring <robh@kernel.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Jiri Slaby <jslaby@suse.cz>
Cc: linux-serial@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Add mrvl,pxa-uart and mrvl,mmp-uart compatible strings for the of_serial
driver. These are 8250 variants which have a port type of PORT_XSCALE.
There is also the serial driver pxa.c with these compatible strings
already. However, it can be replaced with the common 8250 driver. It has
some issues like it cannot coexist with the 8250 driver due to tty name
collision. That also means adding these compatible strings here should
not case a problem.
Signed-off-by: Rob Herring <robh@kernel.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Jiri Slaby <jslaby@suse.cz>
Cc: linux-serial@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Add support for alias parsing from the DT. This allows for consistent
tty numbering.
Signed-off-by: Rob Herring <robh@kernel.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Jiri Slaby <jslaby@suse.cz>
Cc: linux-serial@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The port shadow registers, ->fcr and ->mcr, must be protected from
concurrent updates. Relocate the shadow register updates in
serial8250_do_set_termios() to the port lock critical section.
Signed-off-by: Peter Hurley <peter@hurleysoftware.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
When using no_console_suspend, the serial console may be powered off
anyway during system sleep. Upon resume, the port may be in its default
power-on state, but is expected to continue console i/o before the device
has received its pm callback. The resultant garbage i/o can cause all
kinds of havoc on the remote end.
Use the scratch register as a canary to discover if the console
has been powered-off. Write a non-zero value to the scratch register
at port suspend and reprogram the port before any console i/o if the
scratch register != canary before port resume.
This workaround is disabled for omap_8250 (which uses different divisor
programming).
Credit to Doug Anderson <dianders@chromium.org> for the idea of using
the scratch register canary to discover port power-down.
Cc: Doug Anderson <dianders@chromium.org>
Signed-off-by: Peter Hurley <peter@hurleysoftware.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Exar XR17V35X PCIe uarts support a 4-bit fractional divisor register.
Refactor the divisor calculation from the divisor programming.
Allow a fractional result from serial8250_get_divisor() and pass this
result to serial8250_dl_write().
Simplify the calculation for quot and quot_frac. This was verified
to be identical to the results of the original calculation with a test
jig.
NB: The results were also compared with the divisor value chart
on pg 33 of the Exar XR17V352 datasheet, rev 1.0.3, here:
http://www.exar.com/common/content/document.ashx?id=1585
which differs from the calculated values by 1 in the fractional result.
This is because the calculated values are still rounded in the
fractional result, whereas the table values are truncated. Note
that the data error rate % values in the datasheet are for
rounded fractional results, as the truncated fractional results
have more error.
Cc: Joe Schultz <jschultz@xes-inc.com>
Cc: Aaron Sierra <asierra@xes-inc.com>
Signed-off-by: Peter Hurley <peter@hurleysoftware.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Refactor divisor register programming into a new function,
serial8250_set_divisor; this allows serial console to reinitialize
early after resume from suspend.
Signed-off-by: Peter Hurley <peter@hurleysoftware.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Refactor the computation of the LCR register value from termios c_cflag
into a new local function, serial8250_compute_lcr().
Signed-off-by: Peter Hurley <peter@hurleysoftware.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The UART_BUG_QUOT workaround adjusts the divisor computed from the
baud rate by serial8250_get_divisor(). Move the workaround into
serial8250_get_divisor(), so that divisor-from-baud computation
is encapsulated.
Signed-off-by: Peter Hurley <peter@hurleysoftware.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
16z135 IP Core has changed so the driver needs to be updated to respect
these changes. The following changes have been made:
* Don't invert the 16z135 modem status register when reading.
* Add module parameter to configure the (baud rate dependent) RX timeout.
Character timeout in seconds = (timeout_reg * baud_reg * 4)/freq_reg.
* Enable the handling of UART core's automatic flow control feature.
When AFE is active disable generation of modem status IRQs.
* Rework the handling of IRQs to be conform with newer FPGA versions and
take precautions not to miss an interrupt because of the destructive read
of the IIR register.
* Correct men_z135_handle_modem_status(), MSR is stat_reg[15:8] not
stat_reg[7:0]
* Correct calling of uart_handle_{dcd,cts}_change()
* Reset CLOCAL when CRTSCTS is set
Signed-off-by: Johannes Thumshirn <johannes.thumshirn@men.de>
Reviewed-by: Peter Hurley <peter@hurleysoftware.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
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: Peter Hurley <peter@hurleysoftware.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
BRKINT and ISIG requires input and output flush when a signal char
is received. However, the order of operations is significant since
parallel i/o may be ongoing.
Merge the signal handling for BRKINT with ISIG handling.
Process the signal first. This ensures any ongoing i/o is aborted;
without this, a waiting writer may continue writing after the flush
occurs and after the signal char has been echoed.
Write lock the termios_rwsem, which excludes parallel writers from
pushing new i/o until after the output buffers are flushed; claiming
the write lock is necessary anyway to exclude parallel readers while
the read buffer is flushed.
Subclass the termios_rwsem for ptys since the slave pty performing
the flush may appear to reorder the termios_rwsem->tty buffer lock
lock order; adding annotation clarifies that
slave tty_buffer lock-> slave termios_rwsem -> master tty_buffer lock
is a valid lock order.
Flush the echo buffer. In this context, the echo buffer is 'output'.
Otherwise, the output will appear discontinuous because the output buffer
was cleared which contains older output than the echo buffer.
Open-code the read buffer flush since the input worker does not need
kicking (this is the input worker).
Signed-off-by: Peter Hurley <peter@hurleysoftware.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The pty driver does not clear its write buffer when commanded.
This is to avoid an apparent deadlock between parallel flushes from
both pty ends; specifically when handling either BRK or INTR input.
However, parallel flushes from this source is not possible since
the pty master can never be set to BRKINT or ISIG. Parallel flushes
from other sources are possible but these do not threaten deadlocks.
Annotate the tty buffer mutex for lockdep to represent the nested
tty_buffer locking which occurs when the pty slave is processing input
(its buffer mutex held) and receives INTR or BRK and acquires the
linked tty buffer mutex via tty_buffer_flush().
Signed-off-by: Peter Hurley <peter@hurleysoftware.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Besides nested legacy_mutex locking which is required on pty pair
teardown, other nested pty operations require lock subclassing.
Move lock subclass definition to tty interface header, include/linux/tty.h,
and document its use.
Signed-off-by: Peter Hurley <peter@hurleysoftware.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
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>
If PARMRK is enabled, the available read buffer space computation is
overly-pessimistic, which results in severely throttled i/o, even
in the absence of parity errors. For example, if the 4k read buffer
contains 1k processed data, the input worker will compute available
space of 333 bytes, despite 3k being available. At 1365 chars of
processed data, 0 space available is computed.
*Divide remaining space* by 3, truncating down (if left == 2, left = 0).
Reported-by: Christian Riesch <christian.riesch@omicron.at>
Conflicts:
drivers/tty/n_tty.c
Signed-off-by: Peter Hurley <peter@hurleysoftware.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Add commit_head buffer index, which the producer-side publishes
after input processing in non-canon mode. This ensures the consumer-side
observes correctly-ordered writes in non-canonical mode (ie., the buffer
data is written before the buffer index is advanced). Fix consumer-side
uses of read_cnt() to use commit_head instead.
Add required memory barriers to the tail index to guarantee
the consumer-side has completed the loads before the producer-side
begins writing new data. Open-code the producer-side receive_room()
into the i/o loop.
Remove no-longer-referenced receive_room().
Based on work by Christian Riesch <christian.riesch@omicron.at>
Cc: Christian Riesch <christian.riesch@omicron.at>
Signed-off-by: Peter Hurley <peter@hurleysoftware.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The adjustments performed by receive_room() are to ensure a line
termination can always be written to the read buffer. However,
these adjustments are irrelevant to the throttle threshold (because
the threshold < buffer limit).
Signed-off-by: Peter Hurley <peter@hurleysoftware.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The tty driver will be mistakenly throttled if a line termination
has not been received, and the line exceeds 3967 chars. Thus, it is
possible for the driver to stop sending when it has not yet sent
the newline. This does not apply to the pty driver.
Don't throttle until at least one line termination has been
received.
Signed-off-by: Peter Hurley <peter@hurleysoftware.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The input worker never reschedules itself; it only processes input until
either there is no more input or the read buffer is full. So the reader
is responsible for restarting the input worker only if the read buffer
was previously full (no_room == 1) _and_ space is now available to process
more input because the reader has consumed data from the read buffer.
However, computing the actual space available is not required to determine
if the reader has consumed data from the read buffer. This condition is
evaluated in 5 situations, each of which the space avail is already known:
1. n_tty_flush_buffer() - the read buffer is empty; kick the worker
2. n_tty_set_termios() - no data has been consumed; do not kick the worker
(although it may have kicked the reader so data _will be_ consumed)
3. n_tty_check_unthrottle - avail space > 3968; kick the worker
4. n_tty_read, before leaving - only kick the worker if the reader has
moved the tail. This prevents unnecessarily kicking the worker
when timeout-style reading is used.
5. n_tty_read, before sleeping - although it is possible for the read
buffer to be full and input_available_p() to be false, this can
only happen when the input worker is racing the reader, in which
case the reader will have been woken and won't sleep.
Rename n_tty_set_room() to n_tty_kick_worker() to reflect what the
function actually does.
Signed-off-by: Peter Hurley <peter@hurleysoftware.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This patch adds support for early console initialized from device tree
and kernel command line to all variants of Samsung serial driver.
Signed-off-by: Tomasz Figa <t.figa@samsung.com>
[mszyprow: added support for command line based initialization,
fixed comments, added documentation]
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Reviewed-by: Alim Akhtar <alim.akhtar@samsung.com>
Tested-by: Alim Akhtar <alim.akhtar@samsung.com>
Tested-by: Chanwoo Choi <cw00.choi@samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Since the driver cannot return from overrun error if characters
are output during overrun process, use dev_dbg() instead of
dev_notice() to log the error message of overrun in syslog.
Based on a patch by Hisashi Nakamura.
Signed-off-by: Yoshihiro Kaneko <ykaneko0929@gmail.com>
Acked-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
If we would like to send amount of data less than FIFO size we better would do
this via PIO mode. Otherwise the overhead could be significant.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Since we return in the first branch the second one doesn't require an
additional else keyword. The patch removes it.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
In order to make it possible to restore from hibernation not only in Linux but
also in e.g. U-Boot, we have to use sci_{suspend|remove}() for the PM {freeze|
thaw|restore}() methods. It's handy to achieve this by using SIMPLE_DEV_PM_OPS()
macro, however we have to annotate sci_{suspend|remove}() with '__maybe_unused'
in order to avoid compilation warnings when CONFIG_PM_SLEEP is undefined.
Based on orignal patch by Mikhail Ulyanov <mikhail.ulyanov@cogentembedded.com>.
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The pty_space() computation is broken; the space already consumed
in the tty buffer is not accounted for.
Use tty_buffer_set_limit(), which enforces the limit automatically.
Signed-off-by: Peter Hurley <peter@hurleysoftware.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The implementation of flushing the RX FIFO breaks in a number of cases,
it is impossible to ensure an complete flush of the RX FIFO due to the
hardware not allowing the use of the FIFOs when the receiver is disabled
(Reading from the FIFO register does not remove it from the FIFO when
the RX_EN=0 or RX_DIS=1). Additionally during an initial set_termios
call where RX_DIS=1 causes a hang waiting forever for the RX FIFO to
empty. On top of this the FIFO will be cleared by the use of the RXRST
bits on the Control Register, making the RX flush pointless (as it does
not preserve the data read anyway).
Due to the TXRST the TX FIFO and transmitter can be interrupted during
frame trasmission, causing corruption and additionally data lost in the
FIFO. Most other serial drivers do not flush or clear the FIFOs during
a termios configuration change and as such do not have issues with
corruption. For this UART controller is it required that the TXRST/RXRST
bit be flagged during the change, this means that the data in the FIFO
will be dropped when changing configuration. In order to prevent data
loss and corruption of the transmitted data, wait until the TX FIFO is
empty before changing the configuration. The performance of this may
cause the set_termios call to take a longer amount of time especially
on lower baud rates, however it is comparable to the same performance
hit that a console_write call costs.
Signed-off-by: Nathan Rossi <nathan.rossi@xilinx.com>
Acked-by: Anirudha Sarangi <anirudh@xilinx.com>
Acked-by: Harini Katakam <harinik@xilinx.com>
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Building an arm allmodconfig kernel triggers a lengthy but harmless
warning in the isicom driver:
drvers/tty/isicom.c: In function 'isicom_send_break':
uapi/linux/swab.h:13:15: warning: integer overflow in expression [-Woverflow]
(((__u16)(x) & (__u16)0x00ffU) << 8) | \
^
uapi/linux/swab.h:107:2: note: in expansion of macro '___constant_swab16'
___constant_swab16(x) : \
^
uapi/linux/byteorder/big_endian.h:34:43: note: in expansion of macro '__swab16'
#define __cpu_to_le16(x) ((__force __le16)__swab16((x)))
^
linux/byteorder/generic.h:89:21: note: in expansion of macro '__cpu_to_le16'
#define cpu_to_le16 __cpu_to_le16
^
include/asm/io.h:270:6: note: in expansion of macro 'cpu_to_le16'
cpu_to_le16(v),__io(p)); })
^
drivers/tty/isicom.c:1058:2: note: in expansion of macro 'outw'
outw((length & 0xff00), base);
^
Apparently, the problem is related to the fact that the value 0xff00,
when used as a 16-bit number, is negative and passed into bitwise
operands of the generic byte swapping code.
Marking the input argument as unsigned in both technically correct
and avoids the warning.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
There is no need to explicitly zero the 'ret' variable as it is properly
initialized in a few lines below as:
ret = serial_mxs_probe_dt(s, pdev);
Remove the unneeded zeroing of 'ret'.
Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
We should check whether platform_get_irq() failed, and in the case of error
this needs to be propagated.
Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The irq number is only used inside the probe function, so there is no need
to keep it in the private mxs_auart_port structure.
Use a local 'irq' variable for storing the irq number instead.
Also make its type of 'int' as platform_get_irq() may fail and return a
negative number.
Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The Digicolor USART hardware does not support detecting the BREAK condition.
This means that we can't support sysrq on this hardware. Remove all reference
to sysrq from the code.
This also fixes build when sysrq is disabled:
drivers/tty/serial/digicolor-usart.c: In function 'digicolor_uart_console_write':
drivers/tty/serial/digicolor-usart.c:407:33: error: 'struct uart_port' has no member named 'sysrq'
Reported-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Baruch Siach <baruch@tkos.co.il>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
When the kernel command line parameter, no_console_suspend, is used,
the console should continue to output console messages during and
after system suspend. For a serial console, the serial core ensures
that the device is not shutdown when no_console_suspend is specified.
However, the default operation of the pnp bus will disable and suspend
the device and no further output occurs.
When registering the 8250 port, if the serial device is a console
set the PNP_CONSOLE capability, which prevents device power-off
if consoles are not suspending.
Signed-off-by: Peter Hurley <peter@hurleysoftware.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
unregister_console() will be called from uart_remove_one_port() while
removing the platform driver. So not necessary to call it in driver
exit path.
Signed-off-by: Pramod Gurav <pramod.gurav@smartplayin.com>
Reviewed-by: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The change does following:
- baud, flow, bits, parity were being overwritten as they were
being reinitialized after parsing. Initialize them when they are
declared so that user provided setting are not overwritten.
- msm_set_baud_rate() is anyway called in uart_set_options when it calls
msm_set_termios(). msm_reset() is called when we change the baud rate.
Hence doing away with both of these calls.
- CR_CMD_PROTECTION_EN and CR_TX_ENABLE settings are done in msm_set_baud_rate.
So do away with this here.
Signed-off-by: Pramod Gurav <pramod.gurav@smartplayin.com>
Reviewed-by: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Intel Moorestown platform support was removed few years ago. This is a follow
up which removes Moorestown specific code for the serial devices. It includes
mrst_max3110 and earlyprintk bits.
This was used on SFI (Medfield, Clovertrail) based platforms as well, though
new ones use normal serial interface for the console service.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Acked-by: David Cohen <david.a.cohen@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
When running an userspace program that does a 'tcflush(fd, TCIOFLUSH)' call
we still see the last received character in the URXD register afterwards.
Clear UCR2_SRST bit so that the UART FIFO is flushed properly.
Since UCR2_SRST also resets some UART registers, we need to save and restore
some of them.
Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
Tested-by: Fugang Duan <B38611@freescale.com>
Acked-by: Jason Liu <r64343@freecale.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
