16 May, 2016

1 commit


13 May, 2016

2 commits


10 May, 2016

1 commit

  • When snd_pcm_add_chmap_ctls() is called to the PCM stream to which a
    chmap has been already assigned, it returns as an error due to the
    conflicting snd_ctl_add() result. However, this also clears the
    already assigned chmap_kctl field via pcm_chmap_ctl_private_free(),
    and becomes inconsistent in the later operation.

    This patch adds the check of the conflicting chmap kctl before
    actually trying to allocate / assign. The check failure is treated as
    a kernel warning, as the double call of snd_pcm_add_chmap_ctls() is
    basically a driver bug and having the stack trace would help
    developers to figure out the bad code path.

    Signed-off-by: Takashi Iwai

    Takashi Iwai
     

09 May, 2016

5 commits


08 May, 2016

3 commits


28 Apr, 2016

1 commit

  • dmaengine_pcm currently only supports setups where FIFO reads/writes
    correspond to exactly one sample, eg 16-bit sample data is transferred
    via 16-bit FIFO accesses, 32-bit data via 32-bit accesses.

    This patch adds support for setups with fixed width FIFOs where
    multiple samples are packed into a larger word.

    For example setups with a 32-bit wide FIFO register that expect
    16-bit sample transfers to be done with the left+right sample data
    packed into a 32-bit word.

    Support for packed transfers is controlled via the
    SND_DMAENGINE_PCM_DAI_FLAG_PACK flag in snd_dmaengine_dai_dma_data.flags

    If this flag is set dmaengine_pcm doesn't put any restriction on the
    supported formats and sets the DMA transfer width to undefined.

    This means control over the constraints is now transferred to the DAI
    driver and it's responsible to provide proper configuration and
    check for possible corner cases that aren't handled by the ALSA core.

    Signed-off-by: Matthias Reichl
    Acked-by: Lars-Peter Clausen
    Tested-by: Martin Sperl
    Signed-off-by: Mark Brown

    Matthias Reichl
     

26 Apr, 2016

1 commit

  • This patch tries to address the still remaining issues in ALSA hrtimer
    driver:
    - Spurious use-after-free was detected in hrtimer callback
    - Incorrect rescheduling due to delayed start
    - WARN_ON() is triggered in hrtimer_forward() invoked in hrtimer
    callback

    The first issue happens only when the new timer is scheduled even
    while hrtimer is being closed. It's related with the second and third
    items; since ALSA timer core invokes hw.start callback during hrtimer
    interrupt, this may result in the explicit call of hrtimer_start().

    Also, the similar problem is seen for the stop; ALSA timer core
    invokes hw.stop callback even in the hrtimer handler, too. Since we
    must not call the synced hrtimer_cancel() in such a context, it's just
    a hrtimer_try_to_cancel() call that doesn't properly work.

    Another culprit of the second and third items is the call of
    hrtimer_forward_now() before snd_timer_interrupt(). The timer->stick
    value may change during snd_timer_interrupt() call, but this
    possibility is ignored completely.

    For covering these subtle and messy issues, the following changes have
    been done in this patch:
    - A new flag, in_callback, is introduced in the private data to
    indicate that the hrtimer handler is being processed.
    - Both start and stop callbacks skip when called from (during)
    in_callback flag.
    - The hrtimer handler returns properly HRTIMER_RESTART and NORESTART
    depending on the running state now.
    - The hrtimer handler reprograms the expiry properly after
    snd_timer_interrupt() call, instead of before.
    - The close callback clears running flag and sets in_callback flag
    to block any further start/stop calls.

    Signed-off-by: Takashi Iwai

    Takashi Iwai
     

25 Apr, 2016

1 commit


15 Apr, 2016

1 commit

  • Currently kill_fasync() is called outside the stream lock in
    snd_pcm_period_elapsed(). This is potentially racy, since the stream
    may get released even during the irq handler is running. Although
    snd_pcm_release_substream() calls snd_pcm_drop(), this doesn't
    guarantee that the irq handler finishes, thus the kill_fasync() call
    outside the stream spin lock may be invoked after the substream is
    detached, as recently reported by KASAN.

    As a quick workaround, move kill_fasync() call inside the stream
    lock. The fasync is rarely used interface, so this shouldn't have a
    big impact from the performance POV.

    Ideally, we should implement some sync mechanism for the proper finish
    of stream and irq handler. But this oneliner should suffice for most
    cases, so far.

    Reported-by: Baozeng Ding
    Signed-off-by: Takashi Iwai

    Takashi Iwai
     

