1. 08 Feb, 2019 2 commits
    • Takashi Iwai's avatar
      ALSA: pcm: Revert capture stream behavior change in blocking mode · 00a399ca
      Takashi Iwai authored
      In the commit 62ba568f ("ALSA: pcm: Return 0 when size <
      start_threshold in capture"), we changed the behavior of
      __snd_pcm_lib_xfer() to return immediately with 0 when a capture
      stream has a high start_threshold.  This was intended to be a
      correction of the behavior consistency and looked harmless, but this
      was the culprit of the recent breakage reported by syzkaller, which
      was fixed by the commit e190161f ("ALSA: pcm: Fix tight loop of
      OSS capture stream").
      
      At the time for the OSS fix, I didn't touch the behavior for ALSA
      native API, as assuming that this behavior actually is good.  But this
      turned out to be also broken actually for a similar deployment,
      e.g. one thread goes to a write loop in blocking mode while another
      thread controls the start/stop of the stream manually.
      
      Overall, the original commit is harmful, and it brings less merit to
      keep that behavior.  Let's revert it.
      
      Fixes: 62ba568f ("ALSA: pcm: Return 0 when size < start_threshold in capture")
      Fixes: e190161f ("ALSA: pcm: Fix tight loop of OSS capture stream")
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      00a399ca
    • Takashi Iwai's avatar
      Merge tag 'asoc-fix-v5.0-rc5' of... · 0a5cf9e8
      Takashi Iwai authored
      Merge tag 'asoc-fix-v5.0-rc5' of https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus
      
      ASoC: Fixes for v5.0
      
      A selection of driver specific fixes here, along with a few core fixes:
      
       - A fixup for some MFD devices that were broken by the previous fixes
         for deferred probe.
       - A fix for potential out of bounds array accesses when ordering DAPM
         power/up down sequences.
       - Avoid use after free issue when unloading and reloading drivers using
         topologies.
      0a5cf9e8
  2. 07 Feb, 2019 4 commits
    • Manuel Reinhardt's avatar
      ALSA: usb-audio: Fix implicit fb endpoint setup by quirk · 2bc16b9f
      Manuel Reinhardt authored
      The commit a60945fd ("ALSA: usb-audio: move implicit fb quirks to
      separate function") introduced an error in the handling of quirks for
      implicit feedback endpoints. This commit fixes this.
      
      If a quirk successfully sets up an implicit feedback endpoint, usb-audio
      no longer tries to find the implicit fb endpoint itself.
      
      Fixes: a60945fd ("ALSA: usb-audio: move implicit fb quirks to separate function")
      Signed-off-by: default avatarManuel Reinhardt <manuel.rhdt@gmail.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      2bc16b9f
    • Jurica Vukadin's avatar
      ALSA: hda - Add quirk for HP EliteBook 840 G5 · 4cd3016c
      Jurica Vukadin authored
      This enables mute LED support and fixes switching jacks when the laptop
      is docked.
      Signed-off-by: default avatarJurica Vukadin <jurica.vukadin@rt-rk.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      4cd3016c
    • Sylwester Nawrocki's avatar
      ASoC: samsung: Prevent clk_get_rate() calls in atomic context · 860b454c
      Sylwester Nawrocki authored
      This patch moves clk_get_rate() call from trigger() to hw_params()
      callback to avoid calling sleeping clk API from atomic context
      and prevent deadlock as indicated below.
      
      Before this change clk_get_rate() was being called with same
      spinlock held as the one passed to the clk API when registering
      clocks exposed by the I2S driver.
      
      [   82.109780] BUG: sleeping function called from invalid context at kernel/locking/mutex.c:908
      [   82.117009] in_atomic(): 1, irqs_disabled(): 128, pid: 1554, name: speaker-test
      [   82.124235] 3 locks held by speaker-test/1554:
      [   82.128653]  #0: cc8c5328 (snd_pcm_link_rwlock){...-}, at: snd_pcm_stream_lock_irq+0x20/0x38
      [   82.137058]  #1: ec9eda17 (&(&substream->self_group.lock)->rlock){..-.}, at: snd_pcm_ioctl+0x900/0x1268
      [   82.146417]  #2: 6ac279bf (&(&pri_dai->spinlock)->rlock){..-.}, at: i2s_trigger+0x64/0x6d4
      [   82.154650] irq event stamp: 8144
      [   82.157949] hardirqs last  enabled at (8143): [<c0a0f574>] _raw_read_unlock_irq+0x24/0x5c
      [   82.166089] hardirqs last disabled at (8144): [<c0a0f6a8>] _raw_read_lock_irq+0x18/0x58
      [   82.174063] softirqs last  enabled at (8004): [<c01024e4>] __do_softirq+0x3a4/0x66c
      [   82.181688] softirqs last disabled at (7997): [<c012d730>] irq_exit+0x140/0x168
      [   82.188964] Preemption disabled at:
      [   82.188967] [<00000000>]   (null)
      [   82.195728] CPU: 6 PID: 1554 Comm: speaker-test Not tainted 5.0.0-rc5-00192-ga6e6caca8f03 #191
      [   82.204302] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
      [   82.210376] [<c0111a54>] (unwind_backtrace) from [<c010d8f4>] (show_stack+0x10/0x14)
      [   82.218084] [<c010d8f4>] (show_stack) from [<c09ef004>] (dump_stack+0x90/0xc8)
      [   82.225278] [<c09ef004>] (dump_stack) from [<c0152980>] (___might_sleep+0x22c/0x2c8)
      [   82.232990] [<c0152980>] (___might_sleep) from [<c0a0a2e4>] (__mutex_lock+0x28/0xa3c)
      [   82.240788] [<c0a0a2e4>] (__mutex_lock) from [<c0a0ad80>] (mutex_lock_nested+0x1c/0x24)
      [   82.248763] [<c0a0ad80>] (mutex_lock_nested) from [<c04923dc>] (clk_prepare_lock+0x78/0xec)
      [   82.257079] [<c04923dc>] (clk_prepare_lock) from [<c049538c>] (clk_core_get_rate+0xc/0x5c)
      [   82.265309] [<c049538c>] (clk_core_get_rate) from [<c0766b18>] (i2s_trigger+0x490/0x6d4)
      [   82.273369] [<c0766b18>] (i2s_trigger) from [<c074fec4>] (soc_pcm_trigger+0x100/0x140)
      [   82.281254] [<c074fec4>] (soc_pcm_trigger) from [<c07378a0>] (snd_pcm_do_start+0x2c/0x30)
      [   82.289400] [<c07378a0>] (snd_pcm_do_start) from [<c07376cc>] (snd_pcm_action_single+0x38/0x78)
      [   82.298065] [<c07376cc>] (snd_pcm_action_single) from [<c073a450>] (snd_pcm_ioctl+0x910/0x1268)
      [   82.306734] [<c073a450>] (snd_pcm_ioctl) from [<c0292344>] (do_vfs_ioctl+0x90/0x9ec)
      [   82.314443] [<c0292344>] (do_vfs_ioctl) from [<c0292cd4>] (ksys_ioctl+0x34/0x60)
      [   82.321808] [<c0292cd4>] (ksys_ioctl) from [<c0101000>] (ret_fast_syscall+0x0/0x28)
      [   82.329431] Exception stack(0xeb875fa8 to 0xeb875ff0)
      [   82.334459] 5fa0:                   00033c18 b6e31000 00000004 00004142 00033d80 00033d80
      [   82.342605] 5fc0: 00033c18 b6e31000 00008000 00000036 00008000 00000000 beea38a8 00008000
      [   82.350748] 5fe0: b6e3142c beea384c b6da9a30 b6c9212c
      [   82.355789]
      [   82.357245] ======================================================
      [   82.363397] WARNING: possible circular locking dependency detected
      [   82.369551] 5.0.0-rc5-00192-ga6e6caca8f03 #191 Tainted: G        W
      [   82.376395] ------------------------------------------------------
      [   82.382548] speaker-test/1554 is trying to acquire lock:
      [   82.387834] 6d2007f4 (prepare_lock){+.+.}, at: clk_prepare_lock+0x78/0xec
      [   82.394593]
      [   82.394593] but task is already holding lock:
      [   82.400398] 6ac279bf (&(&pri_dai->spinlock)->rlock){..-.}, at: i2s_trigger+0x64/0x6d4
      [   82.408197]
      [   82.408197] which lock already depends on the new lock.
      [   82.416343]
      [   82.416343] the existing dependency chain (in reverse order) is:
      [   82.423795]
      [   82.423795] -> #1 (&(&pri_dai->spinlock)->rlock){..-.}:
      [   82.430472]        clk_mux_set_parent+0x34/0xb8
      [   82.434975]        clk_core_set_parent_nolock+0x1c4/0x52c
      [   82.440347]        clk_set_parent+0x38/0x6c
      [   82.444509]        of_clk_set_defaults+0xc8/0x308
      [   82.449186]        of_clk_add_provider+0x84/0xd0
      [   82.453779]        samsung_i2s_probe+0x408/0x5f8
      [   82.458376]        platform_drv_probe+0x48/0x98
      [   82.462879]        really_probe+0x224/0x3f4
      [   82.467037]        driver_probe_device+0x70/0x1c4
      [   82.471716]        bus_for_each_drv+0x44/0x8c
      [   82.476049]        __device_attach+0xa0/0x138
      [   82.480382]        bus_probe_device+0x88/0x90
      [   82.484715]        deferred_probe_work_func+0x6c/0xbc
      [   82.489741]        process_one_work+0x200/0x740
      [   82.494246]        worker_thread+0x2c/0x4c8
      [   82.498408]        kthread+0x128/0x164
      [   82.502131]        ret_from_fork+0x14/0x20
      [   82.506204]          (null)
      [   82.508976]
      [   82.508976] -> #0 (prepare_lock){+.+.}:
      [   82.514264]        __mutex_lock+0x60/0xa3c
      [   82.518336]        mutex_lock_nested+0x1c/0x24
      [   82.522756]        clk_prepare_lock+0x78/0xec
      [   82.527088]        clk_core_get_rate+0xc/0x5c
      [   82.531421]        i2s_trigger+0x490/0x6d4
      [   82.535494]        soc_pcm_trigger+0x100/0x140
      [   82.539913]        snd_pcm_do_start+0x2c/0x30
      [   82.544246]        snd_pcm_action_single+0x38/0x78
      [   82.549012]        snd_pcm_ioctl+0x910/0x1268
      [   82.553345]        do_vfs_ioctl+0x90/0x9ec
      [   82.557417]        ksys_ioctl+0x34/0x60
      [   82.561229]        ret_fast_syscall+0x0/0x28
      [   82.565477]        0xbeea384c
      [   82.568421]
      [   82.568421] other info that might help us debug this:
      [   82.568421]
      [   82.576394]  Possible unsafe locking scenario:
      [   82.576394]
      [   82.582285]        CPU0                    CPU1
      [   82.586792]        ----                    ----
      [   82.591297]   lock(&(&pri_dai->spinlock)->rlock);
      [   82.595977]                                lock(prepare_lock);
      [   82.601782]                                lock(&(&pri_dai->spinlock)->rlock);
      [   82.608975]   lock(prepare_lock);
      [   82.612268]
      [   82.612268]  *** DEADLOCK ***
      
      Fixes: 647d04f8 ("ASoC: samsung: i2s: Ensure the RCLK rate is properly determined")
      Reported-by: default avatarKrzysztof Kozłowski <krzk@kernel.org>
      Signed-off-by: default avatarSylwester Nawrocki <s.nawrocki@samsung.com>
      Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      860b454c
    • Jiada Wang's avatar
      ASoC: rsnd: ssiu: correct shift bit for ssiu9 · 76379dfb
      Jiada Wang authored
      Currently "0xf << 36" is used to
      clear SSIU-9 internal buffer state, which overflows 32-bit value
      according to user reference manual, it is always bit4 ~ bit7
      of SSI_SYS_STATUS[1,3,5,7] registers indicate
      SSIU-9's buffer state, so "0xf << 4" should be used.
      
      This patch fix incorrect shifting issue in SSIU-9 case
      
      Fixes: commit b7169dde ("ASoC: rsnd: remove RSND_REG_ from rsnd_reg")
      Signed-off-by: default avatarJiada Wang <jiada_wang@mentor.com>
      Acked-by: default avatarKuninori Morimoto <kuninori.morimoto.gx@renesas.com>
      Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      76379dfb
  3. 06 Feb, 2019 3 commits
  4. 05 Feb, 2019 2 commits
    • Charles Keepax's avatar
      ALSA: compress: Fix stop handling on compressed capture streams · 4f2ab5e1
      Charles Keepax authored
      It is normal user behaviour to start, stop, then start a stream
      again without closing it. Currently this works for compressed
      playback streams but not capture ones.
      
      The states on a compressed capture stream go directly from OPEN to
      PREPARED, unlike a playback stream which moves to SETUP and waits
      for a write of data before moving to PREPARED. Currently however,
      when a stop is sent the state is set to SETUP for both types of
      streams. This leaves a capture stream in the situation where a new
      start can't be sent as that requires the state to be PREPARED and
      a new set_params can't be sent as that requires the state to be
      OPEN. The only option being to close the stream, and then reopen.
      
      Correct this issues by allowing snd_compr_drain_notify to set the
      state depending on the stream direction, as we already do in
      set_params.
      
      Fixes: 49bb6402 ("ALSA: compress_core: Add support for capture streams")
      Signed-off-by: default avatarCharles Keepax <ckeepax@opensource.cirrus.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      4f2ab5e1
    • Udo Eberhardt's avatar
      ALSA: usb-audio: Add support for new T+A USB DAC · 3bff2407
      Udo Eberhardt authored
      This patch adds the T+A VID to the generic check in order to enable
      native DSD support for T+A devices. This works with the new T+A USB
      DAC model SD3100HV and will also work with future devices which
      support the XMOS/Thesycon style DSD format.
      Signed-off-by: default avatarUdo Eberhardt <udo.eberhardt@thesycon.de>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      3bff2407
  5. 02 Feb, 2019 2 commits
  6. 01 Feb, 2019 3 commits
    • Takashi Iwai's avatar
      ALSA: hda - Serialize codec registrations · 305a0ade
      Takashi Iwai authored
      In the current code, the codec registration may happen both at the
      codec bind time and the end of the controller probe time.  In a rare
      occasion, they race with each other, leading to Oops due to the still
      uninitialized card device.
      
      This patch introduces a simple flag to prevent the codec registration
      at the codec bind time as long as the controller probe is going on.
      The controller probe invokes snd_card_register() that does the whole
      registration task, and we don't need to register each piece
      beforehand.
      
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      305a0ade
    • Takashi Iwai's avatar
      ALSA: hda/realtek - Use a common helper for hp pin reference · 35a39f98
      Takashi Iwai authored
      Replace the open-codes in many places with a new common helper for
      performing the same thing: referring to the primary headphone pin.
      
      This eventually fixes the potentially missing headphone pin on some
      weird devices, too.
      
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      35a39f98
    • Kailang Yang's avatar
      ALSA: hda/realtek - Fix lose hp_pins for disable auto mute · d561aa0a
      Kailang Yang authored
      When auto_mute = no or spec->suppress_auto_mute = 1, cfg->hp_pins will
      lose value.
      
      Add this patch to find hp_pins value.
      I add fixed for ALC282 ALC225 ALC256 ALC294 and alc_default_init()
      alc_default_shutup().
      Signed-off-by: default avatarKailang Yang <kailang@realtek.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      d561aa0a
  7. 31 Jan, 2019 1 commit
  8. 29 Jan, 2019 1 commit
    • Kailang Yang's avatar
      ALSA: hda/realtek - Fixed hp_pin no value · 693abe11
      Kailang Yang authored
      Fix hp_pin always no value.
      
      [More notes on the changes:
      
       The hp_pin value that is referred in alc294_hp_init() is always zero
       at the moment the function gets called, hence this is actually
       useless as in the current code.
      
       And, this kind of init sequence should be called from the codec init
       callback, instead of the parser function.  So, the first fix in this
       patch to move the call call into its own init_hook.
      
       OTOH, this function is needed to be called only once after the boot,
       and it'd take too long for invoking at each resume (where the init
       callback gets called).  So we add a new flag and invoke this only
       once as an additional fix.
      
       The one case is still not covered, though: S4 resume.  But this
       change itself won't lead to any regression in that regard, so we
       leave S4 issue as is for now and fix it later.  -- tiwai ]
      
      Fixes: bde1a745 ("ALSA: hda/realtek - Fixed headphone issue for ALC700")
      Signed-off-by: default avatarKailang Yang <kailang@realtek.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      693abe11
  9. 25 Jan, 2019 3 commits
    • Takashi Iwai's avatar
      ALSA: pcm: Fix tight loop of OSS capture stream · e190161f
      Takashi Iwai authored
      When the trigger=off is passed for a PCM OSS stream, it sets the
      start_threshold of the given substream to the boundary size, so that
      it won't be automatically started.  This can be problematic for a
      capture stream, unfortunately, as detected by syzkaller.  The scenario
      is like the following:
      
      - In __snd_pcm_lib_xfer() that is invoked from snd_pcm_oss_read()
        loop, we have a check whether the stream was already started or the
        stream can be auto-started.
      - The function at this check returns 0 with trigger=off since we
        explicitly disable the auto-start.
      - The loop continues and repeats calling __snd_pcm_lib_xfer() tightly,
        which may lead to an RCU stall.
      
      This patch fixes the bug by simply allowing the wait for non-started
      stream in the case of OSS capture.  For native usages, it's supposed
      to be done by the caller side (which is user-space), hence it returns
      zero like before.
      
      (In theory, __snd_pcm_lib_xfer() could wait even for the native API
       usage cases, too; but I'd like to stay in a safer side for not
       breaking the existing stuff for now.)
      
      Reported-by: syzbot+fbe0496f92a0ce7b786c@syzkaller.appspotmail.com
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      e190161f
    • Olek Poplavsky's avatar
      ALSA: usb-audio: Add Opus #3 to quirks for native DSD support · 9e696664
      Olek Poplavsky authored
      This patch adds quirk VID/PID IDs for the Opus #3 DAP (made by 'The Bit')
      in order to enable Native DSD support.
      
      [ NOTE: this could be handled in the generic way with fp->dvd_raw if
        we add 0x10cb to the vendor whitelist, but since 0x10cb shows a
        different vendor name (Erantech), put to the individual entry at
        this time -- tiwai ]
      Signed-off-by: default avatarOlek Poplavsky <woodenbits@gmail.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      9e696664
    • Charles Keepax's avatar
      ASoC: core: Allow soc_find_component lookups to match parent of_node · d0b95e6c
      Charles Keepax authored
      For devices implemented as a MFD it is common to only have a single node
      in devicetree representing the whole device. As such when looking up
      components in soc_find_components we should match against both the devices
      of_node and the devices parent's of_node, as is already done in the rest
      of the ASoC core.
      
      This causes regressions for some DAI links at the moment as
      soc_find_component was recently added as a check in soc_init_dai_link.
      
      Fixes: 8780cf11 ("ASoC: soc-core: defer card probe until all component is added to list")
      Signed-off-by: default avatarCharles Keepax <ckeepax@opensource.cirrus.com>
      Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      d0b95e6c
  10. 22 Jan, 2019 1 commit
  11. 21 Jan, 2019 2 commits
  12. 18 Jan, 2019 2 commits
    • Russell King's avatar
      ASoC: hdmi-codec: fix oops on re-probe · 0ce23d6d
      Russell King authored
      hdmi-codec oopses the kernel when it is unbound from a successfully
      bound audio subsystem, and is then rebound:
      
      Unable to handle kernel NULL pointer dereference at virtual address 0000001c
      pgd = ee3f0000
      [0000001c] *pgd=3cc59831
      Internal error: Oops: 817 [#1] PREEMPT ARM
      Modules linked in: ext2 snd_soc_spdif_tx vmeta dove_thermal snd_soc_kirkwood ofpart marvell_cesa m25p80 orion_wdt mtd spi_nor des_generic gpio_ir_recv snd_soc_kirkwood_spdif bmm_dmabuf auth_rpcgss nfsd autofs4 etnaviv thermal_sys hwmon gpu_sched tda9950
      CPU: 0 PID: 1005 Comm: bash Not tainted 4.20.0+ #1762
      Hardware name: Marvell Dove (Cubox)
      PC is at hdmi_dai_probe+0x68/0x80
      LR is at find_held_lock+0x20/0x94
      pc : [<c04c7de0>]    lr : [<c0063bf4>]    psr: 600f0013
      sp : ee15bd28  ip : eebd8b1c  fp : c093b488
      r10: ee048000  r9 : eebdab18  r8 : ee048600
      r7 : 00000001  r6 : 00000000  r5 : 00000000  r4 : ee82c100
      r3 : 00000006  r2 : 00000001  r1 : c067e38c  r0 : ee82c100
      Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment none[  297.318599] Control: 10c5387d  Table: 2e3f0019  DAC: 00000051
      Process bash (pid: 1005, stack limit = 0xee15a248)
      ...
      [<c04c7de0>] (hdmi_dai_probe) from [<c04b7060>] (soc_probe_dai.part.9+0x34/0x70)
      [<c04b7060>] (soc_probe_dai.part.9) from [<c04b81a8>] (snd_soc_instantiate_card+0x734/0xc9c)
      [<c04b81a8>] (snd_soc_instantiate_card) from [<c04b8b6c>] (snd_soc_add_component+0x29c/0x378)
      [<c04b8b6c>] (snd_soc_add_component) from [<c04b8c8c>] (snd_soc_register_component+0x44/0x54)
      [<c04b8c8c>] (snd_soc_register_component) from [<c04c64b4>] (devm_snd_soc_register_component+0x48/0x84)
      [<c04c64b4>] (devm_snd_soc_register_component) from [<c04c7be8>] (hdmi_codec_probe+0x150/0x260)
      [<c04c7be8>] (hdmi_codec_probe) from [<c0373124>] (platform_drv_probe+0x48/0x98)
      
      This happens because hdmi_dai_probe() attempts to access the HDMI
      codec private data, but this has not been assigned by hdmi_dai_probe()
      before it calls devm_snd_soc_register_component().  Move the call to
      dev_set_drvdata() before devm_snd_soc_register_component() to avoid
      this oops.
      Signed-off-by: default avatarRussell King <rmk+kernel@armlinux.org.uk>
      Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      Cc: stable@vger.kernel.org
      0ce23d6d
    • Takashi Iwai's avatar
      Merge tag 'asoc-fix-v5.0-rc2' of... · b3c4014c
      Takashi Iwai authored
      Merge tag 'asoc-fix-v5.0-rc2' of https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus
      
      ASoC: Fixes for v5.0
      
      Quite a big batch of fixes here.  There's a couple of things going on,
      the main one is that we found some issues with not deferring probe when
      we should, causing us to skip some driver initialization.  The fixes for
      this then in turn exposed some issues with how we were searching for
      components which had previously gone unnoticed due to the original
      issue.
      
      There's also been the normal driver specific stuff and there's been what
      looks like several batches of automated scanning for issues which have
      generated quite a large set of smaller fixes for potential crashes and
      missed error handling.
      b3c4014c
  13. 15 Jan, 2019 7 commits
    • Gustavo A. R. Silva's avatar
      ASoC: amd: Fix potential NULL pointer dereference · 4cb79ef9
      Gustavo A. R. Silva authored
      Check return value from call to devm_kzalloc() in order to prevent a
      potential NULL pointer dereference.
      
      Also, notice that it makes no sense to allocate any resources if
      res = platform_get_resource(pdev, IORESOURCE_MEM, 0); fails,
      so move the call to devm_kzalloc() below the mentioned code.
      
      Lastly, improve the use of sizeof in the call to devm_kzalloc() by
      changing it from sizeof(struct i2s_dev_data) to sizeof(*adata)
      
      This issue was detected with the help of Coccinelle.
      
      Fixes: ac289c7e ("ASoC: amd: add ACP3x PCM platform driver")
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarGustavo A. R. Silva <gustavo@embeddedor.com>
      Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      4cb79ef9
    • Silvio Cesare's avatar
      ASoC: imx-audmux: change snprintf to scnprintf for possible overflow · c407cd00
      Silvio Cesare authored
      Change snprintf to scnprintf. There are generally two cases where using
      snprintf causes problems.
      
      1) Uses of size += snprintf(buf, SIZE - size, fmt, ...)
      In this case, if snprintf would have written more characters than what the
      buffer size (SIZE) is, then size will end up larger than SIZE. In later
      uses of snprintf, SIZE - size will result in a negative number, leading
      to problems. Note that size might already be too large by using
      size = snprintf before the code reaches a case of size += snprintf.
      
      2) If size is ultimately used as a length parameter for a copy back to user
      space, then it will potentially allow for a buffer overflow and information
      disclosure when size is greater than SIZE. When the size is used to index
      the buffer directly, we can have memory corruption. This also means when
      size = snprintf... is used, it may also cause problems since size may become
      large.  Copying to userspace is mitigated by the HARDENED_USERCOPY kernel
      configuration.
      
      The solution to these issues is to use scnprintf which returns the number of
      characters actually written to the buffer, so the size variable will never
      exceed SIZE.
      Signed-off-by: default avatarSilvio Cesare <silvio.cesare@gmail.com>
      Cc: Timur Tabi <timur@kernel.org>
      Cc: Nicolin Chen <nicoleotsuka@gmail.com>
      Cc: Mark Brown <broonie@kernel.org>
      Cc: Xiubo Li <Xiubo.Lee@gmail.com>
      Cc: Fabio Estevam <fabio.estevam@nxp.com>
      Cc: Dan Carpenter <dan.carpenter@oracle.com>
      Cc: Kees Cook <keescook@chromium.org>
      Cc: Will Deacon <will.deacon@arm.com>
      Cc: Greg KH <greg@kroah.com>
      Signed-off-by: default avatarWilly Tarreau <w@1wt.eu>
      Acked-by: default avatarNicolin Chen <nicoleotsuka@gmail.com>
      Reviewed-by: default avatarKees Cook <keescook@chromium.org>
      Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      c407cd00
    • Gustavo A. R. Silva's avatar
      ASoC: rt5514-spi: Fix potential NULL pointer dereference · 060d0bf4
      Gustavo A. R. Silva authored
      There is a potential NULL pointer dereference in case devm_kzalloc()
      fails and returns NULL.
      
      Fix this by adding a NULL check on rt5514_dsp.
      
      This issue was detected with the help of Coccinelle.
      
      Fixes: 6eebf35b ("ASoC: rt5514: add rt5514 SPI driver")
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarGustavo A. R. Silva <gustavo@embeddedor.com>
      Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      060d0bf4
    • Silvio Cesare's avatar
      ASoC: dapm: change snprintf to scnprintf for possible overflow · e581e151
      Silvio Cesare authored
      Change snprintf to scnprintf. There are generally two cases where using
      snprintf causes problems.
      
      1) Uses of size += snprintf(buf, SIZE - size, fmt, ...)
      In this case, if snprintf would have written more characters than what the
      buffer size (SIZE) is, then size will end up larger than SIZE. In later
      uses of snprintf, SIZE - size will result in a negative number, leading
      to problems. Note that size might already be too large by using
      size = snprintf before the code reaches a case of size += snprintf.
      
      2) If size is ultimately used as a length parameter for a copy back to user
      space, then it will potentially allow for a buffer overflow and information
      disclosure when size is greater than SIZE. When the size is used to index
      the buffer directly, we can have memory corruption. This also means when
      size = snprintf... is used, it may also cause problems since size may become
      large.  Copying to userspace is mitigated by the HARDENED_USERCOPY kernel
      configuration.
      
      The solution to these issues is to use scnprintf which returns the number of
      characters actually written to the buffer, so the size variable will never
      exceed SIZE.
      Signed-off-by: default avatarSilvio Cesare <silvio.cesare@gmail.com>
      Cc: Liam Girdwood <lgirdwood@gmail.com>
      Cc: Mark Brown <broonie@kernel.org>
      Cc: Dan Carpenter <dan.carpenter@oracle.com>
      Cc: Kees Cook <keescook@chromium.org>
      Cc: Will Deacon <will.deacon@arm.com>
      Cc: Greg KH <greg@kroah.com>
      Signed-off-by: default avatarWilly Tarreau <w@1wt.eu>
      Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      e581e151
    • Shuming Fan's avatar
      ASoC: rt5682: Fix PLL source register definitions · ee7ea2a9
      Shuming Fan authored
      Fix typo which causes headphone no sound while using BCLK
      as PLL source.
      Signed-off-by: default avatarShuming Fan <shumingf@realtek.com>
      Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      ee7ea2a9
    • Matthias Reichl's avatar
      ASoC: core: Don't defer probe on optional, NULL components · 2833548e
      Matthias Reichl authored
      cpu and platform are optional components in DAI links. For example
      codec-codec links usually have no platform set.
      
      Call snd_soc_find_component only if the name or of_node of
      a cpu or platform is set. Otherwise it will return NULL and
      soc_init_dai_link bails out immediately with -EPROBE_DEFER,
      meaning registering a card with NULL cpu or platform in DAI links
      can never succeed.
      
      Fixes: 8780cf11 ("ASoC: soc-core: defer card probe until all component is added to list")
      Signed-off-by: default avatarMatthias Reichl <hias@horus.com>
      Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      2833548e
    • Mark Brown's avatar
      ASoC: core: Make snd_soc_find_component() more robust · 5a7b2aab
      Mark Brown authored
      There are some use cases where you're checking for a lot of things on a
      card and it makes sense that you might end up trying to call
      snd_soc_find_component() without either a name or an of_node.  Currently
      in that case we try to dereference the name and crash but it's more
      useful to allow the caller to just treat that as a case where we don't
      find anything, that error handling will already exist.
      
      Inspired by a patch from Ajit Pandey fixing some callers.
      
      Fixes: 8780cf11 ("ASoC: soc-core: defer card probe until all component is added to list")
      Reported-by: default avatarPierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
      Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      5a7b2aab
  14. 14 Jan, 2019 3 commits
    • Curtis Malainey's avatar
      ASoC: soc-core: fix init platform memory handling · 09ac6a81
      Curtis Malainey authored
      snd_soc_init_platform initializes pointers to snd_soc_dai_link which is
      statically allocated and it does this by devm_kzalloc. In the event of
      an EPROBE_DEFER the memory will be freed and the pointers are left
      dangling. snd_soc_init_platform sees the dangling pointers and assumes
      they are pointing to initialized memory and does not reallocate them on
      the second probe attempt which results in a use after free bug since
      devm has freed the memory from the first probe attempt.
      
      Since the intention for snd_soc_dai_link->platform is that it can be set
      statically by the machine driver we need to respect the pointer in the
      event we did not set it but still catch dangling pointers. The solution
      is to add a flag to track whether the pointer was dynamically allocated
      or not.
      Signed-off-by: default avatarCurtis Malainey <cujomalainey@chromium.org>
      Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      09ac6a81
    • Takashi Iwai's avatar
      ASoC: intel: skl: Fix display power regression · 687ae9e2
      Takashi Iwai authored
      Since the refactoring of HD-audio display power management, the
      display power status is managed per domain.  Meanwhile the ASoC
      hdac_hdmi driver still keeps and relies (incorrectly) on the
      refcounting together with ASoC skl driver, and this leads to the
      display state always on.
      
      This patch is an attempt to address the regression by simplifying the
      PM code of ASoC skl and hdac_hdmi drivers.  Basically, since the
      refactoring, we don't have to manage the display power at HD-audio
      controller suspend / resume but only at HD-audio HDMI codec suspend /
      resume.  So the patch drops the superfluous snd_hdac_display_power()
      calls in skl driver.
      
      Meanwhile, in hdac_hdmi side, we rewrite the PM call just to re-use
      the runtime PM callbacks like other drivers do.  Now the logic is
      simple: turn off at suspend and turn on at resume.
      
      The patch also fixes the possibly missing display-power off at skl
      driver removal as well as some error paths at probe.
      
      Fixes: 029d92c2 ("ALSA: hda: Refactor display power management")
      Reported-by: default avatarLibin Yang <libin.yang@intel.com>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      687ae9e2
    • Kailang Yang's avatar
      ALSA: hda/realtek - Fix typo for ALC225 model · 82aa0d7e
      Kailang Yang authored
      Fix typo for model alc255-dell1 to alc225-dell1.
      
      Enable headset mode support for new WYSE NB platform.
      
      Fixes: a26d96c7 ("ALSA: hda/realtek - Comprehensive model list for ALC259 & co")
      Signed-off-by: default avatarKailang Yang <kailang@realtek.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      82aa0d7e
  15. 10 Jan, 2019 1 commit
  16. 09 Jan, 2019 3 commits