Use MCK_DIV8 when the clock divider is > 65535. Unfortunately the mode
register was already written thus the clock selection is ignored.

Fix by doing the baud rate calulation before setting the mode.

Fixes: 5bf5635a ("tty/serial: atmel: add fractional baud rate support")
Signed-off-by: NDavid Engraf <david.engraf@sysgo.com>
Acked-by: NLudovic Desroches <ludovic.desroches@microchip.com>
Acked-by: NRichard Genoud <richard.genoud@gmail.com>
Cc: stable <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20191216085403.17050-1-david.engraf@sysgo.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

There seems to be a race condition in tty drivers and I could see on
many boot cycles a NULL pointer dereference as tty_init_dev() tries to
do 'tty->port->itty = tty' even though tty->port is NULL.
'tty->port' will be set by the driver and if the driver has not yet done
it before we open the tty device we can get to this situation. By adding
some extra debug prints, I noticed that:

6.650130: uart_add_one_port
6.663849: register_console
6.664846: tty_open
6.674391: tty_init_dev
6.675456: tty_port_link_device

uart_add_one_port() registers the console, as soon as it registers, the
userspace tries to use it and that leads to tty_open() but
uart_add_one_port() has not yet done tty_port_link_device() and so
tty->port is not yet configured when control reaches tty_init_dev().

Further look into the code and tty_port_link_device() is done by
uart_add_one_port(). After registering the console uart_add_one_port()
will call tty_port_register_device_attr_serdev() and
tty_port_link_device() is called from this.

Call add tty_port_link_device() before uart_configure_port() is done and
add a check in tty_port_link_device() so that it only links the port if
it has not been done yet.
Suggested-by: NJiri Slaby <jslaby@suse.com>
Signed-off-by: NSudip Mukherjee <sudipm.mukherjee@gmail.com>
Cc: stable <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20191212131602.29504-1-sudipm.mukherjee@gmail.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

A break interrupt will be generated if the RX line was pulled low, which
means some abnomal behaviors occurred of the UART. In this case, we still
need to clear this break interrupt status, otherwise it will cause irq
storm to crash the whole system.

Fixes: b7396a38 ("tty/serial: Add Spreadtrum sc9836-uart driver support")
Signed-off-by: NYonghan Ye <yonghan.ye@unisoc.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: NBaolin Wang <baolin.wang7@gmail.com>
Link: https://lore.kernel.org/r/925e51b73099c90158e080b8f5bed9b3b38c4548.1575460601.git.baolin.wang7@gmail.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

As the commit 677fe555 ("serial: imx: Fix recursive locking bug")
has mentioned the uart driver might cause recursive locking between
normal printing and the kernel debugging facilities (e.g. sysrq and
oops).  In the commit it gave out suggestion for fixing recursive
locking issue: "The solution is to avoid locking in the sysrq case
and trylock in the oops_in_progress case."

This patch follows the suggestion (also used the exactly same code with
other serial drivers, e.g. amba-pl011.c) to fix the recursive locking
issue, this can avoid stuck caused by deadlock and print out log for
sysrq and oops.

Fixes: 04896a77 ("msm_serial: serial driver for MSM7K onboard serial peripheral.")
Signed-off-by: NLeo Yan <leo.yan@linaro.org>
Reviewed-by: NJeffrey Hugo <jeffrey.l.hugo@gmail.com>
Link: https://lore.kernel.org/r/20191127141544.4277-2-leo.yan@linaro.orgSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This reverts commit fdc2de87 ("serial/8250:
Add support for NI-Serial PXI/PXIe+485 devices").

