This commit needs to be reverted because it prevents people from
using the serial console as a secondary console with input being
directed to tty0.

IOW, if you boot with console=ttyS0 console=tty0 then all kernels
prior to this commit will produce output on both ttyS0 and tty0
but input will only be taken from tty0.  With this patch the serial
console will always be the primary console instead of tty0,
potentially preventing people from getting into their machines in
emergency situations.

Fixes: d03516df ("tty: serial: 8250: add CON_CONSDEV to flags")
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

When in RS485 emulation mode, __do_stop_tx_rs485() calls
serial8250_clear_fifos().  This not only clears the FIFOs, but also sets
all bits in their control register (UART_FCR) to 0.

One of the effects of this is the disabling of the FIFOs, which turns
them into single-byte holding registers.  The rest of the driver doesn't
know this, which results in the lions share of characters passed into a
write call to be dropped.

(I can supply logic analyzer screenshots if necessary)

This fix replaces the serial8250_clear_fifos() call to
serial8250_clear_and_reinit_fifos() - this prevents the "dropped
characters" issue from manifesting again while retaining the requirement
of clearing the RX FIFO after transmission if the SER_RS485_RX_DURING_TX
flag is disabled.
Signed-off-by: NDaniel Jedrychowski <avistel@gmail.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Commit f209fa03 ("serial: 8250_pci: Detach low-level driver during
PCI error recovery") introduces a potential use-after-free in case the
pciserial_init_ports call in serial8250_io_resume fails, which may
happen if a memory allocation fails or if the .init quirk failed for
whatever reason).  If this happen, further pci_get_drvdata will return a
pointer to freed memory.

This patch reworks the PCI recovery resume hook to restore the old priv
structure in this case, which should be ok, since the ports were already
detached. Such error during recovery causes us to give up on the
recovery.

