Skip to content

L
linux
Switch branch/tag
  1. 09 Jul, 2020 2 commits
    • Mark Hills's avatar
      ALSA: echoaudio: Race conditions around "opencount" · 027c7002
      Mark Hills authored 
      Use of atomics does not make these statements robust:

       atomic_inc(&chip->opencount);
       if (atomic_read(&chip->opencount) > 1 && chip->rate_set)
               chip->can_set_rate=0;

and

       if (atomic_read(&chip->opencount)) {
               if (chip->opencount) {
                       changed = -EAGAIN;
               } else {
                       changed = set_digital_mode(chip, dmode);

It would be necessary to atomically increment or decrement the value
and use the returned result. And yet we still need to prevent other
threads making use of "can_set_rate" while we set it.

However in all but one case the atomic is misleading as they are already
running with "mode_mutex" held.

Decisions are made on mode setting are often intrinsically connected
to "opencount" because some operations are not permitted unless
there is sole ownership.

So instead simplify this, and use "mode_mutex" as a lock for all reference
counting and mode setting.
Signed-off-by: default avatarMark Hills <mark@xwax.org>
Link: https://lore.kernel.org/r/20200708101848.3457-2-mark@xwax.orgSigned-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      027c7002
    • Mark Hills's avatar
      ALSA: echoaudio: Remove redundant check · db091b0e
      Mark Hills authored 
      This check is always false, as it's not the responsibilty of the
device-specific code to make this check. It is already checked
in snd_echo_digital_mode_put.

I do not have a Mona interface to test this change.

This patch is in preparation for follow-up patch to modify the
behavior of "opencount".
Signed-off-by: default avatarMark Hills <mark@xwax.org>
Link: https://lore.kernel.org/r/20200708101848.3457-1-mark@xwax.orgSigned-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      db091b0e
  3. 08 Jul, 2020 1 commit
  5. 07 Jul, 2020 28 commits
  7. 30 Jun, 2020 1 commit
  9. 25 Jun, 2020 1 commit
  11. 19 Jun, 2020 2 commits
    • Takashi Iwai's avatar
      Merge branch 'topic/hda-micmute-led' into for-next · c7440acc
      Takashi Iwai authored 
      This is a patch set inspired by the recent patch Kai-Heng posted about
the HD-audio mic-mute LED control.  Currently HD-audio driver deals
with the mute and mic-mute LED in several different ways: primarily
with the direct callback of vmaster hook and capture sync hook, while
another with the LED class device binding.  The latter has been used
for binding with the platform device LEDs like Thinkpad, Dell,
Huawei.  And, yet, recently we added our own LED classdev for the
mic-mute LED on some HP systems although they are controlled directly
with the callback; it's exposed, however, for the DMIC that is
governed by a different ASoC driver.

This patch set is an attempt to sort out and make them consistent:
namely,
* All LEDs are now controlled via LED class device
* The generic driver provides helper functions to easily build up the
  LED class dev and the relevant mixer controls
* Conversion of the existing framework and clean ups

The patches are lightly tested in my side with a couple of machines
and also through hda-emu tests.  Some devices receive new kcontrols
for the mute LED behavior (that have been missing so far), but
anything else look good though my tests.

Link: https://lore.kernel.org/r/20200618110842.27238-1-tiwai@suse.deSigned-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      c7440acc
    • Takashi Iwai's avatar
      ALSA: hda: Enable sync-write operation as default for all controllers · f34a4c9d
      Takashi Iwai authored 
      In the end we already enabled the sync-write mode for most of HD-audio
controllers including Intel, and it's no big merit to keep the async
write mode for the rest.  Let's make it as default and drop the
superfluous AZX_DCAPS_SYNC_WRITE bit flag.

Also, avoid to set the allow_bus_reset flag, which is a quite unstable
and hackish behavior that was needed only for some early platforms
(decades ago).  The straight fallback to the single cmd mode is more
robust.

Link: https://lore.kernel.org/r/20200618144051.7415-1-tiwai@suse.deSigned-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      f34a4c9d
  13. 18 Jun, 2020 5 commits
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7