25 Mar, 2019

1 commit


24 Mar, 2019

7 commits


23 Mar, 2019

1 commit

  • Some rpmsg user may require rpmsg resume before the user start
    handle its irq, e.g the typec controller use a GPIO as irq and
    use rpmsg to get event status, so move imx rpmsg power management
    ops to noirq phrase.

    Reviewed-by: Richard Zhu
    Tested-by: Clark Wang
    Signed-off-by: Anson Huang
    Signed-off-by: Li Jun

    Anson Huang
     

22 Mar, 2019

6 commits

  • Changing error message "Link rate is too high - forcing link to lower rate"
    to a debug message "Lowering DP link rate from to ".

    Signed-off-by: Oliver Brown

    Oliver Brown
     
  • Although the hardware spec doesn't mention the additional operation to
    wait for FrameGen secondary syncup for non-PC cases(FrameGen non-sync mode)
    when we enable a display, it turns out it helps avoid content stream(i.e.,
    extdst0 or extdst1) shadow load done event missing issue when the first
    page flip ocurrs after the display enablement. Black/blanked display
    is observed when the issue happens, which means the video signal is likely
    totally off. Adding this waiting operation also aligns to the cases
    where PC is used.

    Signed-off-by: Liu Ying
    (cherry picked from commit cfedc1269f35054c79d7fd2e2a914e97a4c1a47a)

    Liu Ying
     
  • Another coming patch will wait for framegen secondary channel syncup
    for non-sync mode cases. It appears that waiting for 50ms for video
    modes like 1920x1080p@24 and 1920x1080p@30 is not enough. So, this
    patch increases the timeout value to 100ms.

    Signed-off-by: Liu Ying
    (cherry picked from commit 5357bce465db659d69a5026882a899f2077ee078)

    Liu Ying
     
  • When the interrupt occurs during the USB is entering suspend, the
    cdns->lpm flag may not be updated well, the below oops may occur.
    We treat above interrupt as wakeup interrupt, it should be handled
    after lpm flag is set.

    irq 120: nobody cared (try booting with the "irqpoll" option)
    CPU: 0 PID: 107 Comm: kworker/0:1 Tainted: G O 4.14.78 #1
    Hardware name: Freescale i.MX8QM MEK (DT)
    Workqueue: pm pm_runtime_work
    Call trace:
    [] el1_irq+0xb0/0x124
    [] _raw_spin_unlock_irqrestore+0x18/0x48
    [] __irq_put_desc_unlock+0x1c/0x44
    [] enable_irq+0x54/0x90
    [] cdns3_enter_suspend+0x30c/0x3ac
    [] cdns3_runtime_suspend+0x40/0x78
    [] pm_generic_runtime_suspend+0x28/0x48
    [] genpd_runtime_suspend+0x90/0x21c
    [] __rpm_callback+0x130/0x264
    [] rpm_callback+0x24/0x78
    [] rpm_suspend+0x10c/0x668
    [] rpm_idle+0x1c0/0x390
    [] pm_runtime_work+0x94/0xe0
    [] process_one_work+0x140/0x3f8
    [] worker_thread+0x138/0x3e4
    [] kthread+0x104/0x130
    [] ret_from_fork+0x10/0x18

    Signed-off-by: Peter Chen

    Peter Chen
     
  • Signed-off-by: ming_qian

    ming_qian
     
  • Error implement in function CDN_API_DPTX_ForceLanes_blocking,
    it should call function CDN_API_DPTX_ForceLanes.

    Signed-off-by: Sandor Yu
    (cherry picked from commit 458736a5adeec6527dc86de5993c7ddec84daa15)

    Sandor Yu
     

21 Mar, 2019

