In RS485 mode, we may want to set the delay_rts_after_send value to 0.
In the datasheet, the 0 value is said to "disable" the Transmitter Timeguard but
this is exactly the expected behavior if we want no delay...

Moreover, if the value was set to non-zero value by device-tree or earlier
ioctl command, it was impossible to change it back to zero.
Reported-by: NSami Pietikäinen <Sami.Pietikainen@wapice.com>
Signed-off-by: NNicolas Ferre <nicolas.ferre@atmel.com>
Cc: stable@vger.kernel.org  # 3.2+
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

In commit 02730d3c
(Merge 4.1-rc4 into tty-next), git mismerged some lines,
reintroducing a reference to the removed field
uart_amba_port.tx_irq_seen.  This causes a build failure.

This patch removes the mismerged lines, restoring the code to what
was in tty-next (which was the intention).
Signed-off-by: NDave Martin <Dave.Martin@arm.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This was introduced in

commit 6db4063c
Author: Antonino A. Daplas <adaplas@gmail.com>
Date:   Mon Jun 26 00:27:12 2006 -0700

    [PATCH] VT binding: Add sysfs control to the VT layer

with the justification

    "In addition, if any of the consoles are in KD_GRAPHICS mode, binding and
    unbinding will not succeed.  KD_GRAPHICS mode usually indicates that the
    underlying console hardware is used for other purposes other than displaying
    text (ie X).  This feature should prevent binding/unbinding from interfering
    with a graphics application using the VT."

I think we should lift this artificial restriction though:
- KD_GRAPHICS doesn't get cleaned up automatically, which means it's
  easy to have terminals stuck in KD_GRAPHICS when hacking around on
  X.
- X doesn't really care, especially with drm where kms already blocks
  fbdev (and hence fbcon) when there's an active compositor.
- This is a root-only interface with a separate .config option and
  it's possible to hang your machine already anyway if you
  unload/reload drivers and don't know what you're doing.

With this patch i915.ko module reloading works again reliably,
something in the recent fedora upgrades broke things.

Cc: Antonino A. Daplas <adaplas@gmail.com>
Cc: Peter Hurley <peter@hurleysoftware.com>
Cc: Imre Deak <imre.deak@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Acked-by: NDavid Herrmann <dh.herrmann@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Currently there is a lock order problem between the console lock and the
kernfs s_active lock of the console driver's bind sysfs entry. When
writing to the sysfs entry the lock order is first s_active then console
lock, when unregistering the console driver via
do_unregister_con_driver() the order is the opposite. See the below
bugzilla reference for one instance of a lockdep backtrace.

Fix this by unregistering the console driver from a deferred work, where
we can safely drop the console lock while unregistering the device and
corresponding sysfs entries (which in turn acquire s_active). Note that
we have to keep the console driver slot in the registered_con_driver
array reserved for the driver that's being unregistered until it's fully
removed. Otherwise a concurrent call to do_register_con_driver could
try to reuse the same slot and fail when registering the corresponding
device with a minor index that's still in use.

Note that the referenced bug report contains two dmesg logs with two
distinct lockdep reports: [1] is about a locking scenario involving
s_active, console_lock and the fb_notifier list lock, while [2] is
about a locking scenario involving only s_active and console_lock.
In [1] locking fb_notifier triggers the lockdep warning only because
of its dependence on console_lock, otherwise case [1] is the same
s_active<->console_lock dependency problem fixed by this patch.
Before this change we have the following locking scenarios involving
the 3 locks:

a) via do_unregister_framebuffer()->...->do_unregister_con_driver():
   1. console lock 2. fb_notifier lock 3. s_active lock
b) for example via give_up_console()->do_unregister_con_driver():
   1. console lock 2. s_active lock
c) via vt_bind()/vt_unbind():
   1. s_active lock 2. console lock

Since c) is the console bind sysfs entry's write code path we can't
change the locking order there. We can only fix this issue by removing
s_active's dependence on the other two locks in a) and b). We can do
this only in the vt code which owns the corresponding sysfs entry, so
that after the change we have:

a) 1. console lock 2. fb_notifier lock
b) 1. console lock
c) 1. s_active lock 2. console lock
d) in the new con_driver_unregister_callback():
   1. s_active lock

[1] https://bugs.freedesktop.org/attachment.cgi?id=87716
[2] https://bugs.freedesktop.org/attachment.cgi?id=107602

v2:
- get console_lock earlier in con_driver_unregister_callback(), so we
  protect the following console driver field assignments there
- add code coment explaining the reason for deferring the sysfs entry
  removal
- add a third paragraph to the commit message explaining why there are
  two distinct lockdep reports and that this issue is independent of
  fb/fbcon. (Peter Hurley)
