Users of RS-485 can request via ioctl that RTS signals should
be activated selected number of milliseconds before the actual
data transmission or delay reception certain number of milli-
seconds after the transmission is finished.  In sc16is7xx,
however, RTS signalling is handled by the hardware and driver
has no way of providing this feature.

We still try to provide .delay_rts_before_send by delaying
transmission but without actual effect on the RTS line.

Note: this change will make the driver return -EINVAL when the
      feature is requested (.delay_rts_after_send is set).
Signed-off-by: NJakub Kicinski <kubakici@wp.pl>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Updated the documentation for spi interface.
Signed-off-by: NRama Kiran Kumar Indrakanti <indrakanti_ram@hotmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

spi interface for sc16is7xx is added along with Kconfig flag
to enable spi or i2c, thus in a instance we can have either
spi or i2c or both, in sync to the hw.
Signed-off-by: NRama Kiran Kumar Indrakanti <indrakanti_ram@hotmail.com>
Signed-off-by: NJakub Kicinski <kubakici@wp.pl>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The header file, include/linux/serial_8250.h, contains references to
UART_LSR_BRK_ERROR_BITS and UART_MSR_ANY_DELTA that are defined in
<linux/serial_reg.h>.
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>

Commit 27a4c827 ("fbcon: use the cursor blink interval provided by
vt") unconditionally removes the cursor blink timer. Unfortunately that
wreaks havoc under some circumstances. An easily reproducible way is to
use both the framebuffer console and a debug serial port as the console
output for kernel messages (e.g. "console=ttyS0 console=tty1" on the
kernel command-line. Upon boot this triggers a warning from within the
del_timer_sync() function because it is called from IRQ context:

	[    5.070096] ------------[ cut here ]------------
	[    5.070110] WARNING: CPU: 0 PID: 0 at ../kernel/time/timer.c:1098 del_timer_sync+0x4c/0x54()
	[    5.070115] Modules linked in:
	[    5.070120] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.1.0-rc4-next-20150519 #1
	[    5.070123] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
	[    5.070142] [] (unwind_backtrace) from [] (show_stack+0x10/0x14)
	[    5.070156] [] (show_stack) from [] (dump_stack+0x70/0xbc)
	[    5.070164] [] (dump_stack) from [] (warn_slowpath_common+0x74/0xb0)
	[    5.070169] [] (warn_slowpath_common) from [] (warn_slowpath_null+0x1c/0x24)
	[    5.070174] [] (warn_slowpath_null) from [] (del_timer_sync+0x4c/0x54)
	[    5.070183] [] (del_timer_sync) from [] (fbcon_del_cursor_timer+0x2c/0x40)
	[    5.070190] [] (fbcon_del_cursor_timer) from [] (fbcon_cursor+0x9c/0x180)
	[    5.070198] [] (fbcon_cursor) from [] (hide_cursor+0x30/0x98)
	[    5.070204] [] (hide_cursor) from [] (vt_console_print+0x2a8/0x340)
	[    5.070212] [] (vt_console_print) from [] (call_console_drivers.constprop.23+0xc8/0xec)
	[    5.070218] [] (call_console_drivers.constprop.23) from [] (console_unlock+0x498/0x4f0)
	[    5.070223] [] (console_unlock) from [] (vprintk_emit+0x1f0/0x508)
	[    5.070228] [] (vprintk_emit) from [] (vprintk_default+0x24/0x2c)
	[    5.070234] [] (vprintk_default) from [] (printk+0x70/0x88)

After which the system starts spewing all kinds of weird and seemingly
unrelated error messages.

This commit fixes this by restoring the condition under which the call
to fbcon_del_cursor_timer() happens.
Reported-by: NDaniel Stone <daniel@fooishbar.org>
Reported-by: NKevin Hilman <khilman@kernel.org>
Tested-by: NKevin Hilman <khilman@linaro.org>
Tested-by: NScot Doyle <lkml14@scotdoyle.com>
Signed-off-by: NThierry Reding <treding@nvidia.com>
Tested-by: NAndrew Vagin <avagin@virtuozzo.com>
Tested-by: NTomeu Vizoso <tomeu.vizoso@collabora.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Add the necessary driver boilerplate to let the driver be used when
the respective ACPI table is discovered by the ACPI subsystem.

[Andre: change table name, add MODULE_DEVICE_TABLE entry and improve
	commit message]
Reviewed-by: NHanjun Guo <hanjun.guo@linaro.org>
Signed-off-by: NGraeme Gregory <graeme.gregory@linaro.org>
Tested-by: NMark Langsdorf <mlangsdo@redhat.com>
Tested-by: NNaresh Bhat <nbhat@cavium.com>
Signed-off-by: NAndre Przywara <andre.przywara@arm.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The ARM Server Base System Architecture[1] document describes a
generic UART which is a subset of the PL011 UART.
It lacks DMA support, baud rate control and modem status line
control, among other things.
The idea is to move the UART initialization and setup into the
firmware (which does this job today already) and let the kernel just
use the UART for sending and receiving characters.

We use the recent refactoring to build a new struct uart_ops
variable which points to some new functions avoiding access to the
missing registers. We reuse as much existing PL011 code as possible.

In contrast to the PL011 the SBSA UART does not define any AMBA or
PrimeCell relations, so we go with a pretty generic probe function
which only uses platform device functions.
A DT binding is provided with this patch, ACPI support is added in a
separate one.
Signed-off-by: NAndre Przywara <andre.przywara@arm.com>
Tested-by: NMark Langsdorf <mlangsdo@redhat.com>
Tested-by: NNaresh Bhat <nbhat@cavium.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The SBSA UART has a fixed baud rate and flow control setting, which
cannot be changed or queried by software.
Add a vendor specific property to always return fixed values when
trying to read the console options.
Signed-off-by: NAndre Przywara <andre.przywara@arm.com>
Tested-by: NMark Langsdorf <mlangsdo@redhat.com>
Tested-by: NNaresh Bhat <nbhat@cavium.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The SBSA UART should not be enabled or disabled (it is always on),
and consequently the spec lacks the UART_CR register.
Add a vendor specific property to skip disabling or enabling of the
UART. This will be used later by the SBSA UART support.
Signed-off-by: NAndre Przywara <andre.przywara@arm.com>
Tested-by: NMark Langsdorf <mlangsdo@redhat.com>
Tested-by: NNaresh Bhat <nbhat@cavium.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

To avoid lines with more than 80 characters and to make the
pl011_int() function more readable, move the workaround out into a
separate function.
Signed-off-by: NAndre Przywara <andre.przywara@arm.com>
Tested-by: NMark Langsdorf <mlangsdo@redhat.com>
Tested-by: NNaresh Bhat <nbhat@cavium.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The PL011 register UART_MIS is actually a bitwise AND of the
UART_RIS and the UART_MISC register.
Since the SBSA UART does not include the _MIS register, use the
two separate registers to get the same behaviour. Since we are
inside the spinlock and we read the _IMSC register only once, there
should be no race issue.
Signed-off-by: NAndre Przywara <andre.przywara@arm.com>
Tested-by: NMark Langsdorf <mlangsdo@redhat.com>
Tested-by: NNaresh Bhat <nbhat@cavium.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Currently the pl011_probe() function is relying on some AMBA IDs
and a device tree node to initialize the driver and a port.
Both features are not necessarily required for the driver:
- we lack AMBA IDs in the ARM SBSA generic UART and
- we lack a DT node in ACPI systems.
So lets refactor the function to ease later reuse.
Signed-off-by: NAndre Przywara <andre.przywara@arm.com>
Tested-by: NMark Langsdorf <mlangsdo@redhat.com>
Tested-by: NNaresh Bhat <nbhat@cavium.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Split the pl011_set_termios() function into smaller chunks to allow
easier reuse later when adding SBSA support.
Signed-off-by: NAndre Przywara <andre.przywara@arm.com>
Tested-by: NMark Langsdorf <mlangsdo@redhat.com>
Tested-by: NNaresh Bhat <nbhat@cavium.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Split the pl011_shutdown() function into smaller chunks to allow
easier reuse later when adding SBSA support.
Signed-off-by: NAndre Przywara <andre.przywara@arm.com>
Tested-by: NMark Langsdorf <mlangsdo@redhat.com>
Tested-by: NNaresh Bhat <nbhat@cavium.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Split the pl011_startup() function into smaller chunks to allow
easier reuse later when adding SBSA support.
Signed-off-by: NAndre Przywara <andre.przywara@arm.com>
Tested-by: NMark Langsdorf <mlangsdo@redhat.com>
Tested-by: NNaresh Bhat <nbhat@cavium.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Although we care about not unregistering the driver if there are
still ports connected during the .remove callback, we do miss this
check in the pl011_probe function. So if the current port allocation
fails, but there are other ports already registered, we will kill
those.
So factor out the port removal into a separate function and use that
in the probe function, too.
Signed-off-by: NAndre Przywara <andre.przywara@arm.com>
Tested-by: NMark Langsdorf <mlangsdo@redhat.com>
Tested-by: NNaresh Bhat <nbhat@cavium.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

If the mediatek serial port driver is built-in, but serial
console is disabled in Kconfig (e.g. when the serial driver
itself is a loadable module), we get this build error:

drivers/built-in.o: In function `early_mtk8250_setup':
undefined reference to `early_serial8250_setup'

To avoid that problem, this patch encloses the early_mtk8250_setup
function in #ifdef CONFIG_SERIAL_8250_CONSOLE, the same symbol
that guards the early_serial8250_setup function.
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Acked-by: NEddie Huang <eddie.huang@mediatek.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

A configuration that enables earlycon but not the core console
code causes a link error:

  drivers/built-in.o: In function `setup_earlycon':
  drivers/tty/serial/earlycon.c:70: undefined reference to `uart_parse_earlycon'

That error can be triggered by the newly added samsung earlycon support,
which is missing a 'select' statement.

As suggested by Peter Hurley, solves the problem by moving the
'select SERIAL_EARLYCON' statement to the samsung console driver
option, as it is done by all other console drivers.
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Fixes: b94ba032 ("serial: samsung: Add support for early console")
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The platform_sysrq_reset_seq code was intended as a way for an embedded
platform to provide its own sysrq sequence at compile time. After over
two years, nobody has started using it in an upstream kernel, and
the platforms that were interested in it have moved on to devicetree,
which can be used to configure the sequence without requiring kernel
changes. The method is also incompatible with the way that most
architectures build support for multiple platforms into a single
kernel.

Now the code is producing warnings when built with gcc-5.1:

drivers/tty/sysrq.c: In function 'sysrq_init':
drivers/tty/sysrq.c:959:33: warning: array subscript is above array bounds [-Warray-bounds]
   key = platform_sysrq_reset_seq[i];

We could fix this, but it seems unlikely that it will ever be used,
so let's just remove the code instead. We still have the option to
pass the sequence either in DT, using the kernel command line,
or using the /sys/module/sysrq/parameters/reset_seq file.
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Fixes: 154b7a48 ("Input: sysrq - allow specifying alternate reset sequence")
----
v2: moved sysrq_reset_downtime_ms variable to avoid introducing a compile
    warning when CONFIG_INPUT is disabled
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The function mctrl_gpio_init returns failure if the assignment to any
member of the gpio array results in an error pointer.  So there is no
need to check for such error values in the other functions.
Signed-off-by: NUwe Kleine-König <u.kleine-koenig@pengutronix.de>
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 DMA properties to all SCIF, SCIFA, SCIFB, and HSCIF device nodes.
Signed-off-by: NGeert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Add DMA properties to all SCIF, SCIFA, SCIFB, and HSCIF device nodes.
Signed-off-by: NGeert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Add DMA properties to all SCIF, SCIFA, SCIFB, and HSCIF device nodes.
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>

The currently in-use port->startup and port->shutdown are "okay". The
startup part for instance does the tiny omap extra part and invokes
serial8250_do_startup() for the remaining pieces. The workflow in
serial8250_do_startup() is okay except for the part where UART_RX is
read without a check if there is something to read. I tried to
workaround it in commit 0aa525d1 ("tty: serial: 8250_core: read only
RX if there is something in the FIFO") but then reverted it later in
commit ca8bb4ae ("serial: 8250: Revert "tty: serial: 8250_core: read
only RX if there is something in the FIFO"").

This is the second attempt to get it to work on older OMAPs without
breaking other chips this time
Peter Hurley suggested to pull in the few needed lines from
serial8250_do_startup() and drop everything else that is not required
including making it simpler like using just request_irq() instead the
chain handler like it is doing now.
So lets try that.

Fixes: ca8bb4ae ("serial: 8250: Revert "tty: serial: 8250_core:
       read only RX if there is something in the FIFO"")
Tested-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NSebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

If the call to dmaengine_slave_config() fails, then the DMA buffer will
not be freed/unmapped. Fix this by moving the code that stores the
address of the buffer in the tegra_uart_port structure to before the
call to dmaengine_slave_config().
Reported-by: NAlexandre Courbot <acourbot@nvidia.com>
Signed-off-by: NJon Hunter <jonathanh@nvidia.com>
Reviewed-by: NAlexandre Courbot <acourbot@nvidia.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

it seems this is a more typical behaviour from reviewing other console
drivers.
Signed-off-by: NQipan Li <Qipan.Li@csr.com>
Signed-off-by: NBarry Song <Baohua.Song@csr.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Signed-off-by: NQipan Li <Qipan.Li@csr.com>
Signed-off-by: NBarry Song <Baohua.Song@csr.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

add overrun error's flag mark and parity's counter, we can show the
statistic from procfs node.

BTW, let the indentation of stick bits configuration look better.
Signed-off-by: NQipan Li <Qipan.Li@csr.com>
Signed-off-by: NBarry Song <Baohua.Song@csr.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

In special condition, when cpu schedule into rx_tmo_process_tl or
rx_dma_complete_tl and all the receive dma tasks have done, it will
go into endless loop because no dma task cookie status be changed.
Signed-off-by: NQipan Li <Qipan.Li@csr.com>
Signed-off-by: NBarry Song <Baohua.Song@csr.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

>From HW spec, when rxfifo's data is less than AFC_RX_THD(RX threshhold), RTS
signal is active. otherwise, RTS signal is inactive.

Crrently the RX threshhold is set as zero, so RTS has no chance to be
active. This patch replaces the default 0 by a positive number.
Signed-off-by: NQipan Li <Qipan.Li@csr.com>
Signed-off-by: NBarry Song <Baohua.Song@csr.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

differentiate difference port types by re-defining the status MARCO
or putting HW differences into private data of the related ports.
Signed-off-by: NQipan Li <Qipan.Li@csr.com>
Signed-off-by: NBarry Song <Baohua.Song@csr.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This comment does not reflect the actual code.  It should be 57600,
not 56000.
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This comment does not reflect the actual code.  It should be 57600,
not 56000.
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

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 resolves some tty driver merge issues.
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Two watchdog changes that came through different trees had a non
conflicting conflict, that is, one changed the semantics of a variable
but no actual code conflict happened. So the merge appeared fine, but
the resulting code did not behave as expected.

Commit 195daf66 ("watchdog: enable the new user interface of the
watchdog mechanism") changes the semantics of watchdog_user_enabled,
which thereafter is only used by the functions introduced by
b3738d29 ("watchdog: Add watchdog enable/disable all functions").

There further appears to be a distinct lack of serialization between
setting and using watchdog_enabled, so perhaps we should wrap the
{en,dis}able_all() things in watchdog_proc_mutex.

This patch fixes a s2r failure reported by Michal; which I cannot
readily explain. But this does make the code internally consistent
again.
Reported-and-tested-by: NMichal Hocko <mhocko@suse.cz>
Signed-off-by: NPeter Zijlstra (Intel) <peterz@infradead.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>