9 commits

  • Add support for suspend and resume operation for PM in CAAM driver.

    When the CAAM goes in suspend, the hardware is considered to do nothing.

    On some platforms, the power of the CAAM is not turned off so it keeps
    its configuration.

    On other platforms, it doesn't so it is necessary to save the state of
    the CAAM:
    - JRs MID
    - Address of input and output rings

    Limitation:
    When the CAAM is powered OFF, it is resetted so the JDKEK and TDKEK
    changes. This impacts crypto transforms using MDHA split-keys
    which are kept over suspend as they are encrypted with the JDKEK:
    - hmac(*) from caamhash.c
    - authenc(hmac(*),*) from caamalg.c
    - echainiv(authenc(hmac(*),*)) from caamalg.c
    The issue was already present in current code so this patch does not
    add a regression in this regard.

    Reviewed-by: Horia Geantă
    Signed-off-by: Franck LENORMAND
    (cherry picked from commit b90e25f285a65ee8c8433aba7fe8b19b2cdf70b9)

    Franck LENORMAND
     
  • The structure partid is not suitable to represent the DECO MID register.

    This patch replace partid by masterid which is more appropriate.

    Reviewed-by: Horia Geantă
    Signed-off-by: Franck LENORMAND
    (cherry picked from commit 49d6d90809cb04ae3a63e7e87f670014ab5da0a1)

    Franck LENORMAND
     
  • The previous patch create a DMA issue detected with
    DMA debug as the size unmapped is not always the size
    mapped.

    Signed-off-by: Franck LENORMAND
    (cherry picked from commit 00bd0d58f4d339d0488c4eb102e34e70edd017ee)

    Franck LENORMAND
     
  • Roland reports the following issue and provides a root cause analysis:

    "On a v4.19 i.MX6 system with IMA and CONFIG_DMA_API_DEBUG enabled, a
    warning is generated when accessing files on a filesystem for which IMA
    measurement is enabled:

    ------------[ cut here ]------------
    WARNING: CPU: 0 PID: 1 at kernel/dma/debug.c:1181 check_for_stack.part.9+0xd0/0x120
    caam_jr 2101000.jr0: DMA-API: device driver maps memory from stack [addr=b668049e]
    Modules linked in:
    CPU: 0 PID: 1 Comm: switch_root Not tainted 4.19.0-20181214-1 #2
    Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
    Backtrace:
    [] (dump_backtrace) from [] (show_stack+0x20/0x24)
    [] (show_stack) from [] (dump_stack+0xa0/0xcc)
    [] (dump_stack) from [] (__warn+0xf0/0x108)
    [] (__warn) from [] (warn_slowpath_fmt+0x58/0x74)
    [] (warn_slowpath_fmt) from [] (check_for_stack.part.9+0xd0/0x120)
    [] (check_for_stack.part.9) from [] (debug_dma_map_page+0x144/0x174)
    [] (debug_dma_map_page) from [] (ahash_final_ctx+0x5b4/0xcf0)
    [] (ahash_final_ctx) from [] (ahash_final+0x1c/0x20)
    [] (ahash_final) from [] (crypto_ahash_op+0x38/0x80)
    [] (crypto_ahash_op) from [] (crypto_ahash_final+0x20/0x24)
    [] (crypto_ahash_final) from [] (ima_calc_file_hash+0x29c/0xa40)
    [] (ima_calc_file_hash) from [] (ima_collect_measurement+0x1dc/0x240)
    [] (ima_collect_measurement) from [] (process_measurement+0x4c4/0x6b8)
    [] (process_measurement) from [] (ima_file_check+0x88/0xa4)
    [] (ima_file_check) from [] (path_openat+0x5d8/0x1364)
    [] (path_openat) from [] (do_filp_open+0x84/0xf0)
    [] (do_filp_open) from [] (do_open_execat+0x84/0x1b0)
    [] (do_open_execat) from [] (__do_execve_file+0x43c/0x890)
    [] (__do_execve_file) from [] (sys_execve+0x44/0x4c)
    [] (sys_execve) from [] (ret_fast_syscall+0x0/0x28)
    ---[ end trace 3455789a10e3aefd ]---

    The cause is that the struct ahash_request *req is created as a
    stack-local variable up in the stack (presumably somewhere in the IMA
    implementation), then passed down into the CAAM driver, which tries to
    dma_single_map the req->result (indirectly via map_seq_out_ptr_result)
    in order to make that buffer available for the CAAM to store the result
    of the following hash operation.

    The calling code doesn't know how req will be used by the CAAM driver,
    and there could be other such occurrences where stack memory is passed
    down to the CAAM driver. Therefore we should rather fix this issue in
    the CAAM driver where the requirements are known."

    Fix this problem by:
    -instructing the crypto engine to write the final hash in state->caam_ctx
    -subsequently memcpy-ing the final hash into req->result

    Reported-by: Roland Hieber
    Signed-off-by: Horia Geantă
    Signed-off-by: Franck LENORMAND
    (cherry picked from commit d8e87d0a42ce7ff9d96c4197c8df4b22e181c780)

    Franck LENORMAND
     
  • If CONFIG_KASAN enabled, gpu kernel driver will throw out the following error:

    drivers/mxc/gpu-viv/hal/kernel/gc_hal_kernel_command.c: In function ‘gckCOMMAND_Commit’:
    rivers/mxc/gpu-viv/hal/kernel/gc_hal_kernel_command.c:2646:1: error:
    the frame size of 2784 bytes is larger than 2048 bytes [-Werror=frame-larger-than=]

    Signed-off-by: Xianzhong
    (cherry picked from commit d5237ed9bca46858875a9b0ef4134ad477832102)

    Xianzhong
     
  • This reverts commit ae7756f53980f6d6bde1a72ea0798c5341c764fb.

    Root cause identified, the issue of stream mode only happens
    on imx8mm DDR4 board, because the DDR QoS setting is not correct.
    After the Qos setting change to be default value on imx8mm DDR4
    board, we can enable stream mode for USB device mode now.

    Acked-by: Peter Chen
    Signed-off-by: Li Jun
    (cherry picked from commit 4dad5065f1088197884de992be9adfed228197d9)

    Li Jun
     
  • Fixes: 944c01a889d9 ("spi: lpspi: enable runtime pm for lpspi")
    Signed-off-by: kbuild test robot
    Signed-off-by: Mark Brown

    kbuild test robot
     
  • set skip firmware bss flag when when driver clear firmware buffer.
    If driver didn't clear the buffer, and the flag is set.
    Something unexpected may happen.
    So clear firmware buffer before download firmware every times.

    Signed-off-by: ming_qian

    ming_qian
     
  • if seq header is not found before user streamoff.
    and user streamon again.
    the firmware is keeping parsing seq state.
    but it don't really parse seq header
    because it has been canceled by streamoff.
    The firmware needs driver trigger again to start parse next seq.
    In this case, driver will send stop cmd to firmware first,
    and send start cmd to firmware to restart parse seq header.
    And the user need transfer spspps before I frame again.

    Signed-off-by: ming_qian

    ming_qian
     