v3:
- clarify further the third paragraph
v4:
- rebased on v4 of patch 1/3
Signed-off-by: NImre Deak <imre.deak@intel.com>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

A read() from a pty master may mistakenly indicate EOF (errno == -EIO)
after the pty slave has closed, even though input data remains to be read.
For example,

       pty slave       |        input worker        |    pty master
                       |                            |
                       |                            |   n_tty_read()
pty_write()            |                            |     input avail? no
  add data             |                            |     sleep
  schedule worker  --->|                            |     .
                       |---> flush_to_ldisc()       |     .
pty_close()            |       fill read buffer     |     .
  wait for worker      |       wakeup reader    --->|     .
                       |       read buffer full?    |---> input avail ? yes
                       |<---   yes - exit worker    |     copy 4096 bytes to user
  TTY_OTHER_CLOSED <---|                            |<--- kick worker
                       |                            |

		                **** New read() before worker starts ****

                       |                            |   n_tty_read()
                       |                            |     input avail? no
                       |                            |     TTY_OTHER_CLOSED? yes
                       |                            |     return -EIO

Several conditions are required to trigger this race:
1. the ldisc read buffer must become full so the input worker exits
2. the read() count parameter must be >= 4096 so the ldisc read buffer
   is empty
3. the subsequent read() occurs before the kicked worker has processed
   more input

However, the underlying cause of the race is that data is pipelined, while
tty state is not; ie., data already written by the pty slave end is not
yet visible to the pty master end, but state changes by the pty slave end
are visible to the pty master end immediately.

Pipeline the TTY_OTHER_CLOSED state through input worker to the reader.
1. Introduce TTY_OTHER_DONE which is set by the input worker when
   TTY_OTHER_CLOSED is set and either the input buffers are flushed or
   input processing has completed. Readers/polls are woken when
   TTY_OTHER_DONE is set.
2. Reader/poll checks TTY_OTHER_DONE instead of TTY_OTHER_CLOSED.
3. A new input worker is started from pty_close() after setting
   TTY_OTHER_CLOSED, which ensures the TTY_OTHER_DONE state will be
   set if the last input worker is already finished (or just about to
   exit).

Remove tty_flush_to_ldisc(); no in-tree callers.

Fixes: 52bce7f8 ("pty, n_tty: Simplify input processing on final close")
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=96311
BugLink: http://bugs.launchpad.net/bugs/1429756
Cc: <stable@vger.kernel.org> # 3.19+
Reported-by: NAndy Whitcroft <apw@canonical.com>
Reported-by: NH.J. Lu <hjl.tools@gmail.com>
Signed-off-by: NPeter Hurley <peter@hurleysoftware.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

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: NPan Xinhui <xinhuix.pan@intel.com>
Fixes: dfabf7ff
Cc: stable <stable@vger.kernel.org> # 3.14+
Acked-by: NJiri Slaby <jslaby@suse.cz>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The beat hvc driver is only used by celleb.
celleb has been dropped [1], so drop the drivers.

[1] http://patchwork.ozlabs.org/patch/451730/

CC: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
CC: Jiri Slaby <jslaby@suse.cz>
CC: Valentin Rothberg <valentinrothberg@gmail.com>
CC: mpe@ellerman.id.au
CC: linuxppc-dev@lists.ozlabs.org
Signed-off-by: NDaniel Axtens <dja@axtens.net>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The CONFIG_ prefix is reserved for Kconfig options in Make and CPP
syntax.  CONFIG_MAGIC is a file local CPP identifier so change the
prefix to apply to Kconfig's naming convention.
Signed-off-by: NValentin Rothberg <valentinrothberg@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This code is no longer used now that mach-msm has been removed.
Delete it.

Cc: David Brown <davidb@codeaurora.org>
Cc: Bryan Huntsman <bryanh@codeaurora.org>
Cc: Daniel Walker <dwalker@fifo99.com>
Signed-off-by: NStephen Boyd <sboyd@codeaurora.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Add an escape sequence to specify the current console's cursor blink
interval. The interval is specified as a number of milliseconds until
the next cursor display state toggle, from 50 to 65535. /proc/loadavg
did not show a difference with a one msec interval, but the lower
bound is set to 50 msecs since slower hardware wasn't tested.

Store the interval in the vc_data structure for later access by fbcon,
initializing the value to fbcon's current hardcoded value of 200 msecs.
Signed-off-by: NScot Doyle <lkml14@scotdoyle.com>
Acked-by: NPavel Machek <pavel@ucw.cz>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Function tegra_uart_dma_channel_allocate() does not check that
dma_map_single() mapped the DMA buffer correctly. Add a check for this
and appropriate error handling.

Furthermore, if dmaengine_slave_config() (called by
tegra_uart_dma_channel_allocate()) fails, then memory allocated/mapped
is not freed/unmapped. Therefore, call tegra_uart_dma_channel_free()
instead of just dma_release_channel() if  dmaengine_slave_config() fails.
Signed-off-by: NJon Hunter <jonathanh@nvidia.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

