08 Mar, 2020

1 commit

  • Merge Linux stable release v5.4.24 into imx_5.4.y

    * tag 'v5.4.24': (3306 commits)
    Linux 5.4.24
    blktrace: Protect q->blk_trace with RCU
    kvm: nVMX: VMWRITE checks unsupported field before read-only field
    ...

    Signed-off-by: Jason Liu

    Conflicts:
    arch/arm/boot/dts/imx6sll-evk.dts
    arch/arm/boot/dts/imx7ulp.dtsi
    arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
    drivers/clk/imx/clk-composite-8m.c
    drivers/gpio/gpio-mxc.c
    drivers/irqchip/Kconfig
    drivers/mmc/host/sdhci-of-esdhc.c
    drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c
    drivers/net/can/flexcan.c
    drivers/net/ethernet/freescale/dpaa/dpaa_eth.c
    drivers/net/ethernet/mscc/ocelot.c
    drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
    drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
    drivers/net/phy/realtek.c
    drivers/pci/controller/mobiveil/pcie-mobiveil-host.c
    drivers/perf/fsl_imx8_ddr_perf.c
    drivers/tee/optee/shm_pool.c
    drivers/usb/cdns3/gadget.c
    kernel/sched/cpufreq.c
    net/core/xdp.c
    sound/soc/fsl/fsl_esai.c
    sound/soc/fsl/fsl_sai.c
    sound/soc/sof/core.c
    sound/soc/sof/imx/Kconfig
    sound/soc/sof/loader.c

    Jason Liu
     

29 Feb, 2020

4 commits

  • commit 679aac5ead2f18d223554a52b543e1195e181811 upstream.

    RX cancel command fails when BT is switched on and off multiple times.

    To handle this, poll for the cancel bit in SE_GENI_S_IRQ_STATUS register
    instead of SE_GENI_S_CMD_CTRL_REG.

    As per the HPG update, handle the RX last bit after cancel command
    and flush out the RX FIFO buffer.

    Signed-off-by: satya priya
    Cc: stable
    Link: https://lore.kernel.org/r/1581415982-8793-1-git-send-email-skakit@codeaurora.org
    Signed-off-by: Greg Kroah-Hartman

    satya priya
     
  • commit f76707831829530ffdd3888bebc108aecefccaa0 upstream.

    There has oops as below happen on i.MX8MP EVK platform that has
    6G bytes DDR memory.

    when (xmit->tail < xmit->head) && (xmit->head == 0),
    it setups one sg entry with sg->length is zero:
    sg_set_buf(sgl + 1, xmit->buf, xmit->head);

    if xmit->buf is allocated from >4G address space, and SDMA only
    support
    Tested-by: Eagle Zhou
    Signed-off-by: Fugang Duan
    Cc: stable
    Fixes: 7942f8577f2a ("serial: imx: TX DMA: clean up sg initialization")
    Reviewed-by: Uwe Kleine-König
    Link: https://lore.kernel.org/r/1581401761-6378-1-git-send-email-fugang.duan@nxp.com
    Signed-off-by: Greg Kroah-Hartman

    Fugang Duan
     
  • commit 04b5bfe3dc94e64d0590c54045815cb5183fb095 upstream.

    In atmel_shutdown() we call atmel_stop_rx() and atmel_stop_tx() functions.
    Prevent the rx restart that is implemented in RS485 or ISO7816 modes when
    calling atmel_stop_tx() by using the atomic information tasklet_shutdown
    that is already in place for this purpose.

    Fixes: 98f2082c3ac4 ("tty/serial: atmel: enforce tasklet init and termination sequences")
    Signed-off-by: Nicolas Ferre
    Cc: stable
    Link: https://lore.kernel.org/r/20200210152053.8289-1-nicolas.ferre@microchip.com
    Signed-off-by: Greg Kroah-Hartman

    Nicolas Ferre
     
  • commit 7febbcbc48fc92e3f33863b32ed715ba4aff18c4 upstream.

    The commit 54e53b2e8081
    ("tty: serial: 8250: pass IRQ shared flag to UART ports")
    nicely explained the problem:

    ---8
    Cc: Kurt Kanzenbach
    Cc: Vikram Pandita
    Signed-off-by: Andy Shevchenko
    Cc: stable
    Acked-by: Kurt Kanzenbach
    Link: https://lore.kernel.org/r/20200211135559.85960-1-andriy.shevchenko@linux.intel.com
    Signed-off-by: Greg Kroah-Hartman

    Andy Shevchenko
     