20 Mar, 2019

5 commits

  • on i.MX8

    We need to add property in DTS node before when we want to use normal
    mode on i.MX8 platform. Check in RM, we also can use CBT register not
    must CTRL1 register to set bitrate for normal mode.

    This patch intends to use CBT register to set bitrate for normal mode on
    i.MX8. After this, we don't need to modify the DTS node to support
    normal mode.

    Signed-off-by: Joakim Zhang

    Joakim Zhang
     
  • The alias ID must be defined in device tree, because
    that will be used as BUS ID to Cortex M4. If the alias ID
    not defined, linux kernel will automatically allocate one
    ID which might not be the same number used in Cortex M4 and
    Cortex M4 will not send msg to I2C controller.

    So let's add BUG_ON to catch issue as earlier as possible to avoid
    wasting efforts.

    Signed-off-by: Peng Fan
    Reviewed-by: Clark Wang

    Peng Fan
     
  • Remove the delay waiting, add the sync mechanism during partition reset.
    In order to avoid the hang at master side during the rpmsg restore
    procedure. Re-initialize the first_notify parameter, when rpmsg master
    assumes remote processor is dead.
    Otherwise, master side maybe hang during the rpmsg restore procedure
    in some corner cases.
    ~14ms is required by M4 to process the MU message from the cold boot.
    Set the max wait of MU_SendMessageTimeout to 20ms.

    Signed-off-by: Richard Zhu
    Reviewed-by: Robin Gong
    (cherry picked from commit 6b5573a9c645b947688c171b2dbdb6b70b59356c)

    Richard Zhu
     
  • Clear pending interrupt status of partition reboot during rpmsg
    driver probe to avoid to unregister/register virtio device again.

    Tested-by: Clark Wang
    Reviewed-by: Richard Zhu
    Signed-off-by: Fugang Duan

    Fugang Duan
     
  • in the former patch, the order of allocate dma buffer will be changed.
    if there is no enough memory, some error may occur.
    so revert the former change, and add lock for alloc and free dma

    Signed-off-by: ming_qian

    ming_qian
     

