1. 26 Dec, 2019 1 commit
  2. 24 Dec, 2019 1 commit
    • Takashi Sakamoto's avatar
      ALSA: ctl: allow TLV read operation for callback type of element in locked case · d61fe22c
      Takashi Sakamoto authored
      A design of ALSA control core allows applications to execute three
      operations for TLV feature; read, write and command. Furthermore, it
      allows driver developers to process the operations by two ways; allocated
      array or callback function. In the former, read operation is just allowed,
      thus developers uses the latter when device driver supports variety of
      models or the target model is expected to dynamically change information
      stored in TLV container.
      
      The core also allows applications to lock any element so that the other
      applications can't perform write operation to the element for element
      value and TLV information. When the element is locked, write and command
      operation for TLV information are prohibited as well as element value.
      Any read operation should be allowed in the case.
      
      At present, when an element has callback function for TLV information,
      TLV read operation returns EPERM if the element is locked. On the
      other hand, the read operation is success when an element has allocated
      array for TLV information. In both cases, read operation is success for
      element value expectedly.
      
      This commit fixes the bug. This change can be backported to v4.14
      kernel or later.
      Signed-off-by: default avatarTakashi Sakamoto <o-takashi@sakamocchi.jp>
      Reviewed-by: default avatarJaroslav Kysela <perex@perex.cz>
      Link: https://lore.kernel.org/r/20191223093347.15279-1-o-takashi@sakamocchi.jpSigned-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      d61fe22c
  3. 23 Dec, 2019 4 commits
  4. 20 Dec, 2019 6 commits
  5. 18 Dec, 2019 3 commits
  6. 17 Dec, 2019 3 commits
    • Takashi Iwai's avatar
      Merge tag 'y2038-alsa-v8-signed' of... · df1d6ea0
      Takashi Iwai authored
      Merge tag 'y2038-alsa-v8-signed' of git://git.kernel.org:/pub/scm/linux/kernel/git/arnd/playground into for-next
      
      ALSA: Fix year 2038 issue for sound subsystem
      
      This is a series I worked on with Baolin in 2017 and 2018, but we
      never quite managed to finish up the last pieces. During the
      ALSA developer meetup at ELC-E 2018 in Edinburgh, a decision was
      made to go with this approach for keeping best compatibility
      with existing source code, and then I failed to follow up by
      resending the patches.
      
      Now I have patches for all remaining time_t uses in the kernel,
      so it's absolutely time to revisit them. I have done more
      review of the patches myself and found a couple of minor issues
      that I have fixed up, otherwise the series is still the same as
      before.
      
      Conceptually, the idea of these patches is:
      
      - 64-bit applications should see no changes at all, neither
        compile-time nor run-time.
      
      - 32-bit code compiled with a 64-bit time_t currently
        does not work with ALSA, and requires kernel changes and/or
        sound/asound.h changes
      
      - Most 32-bit code using these interfaces will work correctly
        on a modified kernel, with or without the uapi header changes.
      
      - 32-bit code using SNDRV_TIMER_IOCTL_TREAD requires the
        updated header file for 64-bit time_t support
      
      - 32-bit i386 user space with 64-bit time_t is broken for
        SNDRV_PCM_IOCTL_STATUS, SNDRV_RAWMIDI_IOCTL_STATUS and
        SNDRV_PCM_IOCTL_SYNC_PTR because of i386 alignment. This is also
        addressed by the updated uapi header.
      
      - PCM mmap is currently supported on native x86 kernels
        (both 32-bit and 64-bit) but not for compat mode. This series breaks
        the 32-bit native mmap support for 32-bit time_t, but instead allows
        it for 64-bit time_t on both native and compat kernels. This seems to
        be the best trade-off, as mmap support is optional already, and most
        32-bit code runs in compat mode anyway.
      
      - I've tried to avoid breaking compilation of 32-bit code
        as much as possible. Anything that does break however is likely code
        that is already broken on 64-bit time_t and needs source changes to
        fix them.
      
      [1] https://git.kernel.org/pub/scm/linux/kernel/git/arnd/playground.git y2038-alsa-v8
      [2] https://lore.kernel.org/lkml/CAK8P3a2Os66+iwQYf97qh05W2JP8rmWao8zmKoHiXqVHvyYAJA@mail.gmail.com/T/#m6519cb07cfda08adf1dedea6596bb98892b4d5dcSigned-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      
      Changes since v7: (Arnd):
       - Fix a typo found by Ben Hutchings
      
      Changes since v6: (Arnd):
       - Add a patch to update the API versions
       - Hide a timespec reference in #ifndef __KERNEL__ to remove the
         last reference to time_t
       - Use a more readable way to do padding and describe it in the
         changelog
       - Rebase to linux-5.5-rc1, changing include/sound/soc-component.h
         and sound/drivers/aloop.c as needed.
      
      Changes since v5 (Arnd):
       - Rebased to linux-5.4-rc4
       - Updated to completely remove timespec and time_t references from alsa
       - found and fixed a few bugs
      
      Changes since v4 (Baolin):
       - Add patch 5 to change trigger_tstamp member of struct snd_pcm_runtime.
       - Add patch 8 to change internal timespec.
       - Add more explanation in commit message.
       - Use ktime_get_real_ts64() in patch 6.
       - Split common code out into a separate function in patch 6.
       - Fix tu->tread bug in patch 6 and remove #if __BITS_PER_LONG == 64 macro.
      
      Changes since v3:
       - Move struct snd_pcm_status32 to pcm.h file.
       - Modify comments and commit message.
       - Add new patch2 ~ patch6.
      
      Changes since v2:
       - Renamed all structures to make clear.
       - Remove CONFIG_X86_X32 macro and introduced new compat_snd_pcm_status64_x86_32.
      
      Changes since v1:
       - Add one macro for struct snd_pcm_status_32 which only active in 32bits kernel.
       - Convert pcm_compat.c to use struct snd_pcm_status_64.
       - Convert pcm_native.c to use struct snd_pcm_status_64.
      df1d6ea0
    • Takashi Iwai's avatar
      Merge tag 'asoc-fix-v5.5-rc2' of... · 7c497d79
      Takashi Iwai authored
      Merge tag 'asoc-fix-v5.5-rc2' of https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus
      
      ASoC: Fixes for v5.5
      
      A collection of fixes since the merge window, mostly driver specific but
      there's a few in the core that clean up fallout from the refactorings
      done in the last cycle.
      7c497d79
    • Takashi Iwai's avatar
      ALSA: cmipci: Allow disabling MPU port via module option · d8cac620
      Takashi Iwai authored
      Patrick May reported that his sound card with CMI8378 chip causes a
      crash / reboot when accessing the MIDI port that isn't actually
      present on the board.  Moreover, despite of the documentation,
      passing mpu_port=0 doesn't disable the MIDI port on this board.
      
      It implies that the chip is a newer revision and the MPU401 port is
      integrated and mapped on the PCI register.  For this chip model, the
      driver enables the MPU port unconditionally, so far.
      
      Although fixing the unexpected reboot would be the best solution, it's
      not so trivial to identify the cause.  So, as a plan B, this patch
      extends the existing mpu_port option usage to allow disabling the port
      by specifying the value 0, just like we applied for fm_port option in
      commit 2f24d159 ("[ALSA] cmipci - Allow to disable integrated FM
      port").  As default, the MPU port is still enabled, but user can pass
      mpu_port=0 to disable it.
      Reported-and-tested-by: default avatarPatrick May <dusthillresident@gmail.com>
      Link: https://lore.kernel.org/r/20191217081448.1144-1-tiwai@suse.deSigned-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      d8cac620
  7. 16 Dec, 2019 2 commits
  8. 14 Dec, 2019 7 commits
  9. 13 Dec, 2019 6 commits
    • Takashi Iwai's avatar
      ALSA: hda: Unify get_response handling · 5f2cb361
      Takashi Iwai authored
      Now most of the get_response handling became quite similar between
      HDA-core and legacy drivers, and the only differences are:
      
      - the handling of extra-long polling delay for some codecs
      - the debug message for the stalled communication
      
      and both are worth to share in the common code.
      
      This patch unifies the code into snd_hdac_bus_get_response(), and use
      this from the legacy get_response callback.  It results in a good
      amount of code reduction in the end.
      Reviewed-by: default avatarKai Vehmanen <kai.vehmanen@linux.intel.com>
      Link: https://lore.kernel.org/r/20191212191101.19517-3-tiwai@suse.deSigned-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      5f2cb361
    • Takashi Iwai's avatar
      ALSA: hda: Use waitqueue for RIRB in HDA-core helper, too · 89698ed5
      Takashi Iwai authored
      This patch implements the same logic that was done for the legacy
      HD-audio controller driver by the commit 88452da9 ("ALSA: hda: Use
      standard waitqueue for RIRB wakeup") to the HDA-core helper code,
      too.  This makes snd_hdac_bus_get_response() waiting for the response
      with bus->rirb_wq instead of polling when bus->polling is false.
      It'll save both CPU time and response latency.
      Reviewed-by: default avatarKai Vehmanen <kai.vehmanen@linux.intel.com>
      Link: https://lore.kernel.org/r/20191212191101.19517-2-tiwai@suse.deSigned-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      89698ed5
    • Arnd Bergmann's avatar
      ALSA: bump uapi version numbers · 1cfaef96
      Arnd Bergmann authored
      Change SNDRV_PCM_VERSION, SNDRV_RAWMIDI_VERSION and SNDRV_TIMER_VERSION
      to indicate the addition of the time64 version of the mmap interface and
      these ioctl commands:
      
      SNDRV_PCM_IOCTL_SYNC
      SNDRV_RAWMIDI_IOCTL_STATUS
      SNDRV_PCM_IOCTL_STATUS
      SNDRV_PCM_IOCTL_STATUS_EXT
      SNDRV_TIMER_IOCTL_TREAD
      SNDRV_TIMER_IOCTL_STATUS
      
      32-bit applications built with 64-bit time_t require both the headers
      and the running kernel to support at least the new API version. When
      built with earlier kernel headers, some of these may not work
      correctly, so applications are encouraged to fail compilation like
      
       #if SNDRV_PCM_VERSION < SNDRV_PROTOCOL_VERSION(2, 0, 15)
       extern int __fail_build_for_time_64[sizeof(long) - sizeof(time_t)];
       #endif
      
      or provide their own updated copy of the header file.
      At runtime, the interface is unchanged for 32-bit time_t, but new
      kernels are required to work with user compiled with 64-bit time_t.
      
      A runtime check can be used to detect old kernel versions and
      warn about those.
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      1cfaef96
    • Arnd Bergmann's avatar
      ALSA: add new 32-bit layout for snd_pcm_mmap_status/control · 80fe7430
      Arnd Bergmann authored
      The snd_pcm_mmap_status and snd_pcm_mmap_control interfaces are one of the
      trickiest areas to get right when moving to 64-bit time_t in user space.
      
      The snd_pcm_mmap_status structure layout is incompatible with user space
      that uses a 64-bit time_t, so we need a new layout for it. Since the
      SNDRV_PCM_IOCTL_SYNC_PTR ioctl combines it with snd_pcm_mmap_control
      into snd_pcm_sync_ptr, we need to change those two as well.
      
      Both structures are also exported via an mmap() operation on certain
      architectures, and this suffers from incompatibility between 32-bit
      and 64-bit user space. As we have to change both structures anyway,
      this is a good opportunity to fix the mmap() problem as well, so let's
      standardize on the existing 64-bit layout of the structure where possible.
      
      The downside is that we lose mmap() support for existing 32-bit x86 and
      powerpc applications, adding that would introduce very noticeable runtime
      overhead and complexity. My assumption here is that not too many people
      will miss the removed feature, given that:
      
      - Almost all x86 and powerpc users these days are on 64-bit kernels,
      the majority of today's 32-bit users are on architectures that never
      supported mmap (ARM, MIPS, ...).
      - It never worked in compat mode (it was intentionally disabled there)
      - The application already needs to work with a fallback to
      SNDRV_PCM_IOCTL_SYNC_PTR, which will keep working with both the old
      and new structure layout.
      
      Both the ioctl() and mmap() based interfaces are changed at the same
      time, as they are based on the same structures. Unlike other interfaces,
      we change the uapi header to export both the traditional structure and
      a version that is portable between 32-bit and 64-bit user space code
      and that corresponds to the existing 64-bit layout. We further check the
      __USE_TIME_BITS64 macro that will be defined by future C library versions
      whenever we use the new time_t definition, so any existing user space
      source code will not see any changes until it gets rebuilt against a new
      C library. However, the new structures are all visible in addition to the
      old ones, allowing applications to explicitly request the new structures.
      
      In order to detect the difference between the old snd_pcm_mmap_status and
      the new __snd_pcm_mmap_status64 structure from the ioctl command number,
      we rely on one quirk in the structure definition: snd_pcm_mmap_status
      must be aligned to alignof(time_t), which leads the compiler to insert
      four bytes of padding in struct snd_pcm_sync_ptr after 'flags' and a
      corresponding change in the size of snd_pcm_sync_ptr itself. On x86-32
      (and only there), the compiler doesn't use 64-bit alignment in structure,
      so I'm adding an explicit pad in the structure that has no effect on the
      existing 64-bit architectures but ensures that the layout matches for x86.
      
      The snd_pcm_uframes_t type compatibility requires another hack: we can't
      easily make that 64 bit wide, so I leave the type as 'unsigned long',
      but add padding before and after it, to ensure that the data is properly
      aligned to the respective 64-bit field in the in-kernel structure.
      
      For the SNDRV_PCM_MMAP_OFFSET_STATUS/CONTROL constants that are used
      as the virtual file offset in the mmap() function, we also have to
      introduce new constants that depend on hte __USE_TIME_BITS64 macro:
      The existing macros are renamed to SNDRV_PCM_MMAP_OFFSET_STATUS_OLD
      and SNDRV_PCM_MMAP_OFFSET_CONTROL_OLD, they continue to work fine on
      64-bit architectures, but stop working on native 32-bit user space.
      The replacement _NEW constants are now used by default for user space
      built with __USE_TIME_BITS64, those now work on all new kernels for x86,
      ppc and alpha (32 and 64 bit, native and compat). It might be a good idea
      for a future alsa-lib to support both the _OLD and _NEW macros and use
      the corresponding structures directly. Unmodified alsa-lib source code
      will retain the current behavior, so it will no longer be able to use
      mmap() for the status/control structures on 32-bit systems, until either
      the C library gets updated to 64-bit time_t or alsa-lib gets updated to
      support both mmap() layouts.
      
      Co-developed-with: Baolin Wang <baolin.wang@linaro.org>
      Signed-off-by: default avatarBaolin Wang <baolin.wang@linaro.org>
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      80fe7430
    • Arnd Bergmann's avatar
      ALSA: move snd_pcm_ioctl_sync_ptr_compat into pcm_native.c · 09d94175
      Arnd Bergmann authored
      This is a preparation patch, moving the compat handler for
      snd_pcm_ioctl_sync_ptr_compat from pcm_compat.c to pcm_native.c.
      No other changes are indented.
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarBaolin Wang <baolin.wang@linaro.org>
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      09d94175
    • Baolin Wang's avatar
      ALSA: Avoid using timespec for struct snd_timer_tread · 07094ae6
      Baolin Wang authored
      The struct snd_timer_tread will use 'timespec' type variables to record
      timestamp, which is not year 2038 safe on 32bits system.
      
      Since the struct snd_timer_tread is passed through read() rather than
      ioctl(), and the read syscall has no command number that lets us pick
      between the 32-bit or 64-bit version of this structure.
      
      Thus we introduced one new command SNDRV_TIMER_IOCTL_TREAD64 and new
      struct snd_timer_tread64 replacing timespec with s64 type to handle
      64bit time_t. That means we will set tu->tread = TREAD_FORMAT_64BIT
      when user space has a 64bit time_t, then we will copy to user with
      struct snd_timer_tread64. Otherwise we will use 32bit time_t variables
      when copying to user.
      
      Moreover this patch replaces timespec type with timespec64 type and
      related y2038 safe APIs.
      Signed-off-by: default avatarBaolin Wang <baolin.wang@linaro.org>
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      07094ae6
  10. 12 Dec, 2019 1 commit
  11. 11 Dec, 2019 6 commits
    • Baolin Wang's avatar
      ALSA: Avoid using timespec for struct snd_rawmidi_status · d9e5582c
      Baolin Wang authored
      The struct snd_rawmidi_status will use 'timespec' type variables to record
      timestamp, which is not year 2038 safe on 32bits system.
      
      Thus we introduced 'struct snd_rawmidi_status32' and 'struct snd_rawmidi_status64'
      to handle 32bit time_t and 64bit time_t in native mode, which replace
      timespec with s64 type.
      
      In compat mode, we renamed or introduced new structures to handle 32bit/64bit
      time_t in compatible mode. The 'struct snd_rawmidi_status32' and
      snd_rawmidi_ioctl_status32() are used to handle 32bit time_t in compat mode.
      'struct compat_snd_rawmidi_status64' is used to handle 64bit time_t.
      
      When glibc changes time_t to 64-bit, any recompiled program will issue ioctl
      commands that the kernel does not understand without this patch.
      Signed-off-by: default avatarBaolin Wang <baolin.wang@linaro.org>
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      d9e5582c
    • Baolin Wang's avatar
      ALSA: Avoid using timespec for struct snd_pcm_status · 3ddee7f8
      Baolin Wang authored
      The struct snd_pcm_status will use 'timespec' type variables to record
      timestamp, which is not year 2038 safe on 32bits system.
      
      Userspace will use SNDRV_PCM_IOCTL_STATUS and SNDRV_PCM_IOCTL_STATUS_EXT
      as commands to issue ioctl() to fill the 'snd_pcm_status' structure in
      userspace. The command number is always defined through _IOR/_IOW/IORW,
      so when userspace changes the definition of 'struct timespec' to use
      64-bit types, the command number also changes.
      
      Thus in the kernel, we now need to define two versions of each such ioctl
      and corresponding ioctl commands to handle 32bit time_t and 64bit time_t
      in native mode:
      struct snd_pcm_status32 {
      	......
      
      	s32 trigger_tstamp_sec;
      	s32 trigger_tstamp_nsec;
      
      	......
      
      	s32 audio_tstamp_sec;
      	s32 audio_tstamp_nsec;
      
      	......
      };
      
      struct snd_pcm_status64 {
      	......
      
      	s32 trigger_tstamp_sec;
      	s32 trigger_tstamp_nsec;
      
      	......
      
      	s32 audio_tstamp_sec;
      	s32 audio_tstamp_nsec;
      
      	......
      };
      
      Moreover in compat file, we renamed or introduced new structures to handle
      32bit/64bit time_t in compatible mode. The 'struct snd_pcm_status32' and
      snd_pcm_status_user32() are used to handle 32bit time_t in compat mode.
      'struct compat_snd_pcm_status64' and snd_pcm_status_user_compat64() are used
      to handle 64bit time_t.
      
      The implicit padding before timespec is made explicit to avoid incompatible
      structure layout between 32-bit and 64-bit x86 due to the different
      alignment requirements, and the snd_pcm_status structure is now hidden
      from the kernel to avoid relying on the timespec definitio definitionn
      
      Finally we can replace SNDRV_PCM_IOCTL_STATUS and SNDRV_PCM_IOCTL_STATUS_EXT
      with new commands and introduce new functions to fill new 'struct snd_pcm_status64'
      instead of using unsafe 'struct snd_pcm_status'. Then in future, the new
      commands can be matched when userspace changes 'timespec' to 64bit type
      to make a size change of 'struct snd_pcm_status'. When glibc changes time_t
      to 64-bit, any recompiled program will issue ioctl commands that the kernel
      does not understand without this patch.
      Signed-off-by: default avatarBaolin Wang <baolin.wang@linaro.org>
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      3ddee7f8
    • Baolin Wang's avatar
      ALSA: Avoid using timespec for struct snd_ctl_elem_value · a4e7dd35
      Baolin Wang authored
      The struct snd_ctl_elem_value will use 'timespec' type variables to record
      timestamp, which is not year 2038 safe on 32bits system.
      
      Since there are no drivers will implemented the tstamp member of the
      struct snd_ctl_elem_value, and also the stucture size will not be changed
      if we change timespec to s64 for tstamp member of struct snd_ctl_elem_value.
      
      From Takashi's comments, "In the library, applications are not expected
      to access to this structure directly. The applications get opaque pointer
      to the structure and must use any control APIs to operate it. Actually the
      library produce no API to handle 'struct snd_ctl_elem_value.tstamp'. This
      means that we can drop this member from alsa-lib without decline of
      functionality." Thus we can simply remove the tstamp member to avoid using
      the type which is not year 2038 safe on 32bits system.
      Signed-off-by: default avatarBaolin Wang <baolin.wang@linaro.org>
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      a4e7dd35
    • Baolin Wang's avatar
      ALSA: Avoid using timespec for struct snd_timer_status · a07804cc
      Baolin Wang authored
      struct snd_timer_status uses 'timespec' type variables to record
      timestamp, which will be changed to an incompatible layout with
      updated user space using 64-bit time_t.
      
      To handle both the old and the new layout on 32-bit architectures,
      this patch introduces 'struct snd_timer_status32' and 'struct snd_timer_status64'
      to handle 32bit time_t and 64bit time_t in native mode and compat mode,
      which replaces timespec with s64 type.
      
      When glibc changes time_t to 64-bit, any recompiled program will issue
      ioctl commands that the kernel does not understand without this patch.
      
      In the public uapi header, snd_timer_status is now guarded by
      an #ifndef __KERNEL__ to avoid referencing 'struct timespec'.
      The timespec definition will be removed from the kernel to prevent
      new y2038 bugs and to avoid the conflict with an incompatible libc
      type of the same name.
      Signed-off-by: default avatarBaolin Wang <baolin.wang@linaro.org>
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      a07804cc
    • Baolin Wang's avatar
      ALSA: Replace timespec with timespec64 · fcae40c9
      Baolin Wang authored
      Since timespec is not year 2038 safe on 32bit system, and we need to
      convert all timespec variables to timespec64 type for sound subsystem.
      
      This patch is used to do preparation for following patches, that will
      convert all structures defined in uapi/sound/asound.h to use 64-bit
      time_t.
      Signed-off-by: default avatarBaolin Wang <baolin.wang@linaro.org>
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      fcae40c9
    • Takashi Iwai's avatar
      ALSA: usb-audio: Support PCM sync_stop · dc5eafe7
      Takashi Iwai authored
      USB-audio driver had some implementation of its own sync-stop
      mechanism.  This patch moved a part of it to the common PCM sync_stop
      ops.
      
      Link: https://lore.kernel.org/r/20191210063454.31603-56-tiwai@suse.deSigned-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      dc5eafe7