28 Feb, 2020

1 commit


13 Feb, 2020

1 commit

  • There has oops as below happen on i.MX8MP EVK platform that has
    6G bytes DDR memory.

    when (xmit->tail < xmit->head) && (xmit->head == 0),
    it setups one sg entry with sg->length is zero:
    sg_set_buf(sgl + 1, xmit->buf, xmit->head);

    if xmit->buf is allocated from >4G address space, and SDMA only
    support
    Tested-by: Eagle Zhou
    Signed-off-by: Fugang Duan
    Cc: stable
    Fixes: 7942f8577f2a ("serial: imx: TX DMA: clean up sg initialization")
    Reviewed-by: Uwe Kleine-König
    Link: https://lore.kernel.org/r/1581401761-6378-1-git-send-email-fugang.duan@nxp.com
    Signed-off-by: Greg Kroah-Hartman

    Fugang Duan
     

01 Feb, 2020

2 commits

  • commit 101aa46bd221b768dfff8ef3745173fc8dbb85ee upstream.

    The main irq handler function starts by first masking disabled
    interrupts in the status register values to ensure to only handle
    enabled interrupts. This is important as when the RX path in the
    hardware is disabled reading the RX fifo results in an external abort.

    This checking must be done under the port lock, otherwise the following
    can happen:

    CPU1 | CPU2
    |
    irq triggers as there are chars |
    in the RX fifo |
    | grab port lock
    imx_uart_int finds RRDY enabled |
    and calls imx_uart_rxint which |
    has to wait for port lock |
    | disable RX (e.g. because we're
    | using RS485 with !RX_DURING_TX)
    |
    | release port lock
    read from RX fifo with RX |
    disabled => exception |

    So take the port lock only once in imx_uart_int() instead of in the
    functions called from there.

    Reported-by: Andre Renaud
    Cc: stable@vger.kernel.org
    Signed-off-by: Uwe Kleine-König
    Link: https://lore.kernel.org/r/20200121071702.20150-1-u.kleine-koenig@pengutronix.de
    Signed-off-by: Greg Kroah-Hartman

    Uwe Kleine-König
     
  • commit dc76697d7e933d5e299116f219c890568785ea15 upstream.

    Unbinding the bcm2835aux UART driver raises the following error if the
    maximum number of 8250 UARTs is set to 1 (via the 8250.nr_uarts module
    parameter or CONFIG_SERIAL_8250_RUNTIME_UARTS):

    (NULL device *): Removing wrong port: a6f80333 != fa20408b

    That's because bcm2835aux_serial_probe() retrieves UART line number 1
    from the devicetree and stores it in data->uart.port.line, while
    serial8250_register_8250_port() instead uses UART line number 0,
    which is stored in data->line.

    On driver unbind, bcm2835aux_serial_remove() uses data->uart.port.line,
    which contains the wrong number. Fix it.

    The issue does not occur if the maximum number of 8250 UARTs is >= 2.

    Fixes: bdc5f3009580 ("serial: bcm2835: add driver for bcm2835-aux-uart")
    Signed-off-by: Lukas Wunner
    Cc: stable@vger.kernel.org # v4.6+
    Cc: Martin Sperl
    Reviewed-by: Nicolas Saenz Julienne
    Tested-by: Nicolas Saenz Julienne
    Link: https://lore.kernel.org/r/912ccf553c5258135c6d7e8f404a101ef320f0f4.1579175223.git.lukas@wunner.de
    Signed-off-by: Greg Kroah-Hartman

    Lukas Wunner
     

18 Jan, 2020

2 commits

  • commit 74887542fdcc92ad06a48c0cca17cdf09fc8aa00 upstream.

    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: da3564ee027e ("pch_uart: add multi-scatter processing")
    Signed-off-by: Peng Fan
    Link: https://lore.kernel.org/r/1573623259-6339-1-git-send-email-peng.fan@nxp.com
    Signed-off-by: Greg Kroah-Hartman

    Peng Fan
     
  • commit 596fd8dffb745afcebc0ec6968e17fe29f02044c 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".

    Fixes: b4cdc8f61beb ("serial: imx: add DMA support for imx6q")
    Signed-off-by: Peng Fan
    Link: https://lore.kernel.org/r/1573108875-26530-1-git-send-email-peng.fan@nxp.com
    Signed-off-by: Greg Kroah-Hartman

    Peng Fan
     

15 Jan, 2020

1 commit

  • commit fb2b90014d782d80d7ebf663e50f96d8c507a73c upstream.

    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: Jiri Slaby
    Signed-off-by: Sudip Mukherjee
    Cc: stable
    Link: https://lore.kernel.org/r/20191212131602.29504-1-sudipm.mukherjee@gmail.com
    Signed-off-by: Greg Kroah-Hartman

    Sudip Mukherjee
     

09 Jan, 2020

1 commit

  • commit 0e4f7f920a5c6bfe5e851e989f27b35a0cc7fb7e upstream.

    As the commit 677fe555cbfb ("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: 04896a77a97b ("msm_serial: serial driver for MSM7K onboard serial peripheral.")
    Signed-off-by: Leo Yan
    Reviewed-by: Jeffrey Hugo
    Link: https://lore.kernel.org/r/20191127141544.4277-2-leo.yan@linaro.org
    Signed-off-by: Greg Kroah-Hartman
    Signed-off-by: Greg Kroah-Hartman

    Leo Yan
     

31 Dec, 2019

2 commits

  • commit abeb2e9414d7e3a0d8417bc3b13d7172513ea8a0 upstream.

    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: b7396a38fb28 ("tty/serial: Add Spreadtrum sc9836-uart driver support")
    Signed-off-by: Yonghan Ye
    Cc: stable
    Signed-off-by: Baolin Wang
    Link: https://lore.kernel.org/r/925e51b73099c90158e080b8f5bed9b3b38c4548.1575460601.git.baolin.wang7@gmail.com
    Signed-off-by: Greg Kroah-Hartman

    Yonghan Ye
     
  • commit cb47b9f8630ae3fa3f5fbd0c7003faba7abdf711 upstream.

    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: 5bf5635ac170 ("tty/serial: atmel: add fractional baud rate support")
    Signed-off-by: David Engraf
    Acked-by: Ludovic Desroches
    Acked-by: Richard Genoud
    Cc: stable
    Link: https://lore.kernel.org/r/20191216085403.17050-1-david.engraf@sysgo.com
    Signed-off-by: Greg Kroah-Hartman

    David Engraf
     

17 Dec, 2019

1 commit

  • "earlycon" no need to specify the value string since it uses
    stdout-path parameters. However when earlycon and normal console
    are not using the same uart port, we need specify value string
    to earlycon, this is what we need to do when support dual linux
    using jailhouse hypervisor. The 2nd linux will use the uart
    of the 1st linux as earlycon.

    earlycon=lpuart32,mmio32,0x5a060010,115200 not work for i.MX8QXP.
    It is because lpuart32_early_console_setup not support little endian.

    Since the original code is to support UPIO_MEM32BE, so if not
    UPIO_MEM32, we still take it as UPIO_MEM32BE

    Acked-by: Fugang Duan
    Signed-off-by: Peng Fan

    Peng Fan
     

16 Dec, 2019

1 commit

  • This is the 5.4.3 stable release

    Conflicts:
    drivers/cpufreq/imx-cpufreq-dt.c
    drivers/spi/spi-fsl-qspi.c

    The conflict is very minor, fixed it when do the merge. The imx-cpufreq-dt.c
    is just one line code-style change, using upstream one, no any function change.

    The spi-fsl-qspi.c has minor conflicts when merge upstream fixes: c69b17da53b2
    spi: spi-fsl-qspi: Clear TDH bits in FLSHCR register

    After merge, basic boot sanity test and basic qspi test been done on i.mx

    Signed-off-by: Jason Liu

    Jason Liu
     

13 Dec, 2019

9 commits

  • 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

    Je Yen Tam
     
  • 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

    Chuhong Yuan
     
  • 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

    Andy Shevchenko
     
  • 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

    Fabrice Gasnier
     
  • 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

    Jiangfeng Xiao
     
  • 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

    Vincent Whitchurch
     
  • 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

    Jeffrey Hugo
     
  • 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

    Peng Fan
     
  • 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

    Frank Wunderlich
     

02 Dec, 2019

1 commit

  • * uart/next: (18 commits)
    MLK-22971 serial: imx: disable UCR4_OREN in .stop_rx()
    tty: serial: lpuart: add LS1028A support
    serial: fsl_lpuart: enable two stop bits
    tty: serial: lpuart: enable wakeup source for lpuart
    MLK-17133-02 tty: serial: lpuart: add runtime pm support
    ...

    Dong Aisheng
     

25 Nov, 2019

13 commits