19 Mar, 2019

1 commit


18 Mar, 2019

9 commits

  • after seek
    replace flush_drv_q() with clear_queue()

    Signed-off-by: Shijie Qin

    Shijie Qin
     
  • Add the model name accordingly for imx7ulp EVKB board since
    the machine name and/or compatible may be used by user.

    Reviewed-by: Richard Zhu
    Signed-off-by: Fugang Duan

    Fugang Duan
     
  • Add security setting check for socket interface since
    stack will check the return value.

    Signed-off-by: Fugang Duan
    Signed-off-by: Marcel Holtmann

    Fugang Duan
     
  • commit 861cb5eb467f ("brcmfmac: Fix access point mode") upstream.

    Since commit 1204aa17f3b4 ("brcmfmac: set WIPHY_FLAG_HAVE_AP_SME flag")
    the Raspberry Pi 3 A+ (BCM43455) isn't able to operate in AP mode with
    hostapd (device_ap_sme=1 use_monitor=0):

    brcmfmac: brcmf_cfg80211_stop_ap: setting AP mode failed -52

    So add the missing mgmt_stypes for AP mode to fix this.

    Fixes: 1204aa17f3b4 ("brcmfmac: set WIPHY_FLAG_HAVE_AP_SME flag")
    Suggested-by: Arend van Spriel
    Signed-off-by: Stefan Wahren
    Acked-by: Arend van Spriel
    Signed-off-by: Kalle Valo

    Stefan Wahren
     
  • Remove the quirk for disable cyw4356 D3 mode since current FW
    already support it.
    This revert the commit 28db0ac248b3("MLK-20716 PCI: add quirk for
    cyw4356 to disable D3 mode")

    Reviewed-by: Richard Zhu
    Signed-off-by: Fugang Duan

    Fugang Duan
     
  • This patch fixes 43455 CRC error while running throughput test with
    suspend/resume stress test.

    The continuous failure messages before system crash:
    brcmfmac: brcmf_sdiod_sglist_rw: CMD53 sg block read failed -84
    brcmfmac: brcmf_sdio_rxglom: glom read of 25600 bytes failed: -5
    brcmfmac: brcmf_sdio_rxfail: abort command, terminate frame
    brcmfmac: brcmf_sdiod_sglist_rw: CMD53 sg block read failed -84
    brcmfmac: brcmf_sdio_rxglom: glom read of 24576 bytes failed: -5
    brcmfmac: brcmf_sdio_rxfail: abort command, terminate frame

    Signed-off-by: Wright Feng
    Signed-off-by: Fugang Duan

    Wright Feng
     
  • With asynchronous suspend/resume feature, suspend and resume callbacks to
    be executed in parallel with each other. It makes bus changes the state to
    BRCMF_BUS_DOWN before all brcmf_cfg80211_suspend IOVAR executions.
    The same situation also happens in resume procedure and causes PM mode
    keeps in PM_MAX after resume. In order to fix the race condition, We add
    one second sleep in bus suspend and cfg80211 resume function.

    Signed-off-by: Wright Feng
    Signed-off-by: Fugang Duan

    Wright Feng
     
  • We got ifp null pointer kernel panic in brcmf_txfinalize after removing
    Wi-Fi USB dongle when data was transmitting, The root cause is that
    interface was removed before calling brcmf_txfinalize in
    brcmf_fws_dequeue_worker and finally caused kernel panic.

    Signed-off-by: Wright Feng
    Signed-off-by: Fugang Duan

    Wright Feng
     
  • To trunkcate the addtional bytes, if extra bytes are received.
    Current code only have a warning and proceed without handling it.
    But in one crash dump reported by DVT, these causes the
    crash intermittently. So the processing is limit to the skb->len.

    Signed-off-by: Raveendran Somu
    Signed-off-by: Fugang Duan

    Raveendran Somu
     

15 Mar, 2019

1 commit