1. 04 6月, 2020 1 次提交
    • T
      ALSA: usb-audio: Fix inconsistent card PM state after resume · 862b2509
      Takashi Iwai 提交于
      When a USB-audio interface gets runtime-suspended via auto-pm feature,
      the driver suspends all functionality and increment
      chip->num_suspended_intf.  Later on, when the system gets suspended to
      S3, the driver increments chip->num_suspended_intf again, skips the
      device changes, and sets the card power state to
      SNDRV_CTL_POWER_D3hot.  In return, when the system gets resumed from
      S3, the resume callback decrements chip->num_suspended_intf.  Since
      this refcount is still not zero (it's been runtime-suspended), the
      whole resume is skipped.  But there is a small pitfall here.
      
      The problem is that the driver doesn't restore the card power state
      after this resume call, leaving it as SNDRV_CTL_POWER_D3hot.  So,
      even after the system resume finishes, the card instance still appears
      as if it were system-suspended, and this confuses many ioctl accesses
      that are blocked unexpectedly.
      
      In details, we have two issues behind the scene: one is that the card
      power state is changed only when the refcount becomes zero, and
      another is that the prior auto-suspend check is kept in a boolean
      flag.  Although the latter problem is almost negligible since the
      auto-pm feature is imposed only on the primary interface, but this can
      be a potential problem on the devices with multiple interfaces.
      
      This patch addresses those issues by the following:
      
      - Replace chip->autosuspended boolean flag with chip->system_suspend
        counter
      
      - At the first system-suspend, chip->num_suspended_intf is recorded to
        chip->system_suspend
      
      - At system-resume, the card power state is restored when the
        chip->num_suspended_intf refcount reaches to chip->system_suspend,
        i.e. the state returns to the auto-suspended
      
      Also, the patch fixes yet another hidden problem by the code
      refactoring along with the fixes above: namely, when some resume
      procedure failed, the driver left chip->num_suspended_intf that was
      already decreased, and it might lead to the refcount unbalance.
      In the new code, the refcount decrement is done after the whole resume
      procedure, and the problem is avoided as well.
      
      Fixes: 0662292a ("ALSA: usb-audio: Handle normal and auto-suspend equally")
      Reported-and-tested-by: NMacpaul Lin <macpaul.lin@mediatek.com>
      Cc: <stable@vger.kernel.org>
      Link: https://lore.kernel.org/r/20200603153709.6293-1-tiwai@suse.deSigned-off-by: NTakashi Iwai <tiwai@suse.de>
      862b2509
  2. 03 6月, 2020 2 次提交
  3. 02 6月, 2020 2 次提交
  4. 01 6月, 2020 3 次提交
    • M
      358c7c61
    • M
      a72ff08f
    • J
      ASoC: qcom: q6asm-dai: kCFI fix · a6b675a8
      John Stultz 提交于
      Fixes the following kCFI crash seen on db845c, caused
      by the function prototypes not matching the callback
      function prototype.
      
      [   82.585661] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000001
      [   82.595387] Mem abort info:
      [   82.599463]   ESR = 0x96000005
      [   82.602658]   EC = 0x25: DABT (current EL), IL = 32 bits
      [   82.608177]   SET = 0, FnV = 0
      [   82.611829]   EA = 0, S1PTW = 0
      [   82.615369] Data abort info:
      [   82.618751]   ISV = 0, ISS = 0x00000005
      [   82.622641]   CM = 0, WnR = 0
      [   82.625774] user pgtable: 4k pages, 39-bit VAs, pgdp=0000000174259000
      [   82.632292] [0000000000000001] pgd=0000000000000000, pud=0000000000000000
      [   82.639167] Internal error: Oops: 96000005 [#1] PREEMPT SMP
      [   82.644795] Modules linked in: hci_uart btqca xhci_plat_hcd xhci_pci_renesas xhci_pci xhci_hcd wcn36xx wcnss_ctrl wcd934x vctrl_regulator ufs_qcom syscon_reboot_e
      [   82.644927]  qcom_apcs_ipc_mailbox q6asm_dai q6routing q6asm q6afe_dai q6adm q6afe q6core q6dsp_common pm8941_pwrkey pm8916_wdt platform_mhu pinctrl_spmi_mpp pine
      [   82.812982] CPU: 3 PID: 240 Comm: kworker/u16:4 Tainted: G        W         5.6.0-rc7-mainline-00960-g0c34353d11b9-dirty #1
      [   82.824201] Hardware name: Thundercomm Dragonboard 845c (DT)
      [   82.829937] Workqueue: qcom_apr_rx apr_rxwq [apr]
      [   82.834698] pstate: 80c00005 (Nzcv daif +PAN +UAO)
      [   82.839553] pc : __cfi_check_fail+0x4/0x1c [q6asm_dai]
      [   82.844754] lr : __cfi_check+0x3a8/0x3b0 [q6asm_dai]
      [   82.849767] sp : ffffffc0105f3c20
      [   82.853123] x29: ffffffc0105f3c30 x28: 0000000000000020
      [   82.858489] x27: ffffff80f4588400 x26: ffffff80f458ec94
      [   82.863854] x25: ffffff80f458ece8 x24: ffffffe3670c7000
      [   82.869220] x23: ffffff8094bb7b34 x22: ffffffe367137000
      [   82.874585] x21: bd07909b332eada6 x20: 0000000000000001
      [   82.879950] x19: ffffffe36713863c x18: ffffff80f8df4430
      [   82.885316] x17: 0000000000000001 x16: ffffffe39d15e660
      [   82.890681] x15: 0000000000000001 x14: 0000000000000027
      [   82.896047] x13: 0000000000000000 x12: ffffffe39e6465a0
      [   82.901413] x11: 0000000000000051 x10: 000000000000ffff
      [   82.906779] x9 : 000ffffffe366c19 x8 : c3c5f18762d1ceef
      [   82.912145] x7 : 0000000000000000 x6 : ffffffc010877698
      [   82.917511] x5 : ffffffc0105f3c00 x4 : 0000000000000000
      [   82.922877] x3 : 0000000000000000 x2 : 0000000000000001
      [   82.928243] x1 : ffffffe36713863c x0 : 0000000000000001
      [   82.933610] Call trace:
      [   82.936099]  __cfi_check_fail+0x4/0x1c [q6asm_dai]
      [   82.940955]  q6asm_srvc_callback+0x22c/0x618 [q6asm]
      [   82.945973]  apr_rxwq+0x1a8/0x27c [apr]
      [   82.949861]  process_one_work+0x2e8/0x54c
      [   82.953919]  worker_thread+0x27c/0x4d4
      [   82.957715]  kthread+0x144/0x154
      [   82.960985]  ret_from_fork+0x10/0x18
      [   82.964603] Code: a8c37bfd f85f8e5e d65f03c0 b40000a0 (39400008)
      [   82.970762] ---[ end trace 410accb839617143 ]---
      [   82.975429] Kernel panic - not syncing: Fatal exception
      Signed-off-by: NJohn Stultz <john.stultz@linaro.org>
      Reviewed-by: NSrinivas Kandagatla <srinivas.kandagatla@linaro.org>
      Cc: Patrick Lai <plai@codeaurora.org>
      Cc: Banajit Goswami <bgoswami@codeaurora.org>
      Cc: Liam Girdwood <lgirdwood@gmail.com>
      Cc: Mark Brown <broonie@kernel.org>
      Cc: Jaroslav Kysela <perex@perex.cz>
      Cc: Takashi Iwai <tiwai@suse.com>
      Cc: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
      Cc: Vinod Koul <vkoul@kernel.org>
      Cc: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
      Cc: Stephan Gerhold <stephan@gerhold.net>
      Cc: Sami Tolvanen <samitolvanen@google.com>
      Cc: Todd Kjos <tkjos@google.com>
      Cc: Alistair Delva <adelva@google.com>
      Cc: Amit Pundir <amit.pundir@linaro.org>
      Cc: Sumit Semwal <sumit.semwal@linaro.org>
      Cc: alsa-devel@alsa-project.org
      Link: https://lore.kernel.org/r/20200529213823.98812-1-john.stultz@linaro.orgSigned-off-by: NMark Brown <broonie@kernel.org>
      a6b675a8
  5. 30 5月, 2020 26 次提交
  6. 29 5月, 2020 6 次提交