The commit fdc2de87 ("serial/8250: Add support for NI-Serial
PXI/PXIe+485 devices") introduced a breakage on NI-Serial PXI(e)-RS485
devices, RS-232 variants have no issue. The Linux system can enumerate the
NI-Serial PXI(e)-RS485 devices, but it broke the R/W operation on the
ports.

However, the implementation is working on the NI internal Linux RT kernel
but it does not work in the Linux main tree kernel. This is only affecting
NI products, specifically the RS-485 variants. Reverting the upstream
until a proper implementation that can apply to both NI internal Linux
kernel and Linux mainline kernel is figured out.
Signed-off-by: NJe Yen Tam <je.yen.tam@ni.com>
Fixes: fdc2de87 ("serial/8250: Add support for NI-Serial PXI/PXIe+485 devices")
Cc: stable <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20191127075301.9866-1-je.yen.tam@ni.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Commit d21b0be2 ("vt: introduce unicode mode for /dev/vcs") guarded
against using devices containing attributes as this is not yet
implemented. It however failed to guard against writes to any devices
as this is also unimplemented.
Reported-by: NOr Cohen <orcohen@paloaltonetworks.com>
Signed-off-by: NNicolas Pitre <npitre@baylibre.com>
Cc: <stable@vger.kernel.org> # v4.19+
Cc: Jiri Slaby <jslaby@suse.com>
Fixes: d21b0be2 ("vt: introduce unicode mode for /dev/vcs")
Link: https://lore.kernel.org/r/nycvar.YSQ.7.76.1911051030580.30289@knanqh.ubzrSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Do not try to handle keycodes that are too big, otherwise we risk doing
out-of-bounds writes:

BUG: KASAN: global-out-of-bounds in clear_bit include/asm-generic/bitops-instrumented.h:56 [inline]
BUG: KASAN: global-out-of-bounds in kbd_keycode drivers/tty/vt/keyboard.c:1411 [inline]
BUG: KASAN: global-out-of-bounds in kbd_event+0xe6b/0x3790 drivers/tty/vt/keyboard.c:1495
Write of size 8 at addr ffffffff89a1b2d8 by task syz-executor108/1722
...
 kbd_keycode drivers/tty/vt/keyboard.c:1411 [inline]
 kbd_event+0xe6b/0x3790 drivers/tty/vt/keyboard.c:1495
 input_to_handler+0x3b6/0x4c0 drivers/input/input.c:118
 input_pass_values.part.0+0x2e3/0x720 drivers/input/input.c:145
 input_pass_values drivers/input/input.c:949 [inline]
 input_set_keycode+0x290/0x320 drivers/input/input.c:954
 evdev_handle_set_keycode_v2+0xc4/0x120 drivers/input/evdev.c:882
 evdev_do_ioctl drivers/input/evdev.c:1150 [inline]

In this case we were dealing with a fuzzed HID device that declared over
12K buttons, and while HID layer should not be reporting to us such big
keycodes, we should also be defensive and reject invalid data ourselves as
well.

Reported-by: syzbot+19340dff067c2d3835c0@syzkaller.appspotmail.com
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: stable <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20191122204220.GA129459@dtor-wsSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

We currently warn the user when tty->port is not set in tty_init_dev
yet. The warning says that the kernel will crash later. And it really
will only few lines below at:
tty->port->itty = tty;

So be nice and avoid the crash -- return an error instead. And update
the warning.
Signed-off-by: NJiri Slaby <jslaby@suse.cz>
Cc: Sudip Mukherjee <sudipm.mukherjee@gmail.com>
Link: https://lore.kernel.org/r/20191122101721.7222-1-jslaby@suse.czSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The interrupt clear flag register is a "write 1 to clear" register.
So, only writing ones allows to clear flags:
- Replace buggy stm32_clr_bits() by a simple write to clear error flags
- Replace useless read/modify/write stm32_set_bits() routine by a
  simple write to clear TC (transfer complete) flag.

Fixes: 4f01d833 ("serial: stm32: fix rx error handling")
Signed-off-by: NFabrice Gasnier <fabrice.gasnier@st.com>
Cc: stable <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/1574323849-1909-1-git-send-email-fabrice.gasnier@st.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Adjust indentation from seven spaces to tab (+optional two spaces) as in
coding style with command like:
	$ sed -e 's/^        /\t/' -i */Kconfig
Signed-off-by: NKrzysztof Kozlowski <krzk@kernel.org>
Link: https://lore.kernel.org/r/20191121132847.29015-1-krzk@kernel.orgSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Doing fuzz test on sbsa uart device, causes a kernel crash
due to NULL pointer dereference:

------------[ cut here ]------------
Unable to handle kernel paging request at virtual address fffffffffffffffc
pgd = ffffffe331723000
[fffffffffffffffc] *pgd=0000002333595003, *pud=0000002333595003, *pmd=00000
Internal error: Oops: 96000005 [#1] PREEMPT SMP
Modules linked in: ping(O) jffs2 rtos_snapshot(O) pramdisk(O) hisi_sfc(O)
Drv_Nandc_K(O) Drv_SysCtl_K(O) Drv_SysClk_K(O) bsp_reg(O) hns3(O)
hns3_uio_enet(O) hclgevf(O) hclge(O) hnae3(O) mdio_factory(O)
mdio_registry(O) mdio_dev(O) mdio(O) hns3_info(O) rtos_kbox_panic(O)
uart_suspend(O) rsm(O) stp llc tunnel4 xt_tcpudp ipt_REJECT nf_reject_ipv4
iptable_filter ip_tables x_tables sd_mod xhci_plat_hcd xhci_pci xhci_hcd
usbmon usbhid usb_storage ohci_platform ohci_pci ohci_hcd hid_generic hid
ehci_platform ehci_pci ehci_hcd vfat fat usbcore usb_common scsi_mod
yaffs2multi(O) ext4 jbd2 ext2 mbcache ofpart i2c_dev i2c_core uio ubi nand
nand_ecc nand_ids cfi_cmdset_0002 cfi_cmdset_0001 cfi_probe gen_probe
cmdlinepart chipreg mtdblock mtd_blkdevs mtd nfsd auth_rpcgss oid_registry
nfsv3 nfs nfs_acl lockd sunrpc grace autofs4
CPU: 2 PID: 2385 Comm: tty_fuzz_test Tainted: G           O    4.4.193 #1
task: ffffffe32b23f110 task.stack: ffffffe32bda4000
PC is at uart_break_ctl+0x44/0x84
LR is at uart_break_ctl+0x34/0x84
pc : [<ffffff8393196098>] lr : [<ffffff8393196088>] pstate: 80000005
sp : ffffffe32bda7cc0
x29: ffffffe32bda7cc0 x28: ffffffe32b23f110
x27: ffffff8393402000 x26: 0000000000000000
x25: ffffffe32b233f40 x24: ffffffc07a8ec680
x23: 0000000000005425 x22: 00000000ffffffff
x21: ffffffe33ed73c98 x20: 0000000000000000
x19: ffffffe33ed94168 x18: 0000000000000004
x17: 0000007f92ae9d30 x16: ffffff8392fa6064
x15: 0000000000000010 x14: 0000000000000000
x13: 0000000000000000 x12: 0000000000000000
x11: 0000000000000020 x10: 0000007ffdac1708
x9 : 0000000000000078 x8 : 000000000000001d
x7 : 0000000052a64887 x6 : ffffffe32bda7e08
x5 : ffffffe32b23c000 x4 : 0000005fbc5b0000
x3 : ffffff83938d5018 x2 : 0000000000000080
x1 : ffffffe32b23c040 x0 : ffffff83934428f8
virtual start addr offset is 38ac00000
module base offset is 2cd4cf1000
linear region base offset is : 0
Process tty_fuzz_test (pid: 2385, stack limit = 0xffffffe32bda4000)
Stack: (0xffffffe32bda7cc0 to 0xffffffe32bda8000)
7cc0: ffffffe32bda7cf0 ffffff8393177718 ffffffc07a8ec680 ffffff8393196054
7ce0: 000000001739f2e0 0000007ffdac1978 ffffffe32bda7d20 ffffff8393179a1c
7d00: 0000000000000000 ffffff8393c0a000 ffffffc07a8ec680 cb88537fdc8ba600
7d20: ffffffe32bda7df0 ffffff8392fa5a40 ffffff8393c0a000 0000000000005425
7d40: 0000007ffdac1978 ffffffe32b233f40 ffffff8393178dcc 0000000000000003
7d60: 000000000000011d 000000000000001d ffffffe32b23f110 000000000000029e
7d80: ffffffe34fe8d5d0 0000000000000000 ffffffe32bda7e14 cb88537fdc8ba600
7da0: ffffffe32bda7e30 ffffff8393042cfc ffffff8393c41720 ffffff8393c46410
7dc0: ffffff839304fa68 ffffffe32b233f40 0000000000005425 0000007ffdac1978
7de0: 000000000000011d cb88537fdc8ba600 ffffffe32bda7e70 ffffff8392fa60cc
7e00: 0000000000000000 ffffffe32b233f40 ffffffe32b233f40 0000000000000003
7e20: 0000000000005425 0000007ffdac1978 ffffffe32bda7e70 ffffff8392fa60b0
7e40: 0000000000000280 ffffffe32b233f40 ffffffe32b233f40 0000000000000003
7e60: 0000000000005425 cb88537fdc8ba600 0000000000000000 ffffff8392e02e78
7e80: 0000000000000280 0000005fbc5b0000 ffffffffffffffff 0000007f92ae9d3c
7ea0: 0000000060000000 0000000000000015 0000000000000003 0000000000005425
7ec0: 0000007ffdac1978 0000000000000000 00000000a54c910e 0000007f92b95014
7ee0: 0000007f92b95090 0000000052a64887 000000000000001d 0000000000000078
7f00: 0000007ffdac1708 0000000000000020 0000000000000000 0000000000000000
7f20: 0000000000000000 0000000000000010 000000556acf0090 0000007f92ae9d30
7f40: 0000000000000004 000000556acdef10 0000000000000000 000000556acdebd0
7f60: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
7f80: 0000000000000000 0000000000000000 0000000000000000 0000007ffdac1840
7fa0: 000000556acdedcc 0000007ffdac1840 0000007f92ae9d3c 0000000060000000
7fc0: 0000000000000000 0000000000000000 0000000000000003 000000000000001d
7fe0: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
Call trace:
Exception stack(0xffffffe32bda7ab0 to 0xffffffe32bda7bf0)
7aa0:                                   0000000000001000 0000007fffffffff
7ac0: ffffffe32bda7cc0 ffffff8393196098 0000000080000005 0000000000000025
7ae0: ffffffe32b233f40 ffffff83930d777c ffffffe32bda7b30 ffffff83930d777c
7b00: ffffffe32bda7be0 ffffff83938d5000 ffffffe32bda7be0 ffffffe32bda7c20
7b20: ffffffe32bda7b60 ffffff83930d777c ffffffe32bda7c10 ffffff83938d5000
7b40: ffffffe32bda7c10 ffffffe32bda7c50 ffffff8393c0a000 ffffffe32b23f110
7b60: ffffffe32bda7b70 ffffff8392e09df4 ffffffe32bda7bb0 cb88537fdc8ba600
7b80: ffffff83934428f8 ffffffe32b23c040 0000000000000080 ffffff83938d5018
7ba0: 0000005fbc5b0000 ffffffe32b23c000 ffffffe32bda7e08 0000000052a64887
7bc0: 000000000000001d 0000000000000078 0000007ffdac1708 0000000000000020
7be0: 0000000000000000 0000000000000000
[<ffffff8393196098>] uart_break_ctl+0x44/0x84
[<ffffff8393177718>] send_break+0xa0/0x114
[<ffffff8393179a1c>] tty_ioctl+0xc50/0xe84
[<ffffff8392fa5a40>] do_vfs_ioctl+0xc4/0x6e8
[<ffffff8392fa60cc>] SyS_ioctl+0x68/0x9c
[<ffffff8392e02e78>] __sys_trace_return+0x0/0x4
Code: b9410ea0 34000160 f9408aa0 f9402814 (b85fc280)
---[ end trace 8606094f1960c5e0 ]---
Kernel panic - not syncing: Fatal exception

Fix this problem by adding NULL checks prior to calling break_ctl ops.
Signed-off-by: NJiangfeng Xiao <xiaojiangfeng@huawei.com>
Cc: stable <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/1574263133-28259-1-git-send-email-xiaojiangfeng@huawei.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The argument 'inode' passed to tty_open_by_driver() was not being used.
Remove the extra argument.
Signed-off-by: NSudip Mukherjee <sudipm.mukherjee@gmail.com>
Link: https://lore.kernel.org/r/20191120151709.14148-1-sudipm.mukherjee@gmail.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Adjust indentation from spaces to tab (+optional two spaces) as in
coding style with command like:
	$ sed -e 's/^        /\t/' -i */Kconfig
Signed-off-by: NKrzysztof Kozlowski <krzk@kernel.org>
Link: https://lore.kernel.org/r/20191120133843.13189-1-krzk@kernel.orgSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Any arm config which has 'CONFIG_MTD_ONENAND_SAMSUNG=m' and
'CONFIG_SERIAL_SAMSUNG=m' gives a build warning:

warning: same module names found:
  drivers/tty/serial/samsung.ko
  drivers/mtd/nand/onenand/samsung.ko

Rename both drivers/tty/serial/samsung.c to
drivers/tty/serial/samsung_tty.c and drivers/mtd/nand/onenand/samsung.c
drivers/mtd/nand/onenand/samsung_mtd.c to fix the warning.
Signed-off-by: NSudip Mukherjee <sudipm.mukherjee@gmail.com>
Acked-by: NRichard Weinberger <richard@nod.at>
Link: https://lore.kernel.org/r/20191117202435.28127-1-sudipm.mukherjee@gmail.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The driver forgets to call pm_runtime_disable in remove.
Add the missed calls to fix it.
Signed-off-by: NChuhong Yuan <hslester96@gmail.com>
Cc: stable <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20191118024833.21587-1-hslester96@gmail.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

PL011's ->flush_buffer() implementation releases and reacquires the port
lock.  Due to a race condition here, data can end up being added to the
circular buffer but neither being discarded nor being sent out.  This
leads to, for example, tcdrain(2) waiting indefinitely.

Process A                       Process B

uart_flush_buffer()
 - acquire lock
 - circ_clear
 - pl011_flush_buffer()
 -- release lock
 -- dmaengine_terminate_all()

                                uart_write()
                                - acquire lock
                                - add chars to circ buffer
                                - start_tx()
                                -- start DMA
                                - release lock

 -- acquire lock
 -- turn off DMA
 -- release lock

                                // Data in circ buffer but DMA is off

According to the comment in the code, the releasing of the lock around
dmaengine_terminate_all() is to avoid a deadlock with the DMA engine
callback.  However, since the time this code was written, the DMA engine
API documentation seems to have been clarified to say that
dmaengine_terminate_all() (in the identically implemented but
differently named dmaengine_terminate_async() variant) does not wait for
any running complete callback to be completed and can even be called
from a complete callback.  So there is no possibility of deadlock if the
DMA engine driver implements this API correctly.

So we should be able to just remove this release and reacquire of the
lock to prevent the aforementioned race condition.
Signed-off-by: NVincent Whitchurch <vincent.whitchurch@axis.com>
Cc: stable <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20191118092547.32135-1-vincent.whitchurch@axis.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This reverts commit f33cf776.

As Johan says, this driver needs a lot more work and these changes are
only going in the wrong direction:
    https://lkml.kernel.org/r/20190523091839.GC568@localhostReported-by: NJohan Hovold <johan@kernel.org>
Cc: Shubhrajyoti Datta <shubhrajyoti.datta@xilinx.com>
Cc: Michal Simek <michal.simek@xilinx.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This reverts commit 62104b28.

As Johan says, this driver needs a lot more work and these changes are
only going in the wrong direction:
    https://lkml.kernel.org/r/20190523091839.GC568@localhostReported-by: NJohan Hovold <johan@kernel.org>
Cc: Shubhrajyoti Datta <shubhrajyoti.datta@xilinx.com>
Cc: Michal Simek <michal.simek@xilinx.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This reverts commit 3b209d25.

As Johan says, this driver needs a lot more work and these changes are
only going in the wrong direction:
    https://lkml.kernel.org/r/20190523091839.GC568@localhostReported-by: NJohan Hovold <johan@kernel.org>
Cc: Shubhrajyoti Datta <shubhrajyoti.datta@xilinx.com>
Cc: Michal Simek <michal.simek@xilinx.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This reverts commit 0379b116.

As Johan says, this driver needs a lot more work and these changes are
only going in the wrong direction:
    https://lkml.kernel.org/r/20190523091839.GC568@localhostReported-by: NJohan Hovold <johan@kernel.org>
Cc: Shubhrajyoti Datta <shubhrajyoti.datta@xilinx.com>
Cc: Michal Simek <michal.simek@xilinx.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This reverts commit d338838c.

As Johan says, this driver needs a lot more work and these changes are
only going in the wrong direction:
    https://lkml.kernel.org/r/20190523091839.GC568@localhostReported-by: NJohan Hovold <johan@kernel.org>
Cc: Shubhrajyoti Datta <shubhrajyoti.datta@xilinx.com>
Cc: Michal Simek <michal.simek@xilinx.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This reverts commit a00d9db8.

As Johan says, this driver needs a lot more work and these changes are
only going in the wrong direction:
	https://lkml.kernel.org/r/20190523091839.GC568@localhostReported-by: NJohan Hovold <johan@kernel.org>
Cc: Shubhrajyoti Datta <shubhrajyoti.datta@xilinx.com>
Cc: Michal Simek <michal.simek@xilinx.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

When running in M-mode we can't use SBI based drivers.  Add a new
CONFIG_RISCV_SBI that drivers that do SBI calls can depend on
instead.
Signed-off-by: NDamien Le Moal <damien.lemoal@wdc.com>
Reviewed-by: NAnup Patel <anup@brainfault.org>
Signed-off-by: NChristoph Hellwig <hch@lst.de>
Signed-off-by: NPaul Walmsley <paul.walmsley@sifive.com>

dma_request_slave_channel_reason() is:
#define dma_request_slave_channel_reason(dev, name) \
	dma_request_chan(dev, name)
Signed-off-by: NPeter Ujfalusi <peter.ujfalusi@ti.com>
Link: https://lore.kernel.org/r/20191113094618.1725-3-peter.ujfalusi@ti.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

dma_request_slave_channel_reason() is:
#define dma_request_slave_channel_reason(dev, name) \
	dma_request_chan(dev, name)
Signed-off-by: NPeter Ujfalusi <peter.ujfalusi@ti.com>
Link: https://lore.kernel.org/r/20191113094618.1725-4-peter.ujfalusi@ti.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

dma_request_slave_channel_reason() is:
#define dma_request_slave_channel_reason(dev, name) \
	dma_request_chan(dev, name)
Signed-off-by: NPeter Ujfalusi <peter.ujfalusi@ti.com>
Link: https://lore.kernel.org/r/20191113094618.1725-2-peter.ujfalusi@ti.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Remove the use of the static uartlite structure.
Signed-off-by: NShubhrajyoti Datta <shubhrajyoti.datta@xilinx.com>
Signed-off-by: NMichal Simek <michal.simek@xilinx.com>
Link: https://lore.kernel.org/r/1573555271-2579-2-git-send-email-shubhrajyoti.datta@gmail.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Change logic how console_port is setup by using CON_ENABLED flag
instead of index. There will be unique uart_console
structure that's why code can't use id for console_port
assignment.
Signed-off-by: NShubhrajyoti Datta <shubhrajyoti.datta@xilinx.com>
Link: https://lore.kernel.org/r/1573555271-2579-1-git-send-email-shubhrajyoti.datta@gmail.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Per Documentation/DMA-API-HOWTO.txt,
To unmap a scatterlist, just call:
	dma_unmap_sg(dev, sglist, nents, direction);

.. note::

	The 'nents' argument to the dma_unmap_sg call must be
	the _same_ one you passed into the dma_map_sg call,
	it should _NOT_ be the 'count' value _returned_ from the
	dma_map_sg call.

However in the driver, priv->nent is directly assigned with value
returned from dma_map_sg, and dma_unmap_sg use priv->nent for unmap,
this breaks the API usage.

So introduce a new entry orig_nent to remember 'nents'.

Fixes: da3564ee ("pch_uart: add multi-scatter processing")
Signed-off-by: NPeng Fan <peng.fan@nxp.com>
Link: https://lore.kernel.org/r/1573623259-6339-1-git-send-email-peng.fan@nxp.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The dmaengine_prep_slave_sg needs to use sg count returned
by dma_map_sg, not use sport->dma_tx_nents, because the return
value of dma_map_sg is not always same with "nents".

Fixes: b4cdc8f6 ("serial: imx: add DMA support for imx6q")
Signed-off-by: NPeng Fan <peng.fan@nxp.com>
Link: https://lore.kernel.org/r/1573108875-26530-1-git-send-email-peng.fan@nxp.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This means removing support for checking magic in amiserial.c
(SERIAL_PARANOIA_CHECK option), which was checking a magic field which
doesn't currently exist in the struct. That code hasn't built at least
since git.

Removing the definition from the header is safe anyway as that code was
from another driver and not including it.
Signed-off-by: NPascal Terjan <pterjan@google.com>
Reviewed-by: NGeert Uytterhoeven <geert@linux-m68k.org>
Link: https://lore.kernel.org/r/20191105192749.67533-1-pterjan@google.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The dmaengine_prep_slave_sg needs to use sg count returned
by dma_map_sg, not use sport->dma_tx_nents, because the return
value of dma_map_sg is not always same with "nents".

When enabling iommu for lpuart + edma, iommu framework may concatenate
two sgs into one.

Fixes: 6250cc30 ("tty: serial: fsl_lpuart: Use scatter/gather DMA for Tx")
Cc: <stable@vger.kernel.org>
Signed-off-by: NPeng Fan <peng.fan@nxp.com>
Link: https://lore.kernel.org/r/1572932977-17866-1-git-send-email-peng.fan@nxp.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This reverts commit 7726fb53.

Jiri writes:
	On 24. 09. 19, 11:25, Xiaoming Ni wrote:
	> According to the comment of tty_port_destroy():
	>     When a port was initialized using tty_port_init, one has to destroy
	>     the port by tty_port_destroy();

	It continues with a part saying:
	   Either indirectly by using tty_port refcounting
	   (tty_port_put) or directly if refcounting is not used.

So this should be reverted.

Cc: Xiaoming Ni <nixiaoming@huawei.com>
Reported-by: NJiri Slaby <jslaby@suse.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The driver uses clk_prepare_enable in ulite_probe but uses clk_unprepare
in ulite_remove, which does not match.
Replace clk_unprepare with clk_disable_unprepare to fix it.
Signed-off-by: NChuhong Yuan <hslester96@gmail.com>
Link: https://lore.kernel.org/r/20191101085433.10399-1-hslester96@gmail.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

As platform_get_irq() now prints an error when the interrupt does not
exist, this warnings are printed on bananapi-r2:

[    4.935780] mt6577-uart 11004000.serial: IRQ index 1 not found
[    4.962589] 11002000.serial: ttyS1 at MMIO 0x11002000 (irq = 202, base_baud = 1625000) is a ST16650V2
[    4.972127] mt6577-uart 11002000.serial: IRQ index 1 not found
[    4.998927] 11003000.serial: ttyS2 at MMIO 0x11003000 (irq = 203, base_baud = 1625000) is a ST16650V2
[    5.008474] mt6577-uart 11003000.serial: IRQ index 1 not found

Fix this by calling platform_get_irq_optional() instead.

now it looks like this:

[    4.872751] Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled

Fixes: 7723f4c5 ("driver core: platform: Add an error message to platform_get_irq*()")
Signed-off-by: NFrank Wunderlich <frank-w@public-files.de>
Cc: stable <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20191027062117.20389-1-frank-w@public-files.deSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Since the commit 7723f4c5 ("driver core: platform: Add an error message
to platform_get_irq*()") platform_get_irq() started issuing an error message.
Thus, there is no need to have the same in the driver

Fixes: 7723f4c5 ("driver core: platform: Add an error message to platform_get_irq*()")
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: stable <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20191023103558.51862-1-andriy.shevchenko@linux.intel.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

hci_qca interfaces to the wcn3990 via a uart_dm on the msm8998 mtp and
Lenovo Miix 630 laptop.  As part of initializing the wcn3990, hci_qca
disables flow, configures the uart baudrate, and then reenables flow - at
which point an event is expected to be received over the uart from the
wcn3990.  It is observed that this event comes after the baudrate change
but before hci_qca re-enables flow. This is unexpected, and is a result of
msm_reset() being broken.

According to the uart_dm hardware documentation, it is recommended that
automatic hardware flow control be enabled by setting RX_RDY_CTL.  Auto
hw flow control will manage RFR based on the configured watermark.  When
there is space to receive data, the hw will assert RFR.  When the watermark
is hit, the hw will de-assert RFR.

The hardware documentation indicates that RFR can me manually managed via
CR when RX_RDY_CTL is not set.  SET_RFR asserts RFR, and RESET_RFR
de-asserts RFR.

msm_reset() is broken because after resetting the hardware, it
unconditionally asserts RFR via SET_RFR.  This enables flow regardless of
the current configuration, and would undo a previous flow disable
operation.  It should instead de-assert RFR via RESET_RFR to block flow
until the hardware is reconfigured.  msm_serial should rely on the client
to specify that flow should be enabled, either via mctrl() or the termios
structure, and only assert RFR in response to those triggers.

Fixes: 04896a77 ("msm_serial: serial driver for MSM7K onboard serial peripheral.")
Signed-off-by: NJeffrey Hugo <jeffrey.l.hugo@gmail.com>
Reviewed-by: NBjorn Andersson <bjorn.andersson@linaro.org>
Cc: stable <stable@vger.kernel.org>
Reviewed-by: NAndy Gross <agross@kernel.org>
Link: https://lore.kernel.org/r/20191021154616.25457-1-jeffrey.l.hugo@gmail.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The build of xtensa allmodconfig gives warning of:
In function 'get_ports.isra.0':
warning: the frame size of 1040 bytes is larger than 1024 bytes
Signed-off-by: NSudip Mukherjee <sudipm.mukherjee@gmail.com>
Acked-by: NJiri Slaby <jslaby@suse.cz>
Link: https://lore.kernel.org/r/20191018161712.27807-1-sudipm.mukherjee@gmail.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This commits adds RS485 support for LPUART hardware that uses 32-bit
registers. These are typically found in i.MX8 processors.
Signed-off-by: NPhilippe Schenker <philippe.schenker@toradex.com>
Reviewed-by: NFugang Duan <fugang.duan@nxp.com>

Link: https://lore.kernel.org/r/20191017141428.10330-3-philippe.schenker@toradex.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Use define from the 32-bit register description UARTMODIR_* instead of
UARTMODEM_*. The value is the same, so there is no functional change.
Signed-off-by: NPhilippe Schenker <philippe.schenker@toradex.com>
Reviewed-by: NStefan Agner <stefan.agner@toradex.com>
Reviewed-by: NFugang Duan <fugang.duan@nxp.com>

Link: https://lore.kernel.org/r/20191017141428.10330-2-philippe.schenker@toradex.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>