There are two issues in the shutdown path of the UARTs which are:
1. The function tegra_uart_shutdown() calls tegra_uart_flush_buffer()
   to stop DMA TX transfers. However, tegra_uart_flush_buffer() is
   called after the DMA channels have already been freed and so actually
   does nothing.
2. The function that frees the DMA channels
   (tegra_uart_dma_channel_free()), unmaps the dma buffer before
   freeing the DMA channel and does not ensure the DMA has been
   stopped.

Resolve this by fixing the code in tegra_uart_dma_channel_free() to
ensure the DMA is stopped, free the DMA channel and then unmap the DMA
buffer. Finally, remove the unnecessary call to tegra_uart_flush_buffer().
Signed-off-by: NJon Hunter <jonathanh@nvidia.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The DMA cookie for the RX channel is being used by the TX channel.
Therefore, fix driver to use the correct DMA cookie for the TX channel.
Signed-off-by: NJon Hunter <jonathanh@nvidia.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The function tty_insert_flip_string() takes an argument "size" which is
of type size_t. This is an unsigned type. Update the count,
rx_bytes_requested and tx_bytes_requested in the tegra serial driver to
be unsigned integers so that an unsigned type is passed to
tty_insert_flip_string().
Signed-off-by: NJon Hunter <jonathanh@nvidia.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The tegra serial driver has two paths through which receive data is
copied up to the tty layer. These are:
1. DMA completion callback
2. UART RX interrupt

A UART RX interrupt occurs for either RX_TIMEOUT (data has been sitting
in the Rx FIFO for more than 4 character times without being read
because there is not enough data to reach the trigger level), End of
Receive Data event (receiver detects that data stops coming in for more
than 4 character times) or a receive error.

In the RX interrupt path, the following happens ...
- All RX DMA transfers are stopped
- Any data in the DMA buffer and RX FIFO are copied up to the tty layer.
- DMA is restarted/primed for the RX path

In the DMA completion callback, the DMA buffer is copied up to the tty
layer but there is no check to see if the RX interrupt could have
occurred between the DMA interrupt firing the the DMA callback running.
Hence, if a RX interrupt was to occur shortly after the DMA completion
interrupt, it is possible that the RX interrupt path has already copied
the DMA buffer before the DMA callback has been called. Therefore, when
the DMA callback is called, if the DMA is already in-progress, then this
indicates that the UART RX interrupt has already occurred and there is
nothing to do in the DMA callback. This race condition can cause
duplicated data to be received.
Signed-off-by: NShardar Shariff Md <smohammed@nvidia.com>
[jonathanh@nvidia.com: Moved async_tx_ack() call to after check to see
 if DMA has completed because if the DMA is in progress we do not need
 to ACK yet. Changed the print from dev_info to dev_debug. Updated
 changelog to add more commentary on the race condition based upon
 feedback from author.]
Signed-off-by: NJon Hunter <jonathanh@nvidia.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

It is only necessary to read data from the dma buffer when the count
value is non-zero and hence, tegra_uart_copy_rx_to_tty() so only be
called when this is the case.

Although, this was being tested for in two places, there is a third
place where this was not tested. However, instead of adding another
if-statement prior to calling tegra_uart_copy_rx_to_tty(), move the test
inside the function.
Signed-off-by: NShardar Shariff Md <smohammed@nvidia.com>
[jonathanh@nvidia.com: Re-worked patch to move the check for the count
 value inside the function tegra_uart_copy_rx_to_tty(). Updated
 changelog with more commentary.]
Signed-off-by: NJon Hunter <jonathanh@nvidia.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

For all tegra devices (up to t210), there is a hardware issue that
requires software to wait for 3 UART clock periods after enabling
the TX fifo, otherwise data could be lost.
Signed-off-by: NJon Hunter <jonathanh@nvidia.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

For all tegra devices (up to t210), there is a hardware issue that
requires software to wait for 32 UART clock periods for the flush
to propagate otherwise TX data could be post. Add a helper function
to wait for N UART clock periods and update delay following FIFO
flush to be 32 UART clock cycles.
Signed-off-by: NJon Hunter <jonathanh@nvidia.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The port.type has already been set by of_platform_serial_setup()
called from a few lines above.
Setting it to the same value is redundant.
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The port.fifosize member has already been copied at 8 lines above.
Maybe the compiler optimization can clean it away, but just in case.
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: NPeter Hurley <peter@hurleysoftware.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Early console functions are only used during the early boot stage.
This change just saves a small amount of memory footprint.
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