Fixes: f209fa03 ("serial: 8250_pci: Detach low-level driver during
  PCI error recovery")
Reported-by: NMichal Suchanek <msuchanek@suse.com>
Signed-off-by: NGabriel Krisman Bertazi <krisman@linux.vnet.ibm.com>
Signed-off-by: NGuilherme G. Piccoli <gpiccoli@linux.vnet.ibm.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

When using RS485 in half duplex, RX should be enabled when TX is
finished, and stopped when TX starts.

Before commit 0058f087 ("tty/serial: atmel: fix RS485 half
duplex with DMA"), RX was not disabled in atmel_start_tx() if the DMA
was used. So, collisions could happened.

But disabling RX in atmel_start_tx() uncovered another bug:
RX was enabled again in the wrong place (in atmel_tx_dma) instead of
being enabled when TX is finished (in atmel_complete_tx_dma), so the
transmission simply stopped.

This bug was not triggered before commit 0058f087
("tty/serial: atmel: fix RS485 half duplex with DMA") because RX was
never disabled before.

Moving atmel_start_rx() in atmel_complete_tx_dma() corrects the problem.

Cc: stable@vger.kernel.org
Reported-by: NGil Weber <webergil@gmail.com>
Fixes: 0058f087Tested-by: NGil Weber <webergil@gmail.com>
Signed-off-by: NRichard Genoud <richard.genoud@gmail.com>
Acked-by: NAlexandre Belloni <alexandre.belloni@free-electrons.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

If we don't disable the transmitter in atmel_stop_tx, the DMA buffer
continues to send data until it is emptied.
This cause problems with the flow control (CTS is asserted and data are
still sent).

So, disabling the transmitter in atmel_stop_tx is a sane thing to do.

Tested on at91sam9g35-cm(DMA)
Tested for regressions on sama5d2-xplained(Fifo) and at91sam9g20ek(PDC)

Cc: <stable@vger.kernel.org> (beware, this won't apply before 4.3)
Signed-off-by: NRichard Genoud <richard.genoud@gmail.com>
Acked-by: NNicolas Ferre <nicolas.ferre@atmel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This was entirely automated, using the script by Al:

  PATT='^[[:blank:]]*#[[:blank:]]*include[[:blank:]]*<asm/uaccess.h>'
  sed -i -e "s!$PATT!#include <linux/uaccess.h>!" \
        $(git grep -l "$PATT"|grep -v ^include/linux/uaccess.h)

to do the replacement at the end of the merge window.
Requested-by: NAl Viro <viro@zeniv.linux.org.uk>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Fix the following Calltrace:
[   77.768221] WARNING: CPU: 5 PID: 645 at drivers/dma/dmaengine.c:1069 dma_async_device_unregister+0xe2/0xf0
[   77.775058] dma_async_device_unregister called while 1 clients hold a reference
[   77.825048] CPU: 5 PID: 645 Comm: sh Not tainted 4.8.8-WR9.0.0.0_standard+ #3
[   77.832550] Hardware name: Intel Corp. Aspen Cove/Server, BIOS HAVLCRB1.X64.0012.D58.1604140405 04/14/2016
[   77.840396]  0000000000000000 ffffc90008adbc80 ffffffff81403456 ffffc90008adbcd0
[   77.848245]  0000000000000000 ffffc90008adbcc0 ffffffff8105e2e1 0000042d08adbf20
[   77.855934]  ffff88046a861c18 ffff88046a85c420 ffffffff820d4200 ffff88046ae92318
[   77.863601] Call Trace:
[   77.871113]  [<ffffffff81403456>] dump_stack+0x4f/0x69
[   77.878655]  [<ffffffff8105e2e1>] __warn+0xd1/0xf0
[   77.886102]  [<ffffffff8105e34f>] warn_slowpath_fmt+0x4f/0x60
[   77.893508]  [<ffffffff814187a9>] ? find_next_bit+0x19/0x20
[   77.900730]  [<ffffffff814bf83e>] ? dma_channel_rebalance+0x23e/0x270
[   77.907814]  [<ffffffff814bfee2>] dma_async_device_unregister+0xe2/0xf0
[   77.914992]  [<ffffffff814c53aa>] hsu_dma_remove+0x1a/0x60
[   77.921977]  [<ffffffff814ee14c>] dnv_exit+0x1c/0x20
[   77.928752]  [<ffffffff814edff6>] mid8250_remove+0x26/0x40
[   77.935607]  [<ffffffff8144f1b9>] pci_device_remove+0x39/0xc0
[   77.942292]  [<ffffffff8160cfea>] __device_release_driver+0x9a/0x140
[   77.948836]  [<ffffffff8160d0b3>] device_release_driver+0x23/0x30
[   77.955364]  [<ffffffff81447dcc>] pci_stop_bus_device+0x8c/0xa0
[   77.961769]  [<ffffffff81447f0a>] pci_stop_and_remove_bus_device_locked+0x1a/0x30
[   77.968113]  [<ffffffff81450d4e>] remove_store+0x5e/0x70
[   77.974267]  [<ffffffff81607ed8>] dev_attr_store+0x18/0x30
[   77.980243]  [<ffffffff8123006a>] sysfs_kf_write+0x3a/0x50
[   77.986180]  [<ffffffff8122f5ab>] kernfs_fop_write+0x10b/0x190
[   77.992118]  [<ffffffff811bf1c8>] __vfs_write+0x18/0x40
[   77.998032]  [<ffffffff811bfdee>] vfs_write+0xae/0x190
[   78.003747]  [<ffffffff811c1016>] SyS_write+0x46/0xb0
[   78.009234]  [<ffffffff81a4c31b>] entry_SYSCALL_64_fastpath+0x13/0x8f
[   78.014809] ---[ end trace 0c36dd73b7408eb2 ]---

This happens when the 8250 serial controller is hotplugged as follows:
echo 1 > /sys/bus/pci/devices/0000:00:1a.0/remove

This trace happens due to the serial port still holding a reference when
the dma device is unregistered.
The dma unregister routine will check if there is still a reference exist,
if so it will give the WARNING(here serial port still was not unregister).

To fix this, We need to unregister the serial port first, then do DMA
device unregister to make sure there is no reference when to DMA routine.
Signed-off-by: NLiwei Song <liwei.song@windriver.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Several versions of DW DMAC have multi block transfers hardware
support. Hardware support of multi block transfers is disabled
by default if we use DT to configure DMAC and software emulation
of multi block transfers used instead.
Add multi-block property, so it is possible to enable hardware
multi block transfers (if present) via DT.

Switch from per device is_nollp variable to multi_block array
to be able enable/disable multi block transfers separately per
channel.
Acked-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: NEugeniy Paltsev <Eugeniy.Paltsev@synopsys.com>
Signed-off-by: NVinod Koul <vinod.koul@intel.com>

During a PCI error recovery, like the ones provoked by EEH in the ppc64
platform, all IO to the device must be blocked while the recovery is
completed.  Current 8250_pci implementation only suspends the port
instead of detaching it, which doesn't prevent incoming accesses like
TIOCMGET and TIOCMSET calls from reaching the device.  Those end up
racing with the EEH recovery, crashing it.  Similar races were also
observed when opening the device and when shutting it down during
recovery.

This patch implements a more robust IO blockage for the 8250_pci
recovery by unregistering the port at the beginning of the procedure and
re-adding it afterwards.  Since the port is detached from the uart
layer, we can be sure that no request will make through to the device
during recovery.  This is similar to the solution used by the JSM serial
driver.

I thank Peter Hurley <peter@hurleysoftware.com> for valuable input on
this one over one year ago.
Signed-off-by: NGabriel Krisman Bertazi <krisman@linux.vnet.ibm.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

There is no need to check port for NULL in uart_port_deref() since we call it
only when port is defined.

There are few places that violate this. Fix them here as well.
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The mxs-auart driver does not count FIFO overrun errors. These errors never
appear in /proc/tty/driver/ttyAPP. This is because the OERR status bit is
masked by read_status_mask in the rx interrupt function, but the
AUART_STAT_OERR bit is never set in read_status_mask. The patch enables the
counting of overrun errors.
Signed-off-by: NWolfgang Ocker <weo@reccoware.de>
Reviewed-by: NFabio Estevam <fabio.estevam@nxp.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Add a set_ldisc function to enable/disable IrDA SIR mode according to
the new line discipline, if IrDA SIR mode is supported by the hardware
configuration.
Signed-off-by: NEd Blake <ed.blake@imgtec.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Expose set_ldisc() function so that it can be overridden with a
platform specific implementation.
Signed-off-by: NEd Blake <ed.blake@imgtec.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Add an IrDA UART capability flag and change the type of
uart_8250_port.capabilities to be u32 rather than unsigned short to
accommodate the additional flag.
Signed-off-by: NEd Blake <ed.blake@imgtec.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

When any 8250 based driver sets up DMA and has UART_CAP_RPM capability enabled
the device is left powered on after transfer is done. We need to schedule a
device suspend operation when DMA completes the transfer.

The patch is based on the work done by the reporter.
Reported-by: NHuiquan Zhong <huiquan.zhong@intel.com>
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The following fix of runtime PM use in DMA mode requires at least
serial8250_rpm_put_tx() to be available. Export both calls.
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

When su_probe() fails it doesn't free *up and we may have a memory
leak. Fix this by freeing *up before return.
Signed-off-by: NSouptick joarder <jrdr.linux@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

In each call to hv_remove(), con_read_page and con_write_page is not
getting freed and lead to memory leakage. Fix this by freeing both
pointers in hv_remove().
Signed-off-by: NSouptick joarder <jrdr.linux@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Declare an OF early console for SBSA UART so that the early console device
can be specified via the "stdout-path" property in device-tree.

Cc: Russell King <linux@armlinux.org.uk>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NKefeng Wang <wangkefeng.wang@huawei.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The STM32 serial port is SoC specific so no point enabling it
without the architecture enabled.
Signed-off-by: NPeter Robinson <pbrobinson@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

When spi_setup() fails it doesn't free ifx_dev and we have a memory
leak. Fix this by freeing ifx_dev before the return.
Signed-off-by: NSouptick joarder <jrdr.linux@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Inside ioc4_attach_local() 4 memory was allocated using kzalloc and
assign it to ports[] within loop. When kzalloc fails inside loop,
it returns error without freeing previously allocated memory and we
may have memory leak. Fix this by freeing ports[] before return.
Signed-off-by: NSouptick joarder <jrdr.linux@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The fresh new serial driver for pxa produces warnings when
CONFIG_PM_SLEEP is disabled:

drivers/tty/serial/8250/8250_pxa.c:50:12: error: 'serial_pxa_resume' defined but not used [-Werror=unused-function]
drivers/tty/serial/8250/8250_pxa.c:41:12: error: 'serial_pxa_suspend' defined but not used [-Werror=unused-function]

This removes the #ifdef around the two functions and instead marks both
as __maybe_unused, which is more robust and avoids the warning.

Fixes: ab28f51c ("serial: rewrite pxa2xx-uart to use 8250_core")
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Acked-by: NRobert Jarzmik <robert.jarzmik@free.fr>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

An otherwise very nice cleanup of the pxa2xx uart support marked the
init function of this driver as __deprecated:

drivers/tty/serial/pxa.c:944:1: error: 'serial_pxa_init' is deprecated [-Werror=deprecated-declarations]

This seems unhelpful to me, as we now warn for every allmodconfig build,
which is otherwise free of warnings on most architectures. Let's
remove the annotation again.

Fixes: ab28f51c ("serial: rewrite pxa2xx-uart to use 8250_core")
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Drop invalid user-pointer check from TIOCGSERIAL handler.

A NULL-pointer can be valid in user space and copy_to_user() takes care
of sanity checking.

Cc: Mikael Starvik <starvik@axis.com>
Cc: linux-cris-kernel@axis.com
Signed-off-by: NJohan Hovold <johan@kernel.org>
Acked-by: NJesper Nilsson <jesper.nilsson@axis.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Hi,
below patch to fix Fourth port offset of Percom PI7C9X7954 boards.

I had a problem using Fourth port on a pci express serial board based on Pericom
PI7C9X7954. Reading datasheet I notice a "special" offset assign to this port
when used in I/O mode.

Offset 0x0 ->  UART 0
Offset 0x8 ->  UART 1
Offset 0x10 ->  UART 2
Offset 0x38 ->  UART 3  <<---- This don't follow a logical sequence

This patch add a different init to last port, to have right offset.

I check also Pericom 7952 and 7958 but that devices follow logical sequence,
so they are ok.

Regards,
Angelo
Signed-off-by: NAngelo Butti <buttiangelo@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

While spin is already locked, serial output request causes the deadlock,
because serial output process also tries to lock the spin.
This patch removes serial output with spin locked.
Signed-off-by: NTakatoshi Akiyama <takatoshi.akiyama.kj@ps.hitachi-solutions.com>
Signed-off-by: NTakeshi Kihara <takeshi.kihara.df@renesas.com>
Signed-off-by: NSimon Horman <horms+renesas@verge.net.au>
Reviewed-by: NGeert Uytterhoeven <geert+renesas@glider.be>
Acked-by: NWolfram Sang <wsa+renesas@sang-engineering.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The Kconfig currently controlling compilation of this code is:

arch/cris/arch-v10/drivers/Kconfig:config ETRAX_SERIAL
arch/cris/arch-v10/drivers/Kconfig:     bool "Serial-port support"

...meaning that it currently is not being built as a module by anyone.

Lets remove the couple traces of modular infrastructure use, so that
when reading the driver there is no doubt it is builtin-only.

Since module_init translates to device_initcall in the non-modular
case, the init ordering remains unchanged with this commit.

We don't replace module.h with init.h since the file already has that.

Cc: Mikael Starvik <starvik@axis.com>
Cc: Jesper Nilsson <jesper.nilsson@axis.com>
Cc: Jiri Slaby <jslaby@suse.com>
Cc: linux-cris-kernel@axis.com
Cc: linux-serial@vger.kernel.org
Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The newly added pxa glue driver for 8250 supports console output, but
fails to build if the 8250 console is disabled:

drivers/tty/serial/8250/8250_pxa.o: In function `early_serial_pxa_setup':
8250_pxa.c:(.init.text+0x50): undefined reference to `early_serial8250_setup'

This adds an #ifdef like the other glue drivers have it.
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Acked-by: NRobert Jarzmik <robert.jarzmik@free.fr>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The hardware book says, the FCR is combined with a register called
CHAR (it will trigger interrupt when a specific character is
received).  At first, I used lock/read/modify/write/unlock dance for
the FCR to not affect the upper bits, but the CHAR is actually never
used.  It should not hurt to always clear the CHAR and to handle the
FCR as a normal case.  It can save the costly locking.
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
Suggested-by: NDenys Vlasenko <dvlasenk@redhat.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

For this driver, uart_port::regshift is always 2.  Hardcode the
shift value instead of reading ->regshift to get an already known
value.  (pointed out by Denys Vlasenko)

Furthermore, I am using register macros that are already shifted,
which will save code a bit.
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The Kconfig currently controlling compilation of this code is:

arch/cris/arch-v10/drivers/Kconfig:config ETRAX_SERIAL
arch/cris/arch-v10/drivers/Kconfig:     bool "Serial-port support"

...meaning that it currently is not being built as a module by anyone.

Lets remove the couple traces of modular infrastructure use, so that
when reading the driver there is no doubt it is builtin-only.

Since module_init translates to device_initcall in the non-modular
case, the init ordering remains unchanged with this commit.

We don't replace module.h with init.h since the file already has that.

Cc: Mikael Starvik <starvik@axis.com>
Cc: Jesper Nilsson <jesper.nilsson@axis.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Jiri Slaby <jslaby@suse.com>
Cc: linux-cris-kernel@axis.com
Cc: linux-serial@vger.kernel.org
Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: NJesper Nilsson <jespern@axis.com>

Since commit 761ed4a9 ("tty: serial_core: convert uart_close to
use tty_port_close"), the serial console is broken on various systems
and typing "reboot" splats the following on the serial console:

INIT: Sending p[  427.863916] BUG: unable to handle kernel NULL pointer dereference at 00000000000001e0
[  427.885156] IP: [] tty_wakeup+0xc/0x70
[  427.898337] PGD 0 [  427.902051]
[  427.907498] Oops: 0000 [#1] PREEMPT SMP
[  427.917635] Modules linked in: nfsv3 nfs_acl nfs fscache lockd
sunrpc grace edd af_packet cpufreq_conservative cpufreq_userspace
cpufreq_powersave fuse loop md_mod dm_mod joydev hid_generic usbhid
ipmi_ssif ohci_pci ohci_hcd ehci_pci ehci_hcd e1000e ptp firewire_ohci
edac_core pps_core tpm_infineon sp5100_tco firewire_core acpi_cpufreq
serio_raw pcspkr fjes usbcore shpchp edac_mce_amd tpm_tis ipmi_si
tpm_tis_core i2c_piix4 k10temp sg ipmi_msghandler tpm sr_mod button
cdrom kvm_amd kvm irqbypass crc_itu_t ast ttm drm_kms_helper drm
fb_sys_fops sysimgblt sysfillrect syscopyarea i2c_algo_bit scsi_dh_rdac
scsi_dh_alua scsi_dh_emc scsi_dh_hp_sw ata_generic pata_atiixp
[  428.054179] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.9.0-rc1-1.g73e3f23-default #1
[  428.072868] Hardware name: System manufacturer System Product Name/KGP(M)E-D16, BIOS 0902    12/03/2010
[  428.094755] task: ffffffffa2c0d500 task.stack: ffffffffa2c00000
[  428.109717] RIP: 0010:[]  [] tty_wakeup+0xc/0x70
[  428.128407] RSP: 0018:ffff9a1a5fc03df8  EFLAGS: 00010086
[  428.142184] RAX: ffff9a1857258000 RBX: ffffffffa3050ea0 RCX: 0000000000000000
[  428.159649] RDX: 000000000000001b RSI: 0000000000000000 RDI: 0000000000000000
[  428.177109] RBP: ffff9a1a5fc03e08 R08: 0000000000000000 R09: 0000000000000000
[  428.194547] R10: 0000000000021c77 R11: 0000000000000000 R12: ffff9a1857258000
[  428.212002] R13: 0000000000000000 R14: 0000000000000020 R15: 0000000000000020
[  428.229481] FS:  0000000000000000(0000) GS:ffff9a1a5fc00000(0000) knlGS:0000000000000000
[  428.248938] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[  428.263726] CR2: 00000000000001e0 CR3: 0000000390c06000 CR4: 00000000000006f0
[  428.281331] Stack:
[  428.288696]  ffffffffa3050ea0 ffff9a1857258000 ffff9a1a5fc03e18 ffffffffa24e0ab1
[  428.307064]  ffff9a1a5fc03e40 ffffffffa24e8865 ffffffffa3050ea0 00000000000000c2
[  428.325456]  0000000000000046 ffff9a1a5fc03e78 ffffffffa24e8a5f ffffffffa3050ea0
[  428.343905] Call Trace:
[  428.352319]   [  428.356216]  [] uart_write_wakeup+0x21/0x30

The problem is for console ports, the serial port is not shutdown and
interrupts may fire after the struct tty is gone. Simply calling the
tty_port helper tty_port_tty_wakeup instead of tty_wakeup directly will
ensure there is a valid struct tty.

Fixes: 761ed4a9 ("tty: serial_core: convert uart_close to use tty_port_close")
Reported-by: NBorislav Petkov <bp@alien8.de>
Reported-by: NMike Galbraith <mgalbraith@suse.de>
Cc: Jiri Slaby <jslaby@suse.cz>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: linux-serial@vger.kernel.org
Signed-off-by: NRob Herring <robh@kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The port->console flag is always false, as uart_console() is called
before the serial console has been registered.

Hence for a serial port used as the console, uart_tty_port_shutdown()
will still be called when userspace closes the port, powering it down.
This may lead to a system lock up when the serial console driver writes
to the serial port's registers.

To fix this, move the setting of port->console after the call to
uart_configure_port(), which registers the serial console.

Fixes: 761ed4a9 ("tty: serial_core: convert uart_close to use tty_port_close")
Reported-by: NNiklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
Signed-off-by: NGeert Uytterhoeven <geert+renesas@glider.be>
Acked-by: NRob Herring <robh@kernel.org>
Tested-by: NMugunthan V N <mugunthanvnm@ti.com>
Tested-by: NNiklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
[robh: rebased on tty-linus]
Signed-off-by: NRob Herring <robh@kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

After commit 1cf6e8fc ("tty/serial: at91: fix RTS line management
when hardware handshake is enabled"), the hardware handshake wasn't
functional anymore on Atmel platforms (beside SAMA5D2).

To understand why, one has to understand the flag ATMEL_US_USMODE_HWHS
first:
Before commit 1cf6e8fc ("tty/serial: at91: fix RTS line management
when hardware handshake is enabled"), this flag was never set.
Thus, the CTS/RTS where only handled by serial_core (and everything
worked just fine).

This commit introduced the use of the ATMEL_US_USMODE_HWHS flag,
enabling it for all boards when the user space enables flow control.

When the ATMEL_US_USMODE_HWHS is set, the Atmel USART controller
handles a part of the flow control job:
- disable the transmitter when the CTS pin gets high.
- drive the RTS pin high when the DMA buffer transfer is completed or
  PDC RX buffer full or RX FIFO is beyond threshold. (depending on the
  controller version).

NB: This feature is *not* mandatory for the flow control to work.
(Nevertheless, it's very useful if low latencies are needed.)

Now, the specifics of the ATMEL_US_USMODE_HWHS flag:

- For platforms with DMAC and no FIFOs (sam9x25, sam9x35, sama5D3,
sama5D4, sam9g15, sam9g25, sam9g35)* this feature simply doesn't work.
( source: https://lkml.org/lkml/2016/9/7/598 )
Tested it on sam9g35, the RTS pins always stays up, even when RXEN=1
or a new DMA transfer descriptor is set.
=> ATMEL_US_USMODE_HWHS must not be used for those platforms

- For platforms with a PDC (sam926{0,1,3}, sam9g10, sam9g20, sam9g45,
sam9g46)*, there's another kind of problem. Once the flag
ATMEL_US_USMODE_HWHS is set, the RTS pin can't be driven anymore via
RTSEN/RTSDIS in USART Control Register. The RTS pin can only be driven
by enabling/disabling the receiver or setting RCR=RNCR=0 in the PDC
(Receive (Next) Counter Register).
=> Doing this is beyond the scope of this patch and could add other
bugs, so the original (and working) behaviour should be set for those
platforms (meaning ATMEL_US_USMODE_HWHS flag should be unset).

- For platforms with a FIFO (sama5d2)*, the RTS pin is driven according
to the RX FIFO thresholds, and can be also driven by RTSEN/RTSDIS in
USART Control Register. No problem here.
(This was the use case of commit 1cf6e8fc ("tty/serial: at91: fix
RTS line management when hardware handshake is enabled"))
NB: If the CTS pin declared as a GPIO in the DTS, (for instance
cts-gpios = <&pioA PIN_PB31 GPIO_ACTIVE_LOW>), the transmitter will be
disabled.
=> ATMEL_US_USMODE_HWHS flag can be set for this platform ONLY IF the
CTS pin is not a GPIO.

So, the only case when ATMEL_US_USMODE_HWHS can be enabled is when
(atmel_use_fifo(port) &&
 !mctrl_gpio_to_gpiod(atmel_port->gpios, UART_GPIO_CTS))

Tested on all Atmel USART controller flavours:
AT91SAM9G35-CM (DMAC flavour), AT91SAM9G20-EK (PDC flavour),
SAMA5D2xplained (FIFO flavour).

* the list may not be exhaustive

Cc: <stable@vger.kernel.org> #4.4+ (beware, missing atmel_port variable)
Fixes: 1cf6e8fc ("tty/serial: at91: fix RTS line management when hardware handshake is enabled")
Signed-off-by: NRichard Genoud <richard.genoud@gmail.com>
Acked-by: NAlexandre Belloni <alexandre.belloni@free-electrons.com>
Acked-by: NCyrille Pitchen <cyrille.pitchen@atmel.com>
Acked-by: NUwe Kleine-König <u.kleine-koenig@pengutronix.de>
Acked-by: NNicolas Ferre <nicolas.ferre@atmel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2a41bc2a ("tty: serial: fsl_lpuart: add polled console
functions") caused a build warning about an unused variable, so fix it.
Reported-by: Nkbuild test robot <fengguang.wu@intel.com>
Cc: Nicolae Rosia <nicolae_rosia@mentor.com>
Cc: Stefan Golinschi <stefan.golinschi@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The regmap_update first reads the IOState register and then triggers
a write if needed. However, GPIOS might be configured as an input so
 the read to IOState on this GPIO is the current state which might
be random.
Signed-off-by: NFrancois Berder <Francois.Berder@imgtec.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

NXP SC16C2552 requires that we always write a reset to the RX FIFO and
TX FIFO whenever we enable the FIFOs

Cc: xe-kernel@external.cisco.com
Signed-off-by: NSteve Shih <sshih@cisco.com>
Signed-off-by: NDavid Singleton <davsingl@cisco.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

In the case where head == 0 on the circular buffer, there should be one
DMA buffer, not two.  The second zero-length buffer would break the
lpuart driver, transfer would never complete.
Signed-off-by: NAaron Brice <aaron.brice@datasoft.com>
Acked-by: NStefan Agner <stefan@agner.ch>
Tested-by: NStefan Agner <stefan@agner.ch>
Tested-by: NBhuvanchandra DV <bhuvanchandra.dv@toradex.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Fintek F81865 is a LPC to 6 UARTs SuperIO. It has less functional UARTs
likes F81866. It's also need check the IRQ mode with system assigned,
but the configuration is not the same with F81216 series.

F81865 IRQ Mode setting:
    0xf0
            Bit1: IRQ_MODE0
            Bit0: Share mode (always on)

    Level/Low: IRQ_MODE0:0
    Edge/High: IRQ_MODE0:1

The following list is brief descriptions of F81865:

F81865 (0704)
    9Bit(not implements with mainline)
    RS485(implemented)
Suggested-by: NRicardo Ribalda Delgado <ricardo.ribalda@gmail.com>
Signed-off-by: NJi-Ze Hong (Peter Hong) <hpeter+linux_kernel@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>