There is no need to set this again if O_CLOEXEC is supported.
Signed-off-by: Rolf Eike Beer <eb@emlix.com>
Signed-off-by: Jaroslav Kysela <perex@perex.cz>
This is a sync with 5.6-rc1 kernel headers. The copy is performed
from the sanitized headers installed via make headers_install.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
SNDRV_CTL_ELEM_ACCESS_TIMESTAMP is removed from 5.6 kernel ABI as the
ctl timestamp field has been never used and deprecated.
Drop the corresponding access from the topology code, too.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The dimen fields of control element has been deprecated, and it's
finally dropped in kernel 5.6 ABI definition. Remove the
corresponding accesses in alsa-lib code.
As of this patch, it's disabled via ifdef, just to be sure. The
disabled code should be removed in a later stage as a cleanup.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
It is not necessary to maintain this information in sync in the configuration
files. Fill the missing entries to the complementary devices.
Signed-off-by: Jaroslav Kysela <perex@perex.cz>
With the conditionals, it may be useful to define the devices
in the included configuration files. To satisfy the specification
requirements (device naming) those device names might require
to be renamed or deleted wrong references from the conflicting
or supported lists.
Signed-off-by: Jaroslav Kysela <perex@perex.cz>
This code was added in commit 75d393a563
without explaining why. I assume it was a mistake, since it looks like
the libtool problem should have gone away a long time ago. The referenced
wiki page https://wiki.debian.org/RpathIssue says:
Since libtool 1.5.2 (released 2004-01-25), on Linux libtool no
longer sets RPATH for any directories in the dynamic linker search
path, so this should no longer be an issue unless upstream used a
really old version of libtool when creating their distribution
tarball.
This code caused problems in OpenEmbedded, where the libtool script is
named "x86_64-oe-linux-libtool" or similar rather than just "libtool",
so the sed command failed with a file not found error. Rather than
adapting the code to OpenEmbedded's peculiarities, it seems best to just
remove the unnecessary code altogether.
Note: The rpath is set (hardcoded) for 'make' but it is corrected
for 'make install' by libtool.
Signed-off-by: Tanu Kaskinen <tanuk@iki.fi>
Signed-off-by: Jaroslav Kysela <perex@perex.cz>
The new ucm2 expects that the longname directory is shared with
the driver directory. Fix that for 'Syntax 2'.
Signed-off-by: Jaroslav Kysela <perex@perex.cz>
The tplg_elem_free() is called in the error path from many places
and it is expected that the element object will be unregistered
from the tplg structure, too.
Signed-off-by: Jaroslav Kysela <perex@perex.cz>
- use offsetof() for the lists
- add other info to describe the elements
- use the table in the element constructor
Signed-off-by: Jaroslav Kysela <perex@perex.cz>
This file was imported from the xine project. Update it to the current
revision, which resolves the "no AC_LANG_SOURCE call detected in body"
warnings with Autoconf 2.68 or later.
Cc: Diego Pettenò <flameeyes@gmail.com>
Signed-off-by: David Ward <david.ward@ll.mit.edu>
Signed-off-by: Jaroslav Kysela <perex@perex.cz>
The recent update of sound/*.h to sync with the latest Linus uapi
files broke the build of alsa-tools programs. These files used to be
a modified version of Linux sound/* header files, so that they could
be built without Linux headers. The special prefix like __user and
other things were worked around there.
We may do that again, but a better approach is to fix those things in
Linux kernel uapi side, while we keep the minimal workaround in
alsa-lib such as the __u16 and co type definitions.
This patch is such an attempt, namely:
- Keep the original $LINUX/uapi/sound/*.h in include/sound/uapi
directory
- The "fixes" are applied to some uapi headers, so that they don't
contain Linux-specific prefix and use of opaque struct like
snd_ctl_elem_id
- The uapi headers are included indirectly from include/sound/*.h
- Some headers have inclusion of type_compat.h for the Linux variable
types and prefixes
- type_compat.h tries to use <linux/types.h> when __linux__ is
defined, instead of the own conflicting definitions
The last type might need a bit more adjustment depending on the
compiler, but it can be fixed locally without disturbing else.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