When nr_uarts was set to 0 (via config or 8250_core.nr_uarts), we crash
early on x86 because serial8250_isa_init_ports dereferences base_ops
which remains NULL. In fact, there is nothing to do for all the callers
of serial8250_isa_init_ports if there are no uarts.

Based on suggestions by Peter Hurley.
Signed-off-by: NJan Kiszka <jan.kiszka@siemens.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The platform_device_id is not modified by the driver and core uses it as
const.
Signed-off-by: NKrzysztof Kozlowski <k.kozlowski.k@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Staticize symbols not exported and not used outside of file.
Signed-off-by: NKrzysztof Kozlowski <k.kozlowski.k@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The platform_device_id is not modified by the driver and core uses it as
const.
Signed-off-by: NKrzysztof Kozlowski <k.kozlowski.k@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The platform_device_id is not modified by the driver and core uses it as
const.
Signed-off-by: NKrzysztof Kozlowski <k.kozlowski.k@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The code it refers to was removed in commit b545e4f4 ("serial:
sh-sci: Compute overrun_bit without using baud rate algo").
Signed-off-by: NGeert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

error_mask is the union of all error indicating bits in the SCxSR
register, while overrun_mask may apply to a different register (SCLSR),
depending on the SCI variant.

Hence overrun_mask should only be ORed into error_mask if it applies to
the SCxSR register.
Signed-off-by: NGeert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The various SCI implementations use 3 different methods to signal
overrun errors:
  - Bit SCI_ORER in register SCxSR on SCI,
  - Bit SCIFA_ORER in register SCxSR on SCIFA and SCIFB, and SCIF on
    SH7705/SH7720/SH7721,
  - Bit SCLSR_ORER in (optional!) register SCLSR on (H)SCIF.

However:
  1. sci_handle_fifo_overrun()
       a. handles (H)SCIF and SCIFA/SCIFB only,
       b. treats SCIF on SH7705/SH7720/SH7721 incorrectly,
  2. sci_mpxed_interrupt()
       a. treats SCIF on SH7705/SH7720/SH7721 incorrectly,
       b. ignores that not all SCIFs have the SCLSR register, causing
	  "Invalid register access" WARN()ings.

To fix the above:
  1. Determine and store the correct register enum during
     initialization,
  2. Replace the duplicated buggy switch statements by using the stored
     register enum,
  3. Add the missing existence check to  sci_mpxed_interrupt().
Signed-off-by: NGeert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Add the missing overrun bit definition for (H)SCIF.
Replace overrun_bit by overrun_mask, so we can use the existing
defines instead of hardcoded values.
Signed-off-by: NGeert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Add the missing overrun error bit in SCxSR on SCIFA/SCIFB and SCIF on
SH7705/SH7720/SH7721.
Document what the corresponding bit(s) on plain SCIF are used for.
Sort the components of SCIF_DEFAULT_ERROR_MASK by reverse definition
order.

Replace the hardcoded values in the SCxSR_*_CLEAR macros by proper
defines. Use bit masks (negations of sets of bits) to make it more
obvious which bits are being cleared.

Assembler output (on sh) was compared before and after this commit:
  - For the first branch of the big "#if defined(...) || ..." construct,
    the code has changed slightly, as 32-bit bitmasks can be loaded in a
    single instruction, unlike the old large 16-bit constants (the SCxSR
    register is 16 bit, so we don't care about the top 16 bits),
  - For the second branch, the generated code is identical.
Signed-off-by: NGeert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Signed-off-by: NGeert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Signed-off-by: NGeert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Add the register definitions for the Serial Port Control and Data
Registers on SCIFA/SCIFB, which are needed for RTS/CTS pin control.

Extracted from patches by Magnus Damm <damm+renesas@opensource.se>.
Signed-off-by: NGeert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Add the missing register bit definitions to set the RTS pin and read the
CTS pin on (H)SCIF.

Extracted from patches by Magnus Damm <damm+renesas@opensource.se>.
Signed-off-by: NGeert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Move private register definitions and enums from the public
<linux/serial_sci.h> header file to the driver private "sh-sci.h" header
file.

The common Serial Control Register definitions are left in the public
header file, as they're needed to fill in plat_sci_port.scscr on legacy
systems not using DT.
Signed-off-by: NGeert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

We should not be doing assignments within an if () block
so fix up the code to not do this.

change was created using Coccinelle.

CC: Jiri Slaby <jslaby@suse.cz>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

We should not be doing assignments within an if () block
so fix up the code to not do this.

change was created using Coccinelle.

CC: Jiri Slaby <jslaby@suse.cz>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

We should not be doing assignments within an if () block
so fix up the code to not do this.

change was created using Coccinelle.

CC: Jiri Slaby <jslaby@suse.cz>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

We should not be doing assignments within an if () block
so fix up the code to not do this.

change was created using Coccinelle.

CC: Jiri Slaby <jslaby@suse.cz>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>