user/sven/linux.git/drivers/tty/serial, branch v5.4.3

Revert "serial/8250: Add support for NI-Serial PXI/PXIe+485 devices"

2019-12-13T07:43:22Z

commit 27ed14d0ecb38516b6f3c6fdcd62c25c9454f979 upstream. This reverts commit fdc2de87124f5183a98ea7eced1f76dbdba22951 ("serial/8250: Add support for NI-Serial PXI/PXIe+485 devices"). The commit fdc2de87124f ("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: Je Yen Tam Fixes: fdc2de87124f ("serial/8250: Add support for NI-Serial PXI/PXIe+485 devices") Cc: stable Link: https://lore.kernel.org/r/20191127075301.9866-1-je.yen.tam@ni.com Signed-off-by: Greg Kroah-Hartman

serial: ifx6x60: add missed pm_runtime_disable

2019-12-13T07:42:25Z

commit 50b2b571c5f3df721fc81bf9a12c521dfbe019ba upstream. The driver forgets to call pm_runtime_disable in remove. Add the missed calls to fix it. Signed-off-by: Chuhong Yuan Cc: stable Link: https://lore.kernel.org/r/20191118024833.21587-1-hslester96@gmail.com Signed-off-by: Greg Kroah-Hartman

serial: 8250_dw: Avoid double error messaging when IRQ absent

2019-12-13T07:42:25Z

commit 05faa64e73924556ba281911db24643e438fe7ba upstream. Since the commit 7723f4c5ecdb ("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: 7723f4c5ecdb ("driver core: platform: Add an error message to platform_get_irq*()") Signed-off-by: Andy Shevchenko Cc: stable Link: https://lore.kernel.org/r/20191023103558.51862-1-andriy.shevchenko@linux.intel.com Signed-off-by: Greg Kroah-Hartman

serial: stm32: fix clearing interrupt error flags

2019-12-13T07:42:24Z

commit 1250ed7114a977cdc2a67a0c09d6cdda63970eb9 upstream. 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: 4f01d833fdcd ("serial: stm32: fix rx error handling") Signed-off-by: Fabrice Gasnier Cc: stable Link: https://lore.kernel.org/r/1574323849-1909-1-git-send-email-fabrice.gasnier@st.com Signed-off-by: Greg Kroah-Hartman

serial: serial_core: Perform NULL checks for break_ctl ops

2019-12-13T07:42:23Z

commit 7d73170e1c282576419f8b50a771f1fcd2b81a94 upstream. 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 : [] lr : [] 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 [] uart_break_ctl+0x44/0x84 [] send_break+0xa0/0x114 [] tty_ioctl+0xc50/0xe84 [] do_vfs_ioctl+0xc4/0x6e8 [] SyS_ioctl+0x68/0x9c [] __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: Jiangfeng Xiao Cc: stable Link: https://lore.kernel.org/r/1574263133-28259-1-git-send-email-xiaojiangfeng@huawei.com Signed-off-by: Greg Kroah-Hartman

serial: pl011: Fix DMA ->flush_buffer()

2019-12-13T07:42:23Z

commit f6a196477184b99a31d16366a8e826558aa11f6d upstream. 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: Vincent Whitchurch Cc: stable Link: https://lore.kernel.org/r/20191118092547.32135-1-vincent.whitchurch@axis.com Signed-off-by: Greg Kroah-Hartman

tty: serial: msm_serial: Fix flow control

2019-12-13T07:42:22Z

commit b027ce258369cbfa88401a691c23dad01deb9f9b upstream. 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: 04896a77a97b ("msm_serial: serial driver for MSM7K onboard serial peripheral.") Signed-off-by: Jeffrey Hugo Reviewed-by: Bjorn Andersson Cc: stable Reviewed-by: Andy Gross Link: https://lore.kernel.org/r/20191021154616.25457-1-jeffrey.l.hugo@gmail.com Signed-off-by: Greg Kroah-Hartman

tty: serial: fsl_lpuart: use the sg count from dma_map_sg

2019-12-13T07:42:21Z

commit 487ee861de176090b055eba5b252b56a3b9973d6 upstream. 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: 6250cc30c4c4e ("tty: serial: fsl_lpuart: Use scatter/gather DMA for Tx") Cc: Signed-off-by: Peng Fan Link: https://lore.kernel.org/r/1572932977-17866-1-git-send-email-peng.fan@nxp.com Signed-off-by: Greg Kroah-Hartman

serial: 8250-mtk: Use platform_get_irq_optional() for optional irq

2019-12-13T07:42:21Z

commit eb9c1a41ea1234907615fe47d6e47db8352d744b upstream. 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: 7723f4c5ecdb8d83 ("driver core: platform: Add an error message to platform_get_irq*()") Signed-off-by: Frank Wunderlich Cc: stable Link: https://lore.kernel.org/r/20191027062117.20389-1-frank-w@public-files.de Signed-off-by: Greg Kroah-Hartman

8250-men-mcb: fix error checking when get_num_ports returns -ENODEV

2019-10-15T19:38:41Z

The current checking for failure on the number of ports fails when -ENODEV is returned from the call to get_num_ports. Fix this by making num_ports and loop counter i signed rather than unsigned ints. Also add check for num_ports being less than zero to check for -ve error returns. Addresses-Coverity: ("Unsigned compared against 0") Fixes: e2fea54e4592 ("8250-men-mcb: add support for 16z025 and 16z057") Signed-off-by: Colin Ian King Reviewed-by: Michael Moese Link: https://lore.kernel.org/r/20191013220016.9369-1-colin.king@canonical.com Signed-off-by: Greg Kroah-Hartman