kernel/include/uapi/sound/asound.h, branch linux-5.11.y

ALSA: uapi: Fix sparse warning

2020-01-29T20:00:51Z

Fix the following sparse warning generated due to 64-bit compat type having fields defined explicitly with __s32: sound/soc/sof/sof-audio.c:46:31: warning: incorrect type in assignment (different base types) sound/soc/sof/sof-audio.c:46:31: expected restricted snd_pcm_state_t [usertype] state sound/soc/sof/sof-audio.c:46:31: got signed int [usertype] state Fixes: 80fe7430c708 ("ALSA: add new 32-bit layout for snd_pcm_mmap_status/control") Reported-by: Pierre-Louis Bossart Suggested-by: Takashi Iwai Signed-off-by: Ranjani Sridharan Link: https://lore.kernel.org/r/20200129184448.3005-1-ranjani.sridharan@linux.intel.com Signed-off-by: Takashi Iwai

ALSA: control: Fix incompatible protocol error

2019-12-26T15:43:30Z

The recent change to bump the ALSA control API protocol version from 2.0.7 to 2.1.0 caused a regression on user-space; while the user-space expects both the major and the minor versions to be identical with the supported numbers, we changed the minor number from 0 to 1. For recovering from the incompatibility, this patch changes the protocol version again to 2.0.8, which is compatible, but yet higher than the original number 2.0.7, indicating that the protocol change. Fixes: bd3eb4e87eb3 ("ALSA: ctl: bump protocol version up to v2.1.0") Reported-by: Paul Menzel Tested-by: Paul Menzel Link: https://lore.kernel.org/r/s5h1rsr769i.wl-tiwai@suse.de Signed-off-by: Takashi Iwai

ALSA: ctl: bump protocol version up to v2.1.0

2019-12-23T14:57:36Z

In a development period for v5.6 kernel, some changes are introduced to structures in ALSA control interface: - 'tstamp' member is removed from 'struct snd_ctl_elem_value - 'TSTAMP' flag is removed from a set of access flags for 'struct snd_ctl_elem_info' - 'dimen' member is removed from 'struct snd_ctl_elem_info Although these changes were introduced with enough consideration for backward compatibility, they include slightly lose of it. This commit bumps protocol version of ALSA control interface up to v2.1.0. Signed-off-by: Takashi Sakamoto Link: https://lore.kernel.org/r/20191223023921.8151-5-o-takashi@sakamocchi.jp Signed-off-by: Takashi Iwai

ALSA: ctl: remove dimen member from elem_info structure

2019-12-23T14:57:35Z

The 'dimen' member of 'struct snd_ctl_elem_info' is designed to deliver information to use an array of value as multi-dimensional values. This feature is used just by echoaudio PCI driver, and fortunately it's not used by the other applications than 'echomixer' in alsa-tools. In a previous commit, usage of 'dimen' member is removed from echoaudio PCI driver. Nowadays no driver/application use the feature. This commit removes the member from structure. Signed-off-by: Takashi Sakamoto Link: https://lore.kernel.org/r/20191223023921.8151-4-o-takashi@sakamocchi.jp Signed-off-by: Takashi Iwai

ALSA: ctl: remove unused macro for timestamping of elem_value

2019-12-23T14:57:34Z

In a former commit, 'tstamp' member was removed from 'struct snd_ctl_elem_value' in a middle way toward solution of Y2038 issue. In a protocol of ALSA control interface, this member is designed to deliver timestamp information in the value structure when the target element supports SNDRV_CTL_ELEM_ACCESS_TIMESTAMP flag. Actually, the feature is neither used by kernel space nor user space, especiall alsa-lib has no API for the feature. Therefore it's reasonable to remove both of them. Practically, the timestamp information corresponds to no information about type of clock ID. It can bring confusions to applications. Reference: a4e7dd35b9da ("ALSA: Avoid using timespec for struct snd_ctl_elem_value") Signed-off-by: Takashi Sakamoto Link: https://lore.kernel.org/r/20191223023921.8151-2-o-takashi@sakamocchi.jp Signed-off-by: Takashi Iwai

ALSA: uapi: Fix typos and header inclusion in asound.h

2019-12-20T15:45:11Z

The recent changes in uapi/asoundlib.h caused some build errors in alsa-lib side because of a typo and the new included files. Basically asound.h is supposed to be usable also on non-Linux systems, so we've tried to avoid the Linux-specific include files. This patch is an attempt to recover from those changes. Fixes: 3ddee7f88aaf ("ALSA: Avoid using timespec for struct snd_pcm_status") Fixes: 80fe7430c708 ("ALSA: add new 32-bit layout for snd_pcm_mmap_status/control") Link: https://lore.kernel.org/r/20191220153415.2740-5-tiwai@suse.de Signed-off-by: Takashi Iwai

ALSA: bump uapi version numbers

2019-12-13T10:25:58Z

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: Arnd Bergmann

ALSA: add new 32-bit layout for snd_pcm_mmap_status/control

2019-12-13T10:25:58Z

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 Signed-off-by: Baolin Wang Signed-off-by: Arnd Bergmann

ALSA: Avoid using timespec for struct snd_timer_tread

2019-12-13T10:25:57Z

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: Baolin Wang Signed-off-by: Arnd Bergmann

ALSA: Avoid using timespec for struct snd_rawmidi_status

2019-12-11T21:06:16Z

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: Baolin Wang Signed-off-by: Arnd Bergmann