08 Oct, 2020

1 commit

  • * tag 'v5.4.70': (3051 commits)
    Linux 5.4.70
    netfilter: ctnetlink: add a range check for l3/l4 protonum
    ep_create_wakeup_source(): dentry name can change under you...
    ...

    Conflicts:
    arch/arm/mach-imx/pm-imx6.c
    arch/arm64/boot/dts/freescale/imx8mm-evk.dts
    arch/arm64/boot/dts/freescale/imx8mn-ddr4-evk.dts
    drivers/crypto/caam/caamalg.c
    drivers/gpu/drm/imx/dw_hdmi-imx.c
    drivers/gpu/drm/imx/imx-ldb.c
    drivers/gpu/drm/imx/ipuv3/ipuv3-crtc.c
    drivers/mmc/host/sdhci-esdhc-imx.c
    drivers/net/ethernet/freescale/dpaa2/dpaa2-eth.c
    drivers/net/ethernet/freescale/enetc/enetc.c
    drivers/net/ethernet/freescale/enetc/enetc_pf.c
    drivers/thermal/imx_thermal.c
    drivers/usb/cdns3/ep0.c
    drivers/xen/swiotlb-xen.c
    sound/soc/fsl/fsl_esai.c
    sound/soc/fsl/fsl_sai.c

    Signed-off-by: Jason Liu

    Jason Liu
     

01 Oct, 2020

5 commits

  • [ Upstream commit 8e84172e372bdca20c305d92d51d33640d2da431 ]

    It's incorrect to check the channel's "busy" state without taking a lock.
    That shouldn't cause any real troubles, nevertheless it's always better
    not to have any race conditions in the code.

    Signed-off-by: Dmitry Osipenko
    Acked-by: Jon Hunter
    Link: https://lore.kernel.org/r/20200209163356.6439-5-digetx@gmail.com
    Signed-off-by: Vinod Koul
    Signed-off-by: Sasha Levin

    Dmitry Osipenko
     
  • [ Upstream commit d80cbef35bf89b763f06e03bb4ff8f933bf012c5 ]

    To avoid race with vchan_complete, use the race free way to terminate
    running transfer.

    Move vdesc->node list_del in stm32_dma_start_transfer instead of in
    stm32_mdma_chan_complete to avoid another race in vchan_dma_desc_free_list.

    Signed-off-by: Amelie Delaunay
    Link: https://lore.kernel.org/r/20200129153628.29329-9-amelie.delaunay@st.com
    Signed-off-by: Vinod Koul
    Signed-off-by: Sasha Levin

    Amelie Delaunay
     
  • [ Upstream commit dfc708812a2acfc0ca56f56233b3c3e7b0d4ffe7 ]

    To avoid race with vchan_complete, use the race free way to terminate
    running transfer.

    Move vdesc->node list_del in stm32_mdma_start_transfer instead of in
    stm32_mdma_xfer_end to avoid another race in vchan_dma_desc_free_list.

    Signed-off-by: Amelie Delaunay
    Link: https://lore.kernel.org/r/20200127085334.13163-7-amelie.delaunay@st.com
    Signed-off-by: Vinod Koul
    Signed-off-by: Sasha Levin

    Amelie Delaunay
     
  • [ Upstream commit cc88525ebffc757e00cc5a5d61da6271646c7f5f ]

    Since the dma engine expects the burst length register content as
    power of 2 value, the burst length needs to be converted first.
    Additionally add a burst length range check to avoid corrupting unrelated
    register bits.

    Signed-off-by: Matthias Fend
    Link: https://lore.kernel.org/r/20200115102249.24398-1-matthias.fend@wolfvision.net
    Signed-off-by: Vinod Koul
    Signed-off-by: Sasha Levin

    Matthias Fend
     
  • [ Upstream commit 1ff95243257fad07290dcbc5f7a6ad79d6e703e2 ]

    When devm_request_irq fails, currently, the function
    dma_async_device_unregister gets called. This doesn't free
    the resources allocated by of_dma_controller_register.
    Therefore, we have called of_dma_controller_free for this purpose.

    Signed-off-by: Satendra Singh Thakur
    Link: https://lore.kernel.org/r/20191109113523.6067-1-sst2005@gmail.com
    Signed-off-by: Vinod Koul
    Signed-off-by: Sasha Levin

    Satendra Singh Thakur
     

27 Sep, 2020

2 commits


17 Sep, 2020

2 commits

  • [ Upstream commit 6d6018fc30bee67290dbed2fa51123f7c6f3d691 ]

    In probe, IRQ is requested before zchan->id is initialized which can be
    read in the irq handler. Hence, shift request irq after other initializations
    complete.

    Found by Linux Driver Verification project (linuxtesting.org).

    Signed-off-by: Madhuparna Bhowmik
    Reviewed-by: Paul Cercueil
    Link: https://lore.kernel.org/r/20200821034423.12713-1-madhuparnabhowmik10@gmail.com
    Signed-off-by: Vinod Koul
    Signed-off-by: Sasha Levin

    Madhuparna Bhowmik
     
  • [ Upstream commit 7eb48dd094de5fe0e216b550e73aa85257903973 ]

    The acpi_get_table() should be coupled with acpi_put_table() if
    the mapped table is not used at runtime to release the table
    mapping, put the CSRT table buf after using it.

    Signed-off-by: Hanjun Guo
    Link: https://lore.kernel.org/r/1595411661-15936-1-git-send-email-guohanjun@huawei.com
    Signed-off-by: Vinod Koul
    Signed-off-by: Sasha Levin

    Hanjun Guo
     

10 Sep, 2020

5 commits

  • commit 05655541c9503bfd01af4e6cbd7f5a29ac748e6c upstream.

    Fix the source and destination physical address calculation of a
    peripheral device on scatter-gather implementation.

    This issue manifested during tests using a 64 bits architecture system.
    The abnormal behavior wasn't visible before due to all previous tests
    were done using 32 bits architecture system, that masked his effect.

    Fixes: e63d79d1ffcd ("dmaengine: Add Synopsys eDMA IP core driver")
    Cc: stable@vger.kernel.org
    Signed-off-by: Gustavo Pimentel
    Link: https://lore.kernel.org/r/8d3ab7e2ba96563fe3495b32f60077fffb85307d.1597327623.git.gustavo.pimentel@synopsys.com
    Signed-off-by: Vinod Koul
    Signed-off-by: Greg Kroah-Hartman

    Gustavo Pimentel
     
  • [ Upstream commit 0661cef675d37e2c4b66a996389ebeae8568e49e ]

    Move the burst len fixup after setting the generic value for it. This
    finally enables the fixup introduced by commit 137bd11090d8 ("dmaengine:
    pl330: Align DMA memcpy operations to MFIFO width"), which otherwise was
    overwritten by the generic value.

    Reported-by: kernel test robot
    Fixes: 137bd11090d8 ("dmaengine: pl330: Align DMA memcpy operations to MFIFO width")
    Signed-off-by: Marek Szyprowski
    Link: https://lore.kernel.org/r/20200825064617.16193-1-m.szyprowski@samsung.com
    Signed-off-by: Vinod Koul
    Signed-off-by: Sasha Levin

    Marek Szyprowski
     
  • [ Upstream commit 0cef8e2c5a07d482ec907249dbd6687e8697677f ]

    The reurn value of of_find_device_by_node() is not checked, thus null
    pointer dereference will be triggered if of_find_device_by_node()
    failed.

    Fixes: bbe89c8e3d59 ("at_hdmac: move to generic DMA binding")
    Signed-off-by: Yu Kuai
    Link: https://lore.kernel.org/r/20200817115728.1706719-2-yukuai3@huawei.com
    Signed-off-by: Vinod Koul
    Signed-off-by: Sasha Levin

    Yu Kuai
     
  • [ Upstream commit 5b2aa9f918f6837ae943557f8cec02c34fcf80e7 ]

    of_dma_xlate callback can return ERR_PTR as well NULL in case of failure.

    If error code is returned (not NULL) then the route should be released and
    the router should not be registered for the channel.

    Fixes: 56f13c0d9524c ("dmaengine: of_dma: Support for DMA routers")
    Signed-off-by: Peter Ujfalusi
    Link: https://lore.kernel.org/r/20200806104928.25975-1-peter.ujfalusi@ti.com
    Signed-off-by: Vinod Koul
    Signed-off-by: Sasha Levin

    Peter Ujfalusi
     
  • [ Upstream commit 0a4c56c80f90797e9b9f8426c6aae4c0cf1c9785 ]

    Commit ef91bb196b0d ("kernel.h: Silence sparse warning in
    lower_32_bits") caused new warnings to show in the fsldma driver, but
    that commit was not to blame: it only exposed some very incorrect code
    that tried to take the low 32 bits of an address.

    That made no sense for multiple reasons, the most notable one being that
    that code was intentionally limited to only 32-bit ppc builds, so "only
    low 32 bits of an address" was completely nonsensical. There were no
    high bits to mask off to begin with.

    But even more importantly fropm a correctness standpoint, turning the
    address into an integer then caused the subsequent address arithmetic to
    be completely wrong too, and the "+1" actually incremented the address
    by one, rather than by four.

    Which again was incorrect, since the code was reading two 32-bit values
    and trying to make a 64-bit end result of it all. Surprisingly, the
    iowrite64() did not suffer from the same odd and incorrect model.

    This code has never worked, but it's questionable whether anybody cared:
    of the two users that actually read the 64-bit value (by way of some C
    preprocessor hackery and eventually the 'get_cdar()' inline function),
    one of them explicitly ignored the value, and the other one might just
    happen to work despite the incorrect value being read.

    This patch at least makes it not fail the build any more, and makes the
    logic superficially sane. Whether it makes any difference to the code
    _working_ or not shall remain a mystery.

    Compile-tested-by: Guenter Roeck
    Reviewed-by: Guenter Roeck
    Signed-off-by: Linus Torvalds
    Signed-off-by: Sasha Levin

    Linus Torvalds
     

11 Aug, 2020

1 commit

  • ERR009165 are not fix on i.mx8m family, so remove 'ecspi_fixed' on
    sdma_imx8mq, otherwise, i.mx8mn ecspi not work in dma mode as below:

    [ 8163.444680] SPI transfer using DMA
    [ 8163.448144] SPI DMA tx transfer timer: 500
    [ 8165.468250] spi_imx 30820000.spi: I/O Error in DMA TX
    [ 8165.473353] spidev spi0.0: SPI transfer failed: -110
    [ 8165.478446] spi_master spi0: failed to transfer one message from queue

    Signed-off-by: Robin Gong
    Reviewed-by: Clark Wang

    Robin Gong
     

29 Jul, 2020

3 commits

  • [ Upstream commit 87730ccbddcb48478b1b88e88b14e73424130764 ]

    DMA transaction time to completion is a function of PCI bandwidth,
    transaction size and a queue depth. So hard coded value for timeouts
    might be wrong for some scenarios.

    Signed-off-by: Leonid Ravich
    Reviewed-by: Dave Jiang
    Link: https://lore.kernel.org/r/20200701184816.29138-1-leonid.ravich@dell.com
    Signed-off-by: Vinod Koul
    Signed-off-by: Sasha Levin

    Leonid Ravich
     
  • [ Upstream commit 8678c71c17721e0f771f135967ef0cce8f69ce9a ]

    Due to recent fixes in m68k arch-specific I/O accessor macros, this
    driver is not working anymore for ColdFire. Fix wrong tcd endianness
    removing additional swaps, since edma_writex() functions should already
    take care of any eventual swap if needed.

    Note, i could only test the change in ColdFire mcf54415 and Vybrid
    vf50 / Colibri where i don't see any issue. So, every feedback and
    test for all other SoCs involved is really appreciated.

    Signed-off-by: Angelo Dureghello
    Reported-by: kbuild test robot
    Link: https://lore.kernel.org/r/20200701225205.1674463-1-angelo.dureghello@timesys.com
    Signed-off-by: Vinod Koul
    Signed-off-by: Sasha Levin

    Angelo Dureghello
     
  • [ Upstream commit 5b78fac4b1ba731cf4177fdbc1e3a4661521bcd0 ]

    pm_runtime_get_sync() increments the runtime PM usage counter even
    when it returns an error code. Thus a pairing decrement is needed on
    the error handling path to keep the counter balanced.

    Signed-off-by: Dinghao Liu
    Reviewed-by: Jon Hunter
    Link: https://lore.kernel.org/r/20200624064626.19855-1-dinghao.liu@zju.edu.cn
    Signed-off-by: Vinod Koul
    Signed-off-by: Sasha Levin

    Dinghao Liu
     

22 Jul, 2020

6 commits

  • commit e142087b15960a4e1e5932942e5abae1f49d2318 upstream.

    Correct EDMA_TCD_ATTR_DSIZE_32BYTE define since it's broken by the below:
    '0x0005 --> BIT(3) | BIT(0))'

    Fixes: 4d6d3a90e4ac ("dmaengine: fsl-edma: fix macros")
    Signed-off-by: Robin Gong
    Tested-by: Angelo Dureghello
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/r/1593449998-32091-1-git-send-email-yibin.gong@nxp.com
    Signed-off-by: Vinod Koul
    Signed-off-by: Greg Kroah-Hartman

    Robin Gong
     
  • commit 8995aa3d164ddd9200e6abcf25c449cf5298c858 upstream.

    On Toradex Colibri VF50 (Vybrid VF5xx) with fsl-edma driver NULL pointer
    exception happens occasionally on serial output initiated by login
    timeout.

    This was reproduced only if kernel was built with significant debugging
    options and EDMA driver is used with serial console.

    Issue looks like a race condition between interrupt handler
    fsl_edma_tx_handler() (called as a result of fsl_edma_xfer_desc()) and
    terminating the transfer with fsl_edma_terminate_all().

    The fsl_edma_tx_handler() handles interrupt for a transfer with already
    freed edesc and idle==true.

    The mcf-edma driver shares design and lot of code with fsl-edma. It
    looks like being affected by same problem. Fix this pattern the same
    way as fix for fsl-edma driver.

    Fixes: e7a3ff92eaf1 ("dmaengine: fsl-edma: add ColdFire mcf5441x edma support")
    Cc:
    Signed-off-by: Krzysztof Kozlowski
    Reviewed-by: Robin Gong
    Link: https://lore.kernel.org/r/1591881665-25592-1-git-send-email-krzk@kernel.org
    Signed-off-by: Vinod Koul
    Signed-off-by: Greg Kroah-Hartman

    Krzysztof Kozlowski
     
  • commit f5e5677c420346b4e9788051c2e4d750996c428c upstream.

    NULL pointer exception happens occasionally on serial output initiated
    by login timeout. This was reproduced only if kernel was built with
    significant debugging options and EDMA driver is used with serial
    console.

    col-vf50 login: root
    Password:
    Login timed out after 60 seconds.
    Unable to handle kernel NULL pointer dereference at virtual address 00000044
    Internal error: Oops: 5 [#1] ARM
    CPU: 0 PID: 157 Comm: login Not tainted 5.7.0-next-20200610-dirty #4
    Hardware name: Freescale Vybrid VF5xx/VF6xx (Device Tree)
    (fsl_edma_tx_handler) from [] (__handle_irq_event_percpu+0x64/0x304)
    (__handle_irq_event_percpu) from [] (handle_irq_event_percpu+0x2c/0x7c)
    (handle_irq_event_percpu) from [] (handle_irq_event+0x38/0x5c)
    (handle_irq_event) from [] (handle_fasteoi_irq+0xa4/0x160)
    (handle_fasteoi_irq) from [] (generic_handle_irq+0x34/0x44)
    (generic_handle_irq) from [] (__handle_domain_irq+0x54/0xa8)
    (__handle_domain_irq) from [] (gic_handle_irq+0x4c/0x80)
    (gic_handle_irq) from [] (__irq_svc+0x70/0x98)
    Exception stack(0x8459fe80 to 0x8459fec8)
    fe80: 72286b00 e3359f64 00000001 0000412d a0070013 85c98840 85c98840 a0070013
    fea0: 8054e0d4 00000000 00000002 00000000 00000002 8459fed0 8081fbe8 8081fbec
    fec0: 60070013 ffffffff
    (__irq_svc) from [] (_raw_spin_unlock_irqrestore+0x30/0x58)
    (_raw_spin_unlock_irqrestore) from [] (uart_flush_buffer+0x88/0xf8)
    (uart_flush_buffer) from [] (tty_ldisc_hangup+0x38/0x1ac)
    (tty_ldisc_hangup) from [] (__tty_hangup+0x158/0x2bc)
    (__tty_hangup) from [] (disassociate_ctty.part.1+0x30/0x23c)
    (disassociate_ctty.part.1) from [] (do_exit+0x580/0xba0)
    (do_exit) from [] (do_group_exit+0x3c/0xb4)
    (do_group_exit) from [] (__wake_up_parent+0x0/0x14)

    Issue looks like race condition between interrupt handler fsl_edma_tx_handler()
    (called as result of fsl_edma_xfer_desc()) and terminating the transfer with
    fsl_edma_terminate_all().

    The fsl_edma_tx_handler() handles interrupt for a transfer with already freed
    edesc and idle==true.

    Fixes: d6be34fbd39b ("dma: Add Freescale eDMA engine driver support")
    Signed-off-by: Krzysztof Kozlowski
    Reviewed-by: Robin Gong
    Cc:
    Link: https://lore.kernel.org/r/1591877861-28156-2-git-send-email-krzk@kernel.org
    Signed-off-by: Vinod Koul
    Signed-off-by: Greg Kroah-Hartman

    Krzysztof Kozlowski
     
  • [ Upstream commit fd17d1abce426b4224a916a242b57be94272771b ]

    The completed threads were not cleared and consequent run would result
    threads accumulating:

    echo 800000 > /sys/module/dmatest/parameters/test_buf_size
    echo 2000 > /sys/module/dmatest/parameters/timeout
    echo 50 > /sys/module/dmatest/parameters/iterations
    echo 1 > /sys/module/dmatest/parameters/max_channels
    echo "" > /sys/module/dmatest/parameters/channel
    [ 237.507265] dmatest: Added 1 threads using dma1chan2
    echo 1 > /sys/module/dmatest/parameters/run
    [ 244.713360] dmatest: Started 1 threads using dma1chan2
    [ 246.117680] dmatest: dma1chan2-copy0: summary 50 tests, 0 failures 2437.47 iops 977623 KB/s (0)

    echo 1 > /sys/module/dmatest/parameters/run
    [ 292.381471] dmatest: No channels configured, continue with any
    [ 292.389307] dmatest: Added 1 threads using dma1chan3
    [ 292.394302] dmatest: Started 1 threads using dma1chan2
    [ 292.399454] dmatest: Started 1 threads using dma1chan3
    [ 293.800835] dmatest: dma1chan3-copy0: summary 50 tests, 0 failures 2624.53 iops 975014 KB/s (0)

    echo 1 > /sys/module/dmatest/parameters/run
    [ 307.301429] dmatest: No channels configured, continue with any
    [ 307.309212] dmatest: Added 1 threads using dma1chan4
    [ 307.314197] dmatest: Started 1 threads using dma1chan2
    [ 307.319343] dmatest: Started 1 threads using dma1chan3
    [ 307.324492] dmatest: Started 1 threads using dma1chan4
    [ 308.730773] dmatest: dma1chan4-copy0: summary 50 tests, 0 failures 2390.28 iops 965436 KB/s (0)

    Fixes: 6b41030fdc79 ("dmaengine: dmatest: Restore default for channel")
    Reported-by: Grygorii Strashko
    Signed-off-by: Peter Ujfalusi
    Link: https://lore.kernel.org/r/20200701101225.8607-1-peter.ujfalusi@ti.com
    Signed-off-by: Vinod Koul
    Signed-off-by: Sasha Levin

    Peter Ujfalusi
     
  • [ Upstream commit 99ba8b9b0d9780e9937eb1d488d120e9e5c2533d ]

    In some cases DMA can be used only with a consumer which does runtime power
    management and on the platforms, that have DMA auto power gating logic
    (see comments in the drivers/acpi/acpi_lpss.c), may result in DMA losing
    its context. Simple mitigation of this issue is to initialize channel
    each time the consumer initiates a transfer.

    Fixes: cfdf5b6cc598 ("dw_dmac: add support for Lynxpoint DMA controllers")
    Reported-by: Tsuchiya Yuto
    Signed-off-by: Andy Shevchenko
    Acked-by: Viresh Kumar
    BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=206403
    Link: https://lore.kernel.org/r/20200705115620.51929-1-andriy.shevchenko@linux.intel.com
    Signed-off-by: Vinod Koul
    Signed-off-by: Sasha Levin

    Andy Shevchenko
     
  • [ Upstream commit 466257d9968ac79575831250b039dc07566c7b13 ]

    A client driver (renesas_usbhs) assumed that
    dmaengine_tx_status() could return the residue even if
    the transfer was completed. However, this was not correct
    usage [1] and this caused to break getting the residue after
    the commit 24461d9792c2 ("dmaengine: virt-dma: Fix access after
    free in vchan_complete()") actually. So, this is possible to get
    wrong received size if the usb controller gets a short packet.
    For example, g_zero driver causes "bad OUT byte" errors.

    To use the tx_result from the renesas_usbhs driver when
    the transfer is completed, set the tx_result parameters.

    Notes that the renesas_usbhs driver needs to update for it.

    [1]
    https://lore.kernel.org/dmaengine/20200616165550.GP2324254@vkoul-mobl/

    Reported-by: Hien Dang
    Fixes: 24461d9792c2 ("dmaengine: virt-dma: Fix access after free in vchan_complete()")
    Signed-off-by: Yoshihiro Shimoda
    Link: https://lore.kernel.org/r/1592482053-19433-1-git-send-email-yoshihiro.shimoda.uh@renesas.com
    Signed-off-by: Vinod Koul
    Signed-off-by: Sasha Levin

    Yoshihiro Shimoda
     

06 Jul, 2020

3 commits


19 Jun, 2020

1 commit

  • * tag 'v5.4.47': (2193 commits)
    Linux 5.4.47
    KVM: arm64: Save the host's PtrAuth keys in non-preemptible context
    KVM: arm64: Synchronize sysreg state on injecting an AArch32 exception
    ...

    Conflicts:
    arch/arm/boot/dts/imx6qdl.dtsi
    arch/arm/mach-imx/Kconfig
    arch/arm/mach-imx/common.h
    arch/arm/mach-imx/suspend-imx6.S
    arch/arm64/boot/dts/freescale/imx8qxp-mek.dts
    arch/powerpc/include/asm/cacheflush.h
    drivers/cpufreq/imx6q-cpufreq.c
    drivers/dma/imx-sdma.c
    drivers/edac/synopsys_edac.c
    drivers/firmware/imx/imx-scu.c
    drivers/net/ethernet/freescale/fec.h
    drivers/net/ethernet/freescale/fec_main.c
    drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
    drivers/net/phy/phy_device.c
    drivers/perf/fsl_imx8_ddr_perf.c
    drivers/usb/cdns3/gadget.c
    drivers/usb/dwc3/gadget.c
    include/uapi/linux/dma-buf.h

    Signed-off-by: Jason Liu

    Jason Liu
     

27 May, 2020

3 commits

  • commit f8f482deb078389b42768b2193e050a81aae137d upstream.

    When the kernel is built with lockdep support and the owl-dma driver is
    used, the following message is shown:

    [ 2.496939] INFO: trying to register non-static key.
    [ 2.501889] the code is fine but needs lockdep annotation.
    [ 2.507357] turning off the locking correctness validator.
    [ 2.512834] CPU: 0 PID: 12 Comm: kworker/0:1 Not tainted 5.6.3+ #15
    [ 2.519084] Hardware name: Generic DT based system
    [ 2.523878] Workqueue: events_freezable mmc_rescan
    [ 2.528681] [] (unwind_backtrace) from [] (show_stack+0x10/0x14)
    [ 2.536420] [] (show_stack) from [] (dump_stack+0xb4/0xe0)
    [ 2.543645] [] (dump_stack) from [] (register_lock_class+0x6f0/0x718)
    [ 2.551816] [] (register_lock_class) from [] (__lock_acquire+0x78/0x25f0)
    [ 2.560330] [] (__lock_acquire) from [] (lock_acquire+0xd8/0x1f4)
    [ 2.568159] [] (lock_acquire) from [] (_raw_spin_lock_irqsave+0x3c/0x50)
    [ 2.576589] [] (_raw_spin_lock_irqsave) from [] (owl_dma_issue_pending+0xbc/0x120)
    [ 2.585884] [] (owl_dma_issue_pending) from [] (owl_mmc_request+0x1b0/0x390)
    [ 2.594655] [] (owl_mmc_request) from [] (mmc_start_request+0x94/0xbc)
    [ 2.602906] [] (mmc_start_request) from [] (mmc_wait_for_req+0x64/0xd0)
    [ 2.611245] [] (mmc_wait_for_req) from [] (mmc_app_send_scr+0x10c/0x144)
    [ 2.619669] [] (mmc_app_send_scr) from [] (mmc_sd_setup_card+0x4c/0x318)
    [ 2.628092] [] (mmc_sd_setup_card) from [] (mmc_sd_init_card+0x104/0x430)
    [ 2.636601] [] (mmc_sd_init_card) from [] (mmc_attach_sd+0xcc/0x16c)
    [ 2.644678] [] (mmc_attach_sd) from [] (mmc_rescan+0x3ac/0x40c)
    [ 2.652332] [] (mmc_rescan) from [] (process_one_work+0x2d8/0x780)
    [ 2.660239] [] (process_one_work) from [] (worker_thread+0x44/0x598)
    [ 2.668323] [] (worker_thread) from [] (kthread+0x148/0x150)
    [ 2.675708] [] (kthread) from [] (ret_from_fork+0x14/0x20)
    [ 2.682912] Exception stack(0xee8fdfb0 to 0xee8fdff8)
    [ 2.687954] dfa0: 00000000 00000000 00000000 00000000
    [ 2.696118] dfc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
    [ 2.704277] dfe0: 00000000 00000000 00000000 00000000 00000013 00000000

    The obvious fix would be to use 'spin_lock_init()' on 'pchan->lock'
    before attempting to call 'spin_lock_irqsave()' in 'owl_dma_get_pchan()'.

    However, according to Manivannan Sadhasivam, 'pchan->lock' was supposed
    to only protect 'pchan->vchan' while 'od->lock' does a similar job in
    'owl_dma_terminate_pchan()'.

    Therefore, this patch substitutes 'pchan->lock' with 'od->lock' and
    removes the 'lock' attribute in 'owl_dma_pchan' struct.

    Fixes: 47e20577c24d ("dmaengine: Add Actions Semi Owl family S900 DMA driver")
    Signed-off-by: Cristian Ciocaltea
    Reviewed-by: Manivannan Sadhasivam
    Acked-by: Andreas Färber
    Link: https://lore.kernel.org/r/c6e6cdaca252b5364bd294093673951036488cf0.1588439073.git.cristian.ciocaltea@gmail.com
    Signed-off-by: Vinod Koul
    Signed-off-by: Greg Kroah-Hartman

    Cristian Ciocaltea
     
  • commit 6b41030fdc79086db5d673c5ed7169f3ee8c13b9 upstream.

    In case of dmatest is built-in and no channel was configured test
    doesn't run with:

    dmatest: Could not start test, no channels configured

    Even though description to "channel" parameter claims that default is
    any.

    Add default channel back as it used to be rather than reject test with
    no channel configuration.

    Fixes: d53513d5dc285d9a95a534fc41c5c08af6b60eac ("dmaengine: dmatest: Add support for multi channel testing)
    Reported-by: Dijil Mohan
    Signed-off-by: Vladimir Murzin
    Link: https://lore.kernel.org/r/20200429071522.58148-1-vladimir.murzin@arm.com
    Signed-off-by: Vinod Koul
    Signed-off-by: Greg Kroah-Hartman

    Vladimir Murzin
     
  • commit 3a5fd0dbd87853f8bd2ea275a5b3b41d6686e761 upstream.

    Commit b53611fb1ce9 ("dmaengine: tegra210-adma: Fix crash during probe")
    has moved some code in the probe function and reordered the error handling
    path accordingly.
    However, a goto has been missed.

    Fix it and goto the right label if 'dma_async_device_register()' fails, so
    that all resources are released.

    Fixes: b53611fb1ce9 ("dmaengine: tegra210-adma: Fix crash during probe")
    Signed-off-by: Christophe JAILLET
    Reviewed-by: Jon Hunter
    Acked-by: Thierry Reding
    Link: https://lore.kernel.org/r/20200516214205.276266-1-christophe.jaillet@wanadoo.fr
    Signed-off-by: Vinod Koul
    Signed-off-by: Greg Kroah-Hartman

    Christophe JAILLET
     

26 May, 2020

1 commit


20 May, 2020

4 commits

  • The legacy terminate_worker may terminate the next transfer if it comes
    before all jobs done in terminated_worker, or refuse to setup next transfer
    since sdmac->desc may not be NULL in sdma_issue_pending(). That case could
    be easily caught in Audio play in case underrun happen at ALSA level which
    means dma channel will be terminated and start again very frequently.
    So move the logic part of 'sdmac->desc' into sdma_disable_channel_async but
    leave the desc free in the work to kill the above case.

    Signed-off-by: Robin Gong

    Robin Gong
     
  • [ Upstream commit 0c89446379218698189a47871336cb30286a7197 ]

    When a channel configuration fails, the status of the channel is set to
    DEV_ERROR so that an attempt to submit it fails. However, this status
    sticks until the heat end of the universe, making it impossible to
    recover from the error.

    Let's reset it when the channel is released so that further use of the
    channel with correct configuration is not impacted.

    Signed-off-by: Lubomir Rintel
    Link: https://lore.kernel.org/r/20200419164912.670973-5-lkundrak@v3.sk
    Signed-off-by: Vinod Koul
    Signed-off-by: Sasha Levin

    Lubomir Rintel
     
  • [ Upstream commit 363c32701c7fdc8265a84b21a6a4f45d1202b9ca ]

    With an invalid dma_slave_config set previously,
    mmp_tdma_prep_dma_cyclic() would detect an error whilst configuring the
    channel, but proceed happily on:

    [ 120.756530] mmp-tdma d42a0800.adma: mmp_tdma: unknown burst size.

    Signed-off-by: Lubomir Rintel
    Link: https://lore.kernel.org/r/20200419164912.670973-2-lkundrak@v3.sk
    Signed-off-by: Vinod Koul
    Signed-off-by: Sasha Levin

    Lubomir Rintel
     
  • [ Upstream commit 2e45676a4d33af47259fa186ea039122ce263ba9 ]

    pd->dma.dev is read in irq handler pd_irq().
    However, it is set to pdev->dev after request_irq().
    Therefore, set pd->dma.dev to pdev->dev before request_irq() to
    avoid data race between pch_dma_probe() and pd_irq().

    Found by Linux Driver Verification project (linuxtesting.org).

    Signed-off-by: Madhuparna Bhowmik
    Link: https://lore.kernel.org/r/20200416062335.29223-1-madhuparnabhowmik10@gmail.com
    Signed-off-by: Vinod Koul
    Signed-off-by: Sasha Levin

    Madhuparna Bhowmik
     

07 May, 2020

3 commits