07 Apr, 2016

2 commits


01 Apr, 2016

1 commit

  • ALSA system timer backend stops the timer via del_timer() without sync
    and leaves del_timer_sync() at the close instead. This is because of
    the restriction by the design of ALSA timer: namely, the stop callback
    may be called from the timer handler, and calling the sync shall lead
    to a hangup. However, this also triggers a kernel BUG() when the
    timer is rearmed immediately after stopping without sync:
    kernel BUG at kernel/time/timer.c:966!
    Call Trace:

    [] snd_timer_s_start+0x13e/0x1a0
    [] snd_timer_interrupt+0x504/0xec0
    [] ? debug_check_no_locks_freed+0x290/0x290
    [] snd_timer_s_function+0xb4/0x120
    [] call_timer_fn+0x162/0x520
    [] ? call_timer_fn+0xcd/0x520
    [] ? snd_timer_interrupt+0xec0/0xec0
    ....

    It's the place where add_timer() checks the pending timer. It's clear
    that this may happen after the immediate restart without sync in our
    cases.

    So, the workaround here is just to use mod_timer() instead of
    add_timer(). This looks like a band-aid fix, but it's a right move,
    as snd_timer_interrupt() takes care of the continuous rearm of timer.

    Reported-by: Jiri Slaby
    Cc:
    Signed-off-by: Takashi Iwai

    Takashi Iwai
     

23 Mar, 2016

1 commit

  • 'struct snd_timer_gparams' includes some members with 'unsigned long',
    therefore its size differs depending on data models of architecture. As
    a result, x86/x32 applications fail to execute ioctl(2) with
    SNDRV_TIMER_GPARAMS command on x86_64 machine.

    This commit fixes this bug by adding a pair of structure and ioctl
    command for the compatibility.

    Signed-off-by: Takashi Sakamoto
    Signed-off-by: Takashi Iwai

    Takashi Sakamoto
     

17 Mar, 2016

1 commit

  • …e in core implementation

    In control compatibility layer, when no elements are found by
    ELEM_READ/ELEM_WRITE ioctl commands, ENXIO is returned. On the other hand,
    in core implementation, ENOENT is returned. This is not good for
    ALSA ctl applications.

    This commit changes the return value from the compatibility layer so
    that the same value is returned.

    Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>

    Takashi Sakamoto
     

14 Mar, 2016

1 commit

  • ASoC: Updates for v4.6

    The main thing in terms of the core this time around has been some
    additional framework work for dynamic topologies (though we *still*
    don't appear to have a stable ABI for the topology code, it's probably
    worth considering if this will ever happen...). Otherwise the work has
    almost all been in the drivers:

    - HDMI support for Sky Lake, along with other fixes and enhancements
    for the Intel drivers.
    - Lots of improvements to the Renesas drivers.
    - Capture support for Qualcomm drivers.
    - Support for TI DaVinci DRA7xxx devices.
    - New machine drivers for Freescale systems with Cirrus CODECs,
    Mediatek systems with RT5650 CODECs.
    - New CPU drivers for Allwinner S/PDIF controllers
    - New CODEC drivers for Maxim MAX9867 and MAX98926 and Realtek RT5514.

    Takashi Iwai
     

13 Mar, 2016

1 commit


11 Mar, 2016

1 commit

  • The commit [d507941beb1e: ALSA: pcm: Correct PCM BUG error message]
    made the warning prefix back to "BUG:" due to its previous wrong
    prefix. But a kernel message containing "BUG:" seems taken as an Oops
    message wrongly by some brain-dead daemons, and it annoys users in the
    end. Instead of teaching daemons, change the string again to a more
    reasonable one.

    Fixes: 507941beb1e ('ALSA: pcm: Correct PCM BUG error message')
    Cc: # v3.19+
    Signed-off-by: Takashi Iwai

    Takashi Iwai
     

08 Mar, 2016

1 commit

  • rawmidi devices expose the card number via IOCTLs, which allows to
    find the corresponding device in sysfs.

    The sequencer provides no identifing data. Chromium works around this
    issue by scanning rawmidi as well as sequencer devices and matching
    them by using assumtions, how the kernel register sequencer devices.

    This changes adds support for exposing the card number for kernel clients
    as well as the PID for user client.

    The minor of the API version is changed to distinguish between the zero
    initialised reserved field and card number 0.

    [minor coding style fixes by tiwai]

    Signed-off-by: Martin Koegler
    Acked-by: Clemens Ladisch
    Signed-off-by: Takashi Iwai

    Martin Koegler
     

05 Mar, 2016

3 commits


04 Mar, 2016

2 commits


02 Mar, 2016

1 commit

  • The OSS sequencer client tries to drain the pending events at
    releasing. Unfortunately, as spotted by syzkaller fuzzer, this may
    lead to an unkillable process state when the event has been queued at
    the far future. Since the process being released can't be signaled
    any longer, it remains and waits for the echo-back event in that far
    future.

    Back to history, the draining feature was implemented at the time we
    misinterpreted POSIX definition for blocking file operation.
    Actually, such a behavior is superfluous at release, and we should
    just release the device as is instead of keeping it up forever.

    This patch just removes the draining call that may block the release
    for too long time unexpectedly.

    BugLink: http://lkml.kernel.org/r/CACT4Y+Y4kD-aBGj37rf-xBw9bH3GMU6P+MYg4W1e-s-paVD2pg@mail.gmail.com
    Reported-by: Dmitry Vyukov
    Cc:
    Signed-off-by: Takashi Iwai

    Takashi Iwai
     

01 Mar, 2016

1 commit


29 Feb, 2016

6 commits

  • X32 ABI takes the 64bit timespec, thus the timer user status ioctl becomes
    incompatible with IA32. This results in NOTTY error when the ioctl is
    issued.

    Meanwhile, this struct in X32 is essentially identical with the one in
    X86-64, so we can just bypassing to the existing code for this
    specific compat ioctl.

    Cc: # v3.4+
    Signed-off-by: Takashi Iwai

    Takashi Iwai
     
  • The timer user status compat ioctl returned the bogus struct used for
    64bit architectures instead of the 32bit one. This patch addresses
    it to return the proper struct.

    Cc:
    Signed-off-by: Takashi Iwai

    Takashi Iwai
     
  • Like the previous fixes for ctl and PCM, we need a fix for
    incompatible X32 ABI regarding the rawmidi: namely, struct
    snd_rawmidi_status has the timespec, and the size and the alignment on
    X32 differ from IA32.

    This patch fixes the incompatible ioctl for X32.

    Cc: # v3.4+
    Signed-off-by: Takashi Iwai

    Takashi Iwai
     
  • Instead of open-coding, use the existing helper to copy a 32bit
    timespec from/to 64bit.

    Signed-off-by: Takashi Iwai

    Takashi Iwai
     
  • X32 ABI uses the 64bit timespec in addition to 64bit alignment of
    64bit values. This leads to incompatibilities in some PCM ioctls
    involved with snd_pcm_channel_info, snd_pcm_status and
    snd_pcm_sync_ptr structs. Fix the PCM compat ABI for these ioctls
    like the previous commit for ctl API.

    Reported-by: Steven Newbury
    Cc: # v3.4+
    Signed-off-by: Takashi Iwai

    Takashi Iwai
     
  • The X32 ABI takes the same alignment like x86-64, and this may result
    in the incompatible struct size from ia32. Unfortunately, we hit this
    in some control ABI: struct snd_ctl_elem_value differs between them
    due to the position of 64bit variable array. This ends up with the
    unknown ioctl (ENOTTY) error.

    The fix is to add the compat entries for the new aligned struct.

    Reported-and-tested-by: Steven Newbury
    Cc: # v3.4+
    Signed-off-by: Takashi Iwai

    Takashi Iwai
     

27 Feb, 2016

1 commit


23 Feb, 2016

1 commit

  • Since the recent integration of kctl jack and input jack layers, we
    can basically build the jack layer even without input devices. That
    is, the jack layer itself can be built with conditional to enable the
    input device support or not, while the users may enable always
    CONFIG_SND_JACK unconditionally.

    For achieving it, this patch changes the following:
    - A new Kconfig, CONFIG_SND_JACK_INPUT_DEV, was introduced to indicate
    whether the jack layer supports the input device,
    - A few items in snd_jack struct and relevant codes are conditionally
    built upon CONFIG_SND_JACK_INPUT_DEV,
    - The users of CONFIG_SND_JACK drop the messy dependency on
    CONFIG_INPUT.

    This change also automagically fixes a potential bug in HD-audio
    driver Arnd reported, where the NULL or uninitialized jack instance is
    dereferenced.

    Reported-by: Arnd Bergmann
    Acked-by: Arnd Bergmann
    Signed-off-by: Takashi Iwai

    Takashi Iwai