26 Oct, 2020
1 commit
-
Kernel-doc markups should use this format:
identifier - descriptionThere is a common comment marked, instead, with kernel-doc
notation.Some identifiers have different names between their prototypes
and the kernel-doc markup.Signed-off-by: Mauro Carvalho Chehab
Acked-by: Mark Brown
Link: https://lore.kernel.org/r/535182d6f55d7a7de293dda9676df68f5f60afc6.1603469755.git.mchehab+huawei@kernel.org
Signed-off-by: Takashi Iwai
08 Sep, 2020
1 commit
-
This patch implements the snd_sof_bytes_ext_volatile_get() to read the
actual parameters from DSP by sending the SOF_IPC_COMP_GET_DATA IPC
for the kcontrol of type SOF_TPLG_KCTL_BYTES_VOLATILE_RO.Signed-off-by: Dharageswari R
Reviewed-by: Guennadi Liakhovetski
Reviewed-by: Ranjani Sridharan
Reviewed-by: Pierre-Louis Bossart
Signed-off-by: Kai Vehmanen
Link: https://lore.kernel.org/r/20200908092825.1813847-2-kai.vehmanen@linux.intel.com
Signed-off-by: Mark Brown
07 Sep, 2020
1 commit
-
Add the definition SOF_TKN_COMP_UUID for the component UUID token, this
shall be used for all types of component in the future.Signed-off-by: Keyon Jie
Reviewed-by: Ranjani Sridharan
Signed-off-by: Kai Vehmanen
Link: https://lore.kernel.org/r/20200904132744.1699575-2-kai.vehmanen@linux.intel.com
Signed-off-by: Mark Brown
04 Sep, 2020
1 commit
-
Currently SOF supports running pipelines on secondary DSP cores in a
limited way. This patch represents the next step in SOF multi-core DSP
support, it adds checks for core ID to individual topology components.
It takes care to power up all the requested cores. More advanced DSP
core power management should be added in the future.Signed-off-by: Pan Xiuli
Signed-off-by: Guennadi Liakhovetski
Reviewed-by: Pierre-Louis Bossart
Reviewed-by: Ranjani Sridharan
Signed-off-by: Kai Vehmanen
Link: https://lore.kernel.org/r/20200902140756.1427005-3-kai.vehmanen@linux.intel.com
Signed-off-by: Mark Brown
26 Aug, 2020
1 commit
-
This step is needed to add possibility to pack sof_ipc_window inside
another one in used FW build tools - for example in extended manifest.
Structure reusability leads to easy parsing function reuse, so source
code is shorter and easier to maintain.Using structures with constant size is less tricky and properly
supported by each toolchain by contrast to variable size elements.This is minor ABI change - backward compatibility is kept.
Signed-off-by: Karol Trzcinski
Reviewed-by: Guennadi Liakhovetski
Reviewed-by: Kai Vehmanen
Reviewed-by: Pierre-Louis Bossart
Signed-off-by: Ranjani Sridharan
Link: https://lore.kernel.org/r/20200825235854.1588034-2-ranjani.sridharan@linux.intel.com
Signed-off-by: Mark Brown
27 Apr, 2020
2 commits
-
Automatically choose DMIC pipeline format configuration depending on
information included in NHLT.
Change the access rights of appropriate kcontrols to read-only in order
to prevent user interference.Signed-off-by: Mateusz Gorski
Reviewed-by: Cezary Rojewski
Reviewed-by: Pierre-Louis Bossart
Link: https://lore.kernel.org/r/20200427132727.24942-4-mateusz.gorski@linux.intel.com
Signed-off-by: Mark Brown -
For pipes supporting multiple input/output formats, kcontrol is
created and selection of pipe input and output configuration
is done based on control set.If more than one configuration is supported, then this patch
allows user to select configuration of choice
using amixer settings.Signed-off-by: Mateusz Gorski
Signed-off-by: Pavan K S
Reviewed-by: Cezary Rojewski
Reviewed-by: Pierre-Louis Bossart
Link: https://lore.kernel.org/r/20200427132727.24942-3-mateusz.gorski@linux.intel.com
Signed-off-by: Mark Brown
22 Apr, 2020
1 commit
-
The recent batch of SOF changes failed to build on some x86
configurations including an allmodconfig, revert the commits:e150ef4169a76 ASoC: SOF: Introduce extended manifest
371091417864b ASoC: SOF: ext_manifest: parse firmware version
7c024b948c206 ASoC: SOF: ext_manifest: parse compiler version
9e72f13ee541c ASoC: SOF: ext_manifest: parse windowsto fix this.
Reported-by: Stephen Rothwell
Signed-off-by: Mark Brown
16 Apr, 2020
8 commits
-
FW interface for HDA DAI parameters was extended with information on
sampling rate and channel count in version 3.16. Align kernel header
with the FW change. This change is backwards compatible. Old firmware
will ignore the values.Signed-off-by: Bard Liao
Signed-off-by: Pierre-Louis Bossart
Reviewed-by: Guennadi Liakhovetski
Reviewed-by: Kai Vehmanen
Link: https://lore.kernel.org/r/20200415202816.934-23-pierre-louis.bossart@linux.intel.com
Signed-off-by: Mark Brown -
FW will need these params for synchronized playback over multiple
DAIs.Signed-off-by: Bard Liao
Signed-off-by: Pierre-Louis Bossart
Reviewed-by: Guennadi Liakhovetski
Reviewed-by: Sławomir Błauciak
Reviewed-by: Kai Vehmanen
Link: https://lore.kernel.org/r/20200415202816.934-21-pierre-louis.bossart@linux.intel.com
Signed-off-by: Mark Brown -
Align struct sof_ipc_cc_version to firmware definition in SOF ABI 3.15.0.
The struct definition was changed due to errors in FW build.
The Cadence XCC compiler produces incorrect linkage section sizes, when a
variable length array is used in the compiler version struct. The firmware
definition was changed to a fixed 32 byte compiler description string.
This length covers all released firmware binaries and thus only a minor
ABI change is needed.As the same structure is used in IPC messages between driver and firmware,
the kernel needs to be aligned to firmware change.Signed-off-by: Pan Xiuli
Signed-off-by: Pierre-Louis Bossart
Reviewed-by: Kai Vehmanen
Link: https://lore.kernel.org/r/20200415202816.934-15-pierre-louis.bossart@linux.intel.com
Signed-off-by: Mark Brown -
Share how many injection probe DMAs and how many probe points
driver can request from FW.
injection_dmas_max 0 means injection is not supported
probe_points_max 0 means whole probes subsystem in FW is not enabled
and not compiled in.ABI version change to 3.14.0
Signed-off-by: Pan Xiuli
Signed-off-by: Pierre-Louis Bossart
Reviewed-by: Kai Vehmanen
Reviewed-by: Guennadi Liakhovetski
Link: https://lore.kernel.org/r/20200415202816.934-10-pierre-louis.bossart@linux.intel.com
Signed-off-by: Mark Brown -
The compiler version and description can be extracted from the
extended manifest content. This information known at build time
does not need to be provided in a mailbox.Signed-off-by: Karol Trzcinski
Signed-off-by: Pierre-Louis Bossart
Reviewed-by: Ranjani Sridharan
Reviewed-by: Kai Vehmanen
Link: https://lore.kernel.org/r/20200415202816.934-8-pierre-louis.bossart@linux.intel.com
Signed-off-by: Mark Brown -
The window description can be extracted from the extended manifest
content. This information known at build time does not need to be
provided in a mailbox.Signed-off-by: Karol Trzcinski
Signed-off-by: Pierre-Louis Bossart
Reviewed-by: Ranjani Sridharan
Reviewed-by: Kai Vehmanen
Link: https://lore.kernel.org/r/20200415202816.934-7-pierre-louis.bossart@linux.intel.com
Signed-off-by: Mark Brown -
The firmware version can be extracted from the extended
manifest content. This information known at build time
does not need to be provided in a mailbox.Signed-off-by: Karol Trzcinski
Signed-off-by: Pierre-Louis Bossart
Reviewed-by: Ranjani Sridharan
Reviewed-by: Kai Vehmanen
Link: https://lore.kernel.org/r/20200415202816.934-6-pierre-louis.bossart@linux.intel.com
Signed-off-by: Mark Brown -
Extended manifest is a place to store build time known firmware
metadata, for example firmware version or used compiler description.
Given information is read on host side before firmware startup.
This part of output binary is located as a first structure in binary
file.
Extended manifest should be skipped in firmware loading routine.Signed-off-by: Karol Trzcinski
Signed-off-by: Pierre-Louis Bossart
Reviewed-by: Ranjani Sridharan
Reviewed-by: Kai Vehmanen
Reviewed-by: Guennadi Liakhovetski
Link: https://lore.kernel.org/r/20200415202816.934-5-pierre-louis.bossart@linux.intel.com
Signed-off-by: Mark Brown
31 Mar, 2020
1 commit
-
This reverts commit 645c08f17f477915f6d900b767e789852f150054
which was reported to break the build a program using this header.The original issue was addressed in the alsa-lib side recently, so we
can make the header more self-contained again.Reported-by: Dmitry V. Levin
Fixes: 645c08f17f47 ("ALSA: uapi: Drop asound.h inclusion from asoc.h")
Cc:
Link: https://lore.kernel.org/r/20200331090023.8112-1-tiwai@suse.de
Signed-off-by: Takashi Iwai
17 Mar, 2020
4 commits
-
We have added support for bunch of new decoders and parameters for
decoders. To help users find the support bump the version up to 0,2,0.Signed-off-by: Vinod Koul
Reviewed-by: Takashi Iwai
Link: https://lore.kernel.org/r/20200316055221.1944464-10-vkoul@kernel.org
Signed-off-by: Mark Brown -
Add ALAC (Apple Lossless Audio Codec) and APE (Monkey's Lossless Audio
Codec) defines and parameters required to configure these.Signed-off-by: Vinod Koul
Reviewed-by: Takashi Iwai
Link: https://lore.kernel.org/r/20200316055221.1944464-7-vkoul@kernel.org
Signed-off-by: Mark Brown -
Some WMA decoders like WMAv10 etc need some additional encoder option
parameters, so add these as WMA decoder params.Signed-off-by: Vinod Koul
Reviewed-by: Takashi Iwai
Link: https://lore.kernel.org/r/20200316055221.1944464-3-vkoul@kernel.org
Signed-off-by: Mark Brown -
Some codec profiles were missing for WMA, like WMA9/10 lossless and
wma10 pro, so add these profilesSigned-off-by: Vinod Koul
Reviewed-by: Takashi Iwai
Link: https://lore.kernel.org/r/20200316055221.1944464-2-vkoul@kernel.org
Signed-off-by: Mark Brown
02 Mar, 2020
1 commit
-
Adds core id to sof_ipc_comp. The intention of this change
is to inform FW on which core that particular component
should run. Right now core id is only passed when pipeline
is created, which is not flexible enough and doesn't allow
for FW to handle this the right way.Signed-off-by: Pierre-Louis Bossart
Signed-off-by: Tomasz Lauda
Link: https://lore.kernel.org/r/20200228231850.9226-5-pierre-louis.bossart@linux.intel.com
Signed-off-by: Mark Brown
30 Jan, 2020
1 commit
-
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] stateFixes: 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
28 Jan, 2020
1 commit
-
…/sound into for-linus
ASoC: Updates for v5.6
A pretty big release this time around, a lot of new drivers and both
Morimoto-san and Takashi were doing subsystem wide updates as well:- Further big refactorings from Morimoto-san simplifying the core
interfaces and moving things to the component level.
- Transition of drivers to managed buffer allocation and removal of
redundant PCM ioctls.
- New driver support for Ingenic JZ4770, Mediatek MT6660, Qualcomm
WCD934x and WSA881x, and Realtek RT700, RT711, RT715, RT1011, RT1015
and RT1308.
31 Dec, 2019
1 commit
-
A few uapi/sound/*.h headers have been corrected for recovering from
the compile errors with the existing user-space code (alsa-lib) by the
recent commits. OTOH, these introduced another regression, as now
linux/types.h inclusion became mandatory for the uapi header checks.As a compromise, this patch re-adds linux/types.h inclusions again,
but conditionally not to break other non-standard user-space stuff
again.Fixes: 2e4688676392 ("ALSA: emu10k1: Make uapi/emu10k1.h compilable again")
Fixes: d63e63d42107 ("ALSA: hdsp: Make uapi/hdsp.h compilable again")
Fixes: 4fa406caf950 ("ALSA: hdspm: Drop linux/types.h inclusion in uapi header")
Reported-by: kbuild test robot
Link: https://lore.kernel.org/r/20191230212742.28925-1-tiwai@suse.de
Signed-off-by: Takashi Iwai
26 Dec, 2019
1 commit
-
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
23 Dec, 2019
3 commits
-
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_infoAlthough 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 -
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 -
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
21 Dec, 2019
1 commit
-
We kept some typedefs in uapi/sound/*.h so that the programs in
alsa-tools can be built. Now that alsa-lib takes these and applies
the workarounds in its own, we don't need these typedefs any longer in
the kernel uapi side. Let's drop them.Link: https://lore.kernel.org/r/20191220161555.20232-1-tiwai@suse.de
Signed-off-by: Takashi Iwai
20 Dec, 2019
5 commits
-
The asound.h isn't always available while asoc.h itself is distributed
in alsa-lib package. So we need to avoid the unnecessary inclusion of
asound.h from there.Link: https://lore.kernel.org/r/20191220153415.2740-6-tiwai@suse.de
Signed-off-by: Takashi Iwai -
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 -
The hdspm.h uapi header has been used also from non-Linux or platforms
that don't have linux/*.h. It was OK in the past because alsa-lib
contained the modified version of this header file, but now it tries
to the verbatim copy, so it broke the build. This fixes it again.Link: https://lore.kernel.org/r/20191220153415.2740-4-tiwai@suse.de
Signed-off-by: Takashi Iwai -
Recently alsa-lib updated its content of sound/hdsp.h just by copying
the latest Linus kernel uapi/*.h, and this broke the build of
alsa-tools programs. We used to modify the headers so that they can
be built without asoundlib.h and linux kernel headers, and the
verbatim copy doesn't work as is.This patch removes again the linux/types.h inclusion and drop __user
prefix that broke the build and adjusts the corresponding code.Link: https://lore.kernel.org/r/20191220153415.2740-3-tiwai@suse.de
Signed-off-by: Takashi Iwai -
Recently we updated the content in alsa-lib uapi header files by just
copying from the latest Linus kernel uapi/*.h, and noticed that it
broke the build of some alsa-tools programs. The reason is that we
used to have a modified version in the past, so that the program can
be built without referring to the unexported stuff like
snd_ctl_elem_id or __user prefix.This patch attempts to restore that, i.e. dropping the stuff that
can't be referred in the user-space. For adapting the changes in
uapi/emu10k1.h, the emu10k1 driver code is also slightly modified.
Most of changes are pointer cast.Link: https://lore.kernel.org/r/20191220153415.2740-2-tiwai@suse.de
Signed-off-by: Takashi Iwai
19 Dec, 2019
1 commit
-
Introduce sof_ipc_dai_sai_params to keep information that
we get from topology and we send to DSP FW.
For the moment it is identical to ESAI one but it will
evolve shortly independentlySigned-off-by: Guido Roncarolo
Signed-off-by: Pierre-Louis Bossart
Link: https://lore.kernel.org/r/20191218002616.7652-8-pierre-louis.bossart@linux.intel.com
Signed-off-by: Mark Brown
13 Dec, 2019
3 commits
-
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_STATUS32-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)];
#endifor 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
-
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 -
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
12 Dec, 2019
1 commit
-
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