Tag for dmaengine slave_id removal topic branch which should be merged
into v5.17
-----BEGIN PGP SIGNATURE-----
iQIzBAABCAAdFiEE+vs47OPLdNbVcHzyfBQHDyUjg0cFAmG8J+UACgkQfBQHDyUj
g0cmEQ/9H5sOft40t02H4tKkdIm8ZvEL4p58+Dzkv09YR7PjGH9pOWoPikzMozNe
aQVIoMs+0QAe9HmaHNOqEgXX3yCswm+PTl9KoULOzMZGMIbw9KxeippVvpqybgtH
flxVPBN/u++WEyPUHRWkr8TCHRzDZjzOQDlHVfOFTl09oNM302Mmz7XasArDwQkI
X3FIpI4mDsWxXOE2hX+A6zqUTqhakV+KBg7a7/JpPnJ558REsvdOxTTRVyW8dQiW
O5EXvrCqus6Ahtu+NIJ3wHjEHcn2pUBeuDRGJgo729f9tBa4ERcZIWSoMXPNLqZm
jbmyoUZIBt6DCTwwd+k35BtreN47dfxY7KIjX3D3qdWDPOBrWsVUIhbEjkzIUqOa
mnEJf6mdDs9z6qCDTYm+Fly7n0bFaOSs94wLWbccxf5PK1ZnS8yI7XcWrA37WRl/
5196CvFoMx4n68QJeyv1PdMEzSMb2aubniOohgfMrPE1HxBdRYcikzoNExiwZeGs
m5oIAQ0bCAu/Jp1c1m/wMN5hE2KSzGQY6L/8h0Jl4ML1jn2x6QGQa6NkHhpVH2AX
5aNF2tOUFNUN8MxunU7eNTE3icpIwhWnW5emfRwrW7sbhPvssbN+O6Pv30TgjA5e
gvtytGO8sXFhRFKoVpMEPI/CYyYz8hxGJKLnLFSvcLYkZN9yvig=
=Mpf8
-----END PGP SIGNATURE-----
gpgsig -----BEGIN PGP SIGNATURE-----
iQEzBAABCgAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAmG8cOYACgkQJNaLcl1U
h9D+Wgf+PdDgmb/kBATZNCfSa13y0A18EVC0ETrCn7EBQt6UbyU5Zx/rVOe8Sjw+
d/kuqc0WCV3UrSdnZHh1pYpn/eqRh6KJCufMJFQiYAEwjJi5TQ5eYDHf7sd0oEI8
NOkTJbl26UImAsnsHcC35moHyTH2U8sKoEeva5i/MIXxBpn+3cIWnmjUi7ZUEzLu
qmZDPEYHVRklcbFEWI7oehb68hJlTHz2PY9ARM+sTUica9owlTiaGRD2WX+Wtc5G
fx0rWoIiFUGnW2qoRBX7yNOBKvzmT6m+pqPMQ/LAjE1Xa4Cb0e87fm33b1QFhuEk
CYFHAAzKem/3GskXlR57fY4p8CvJmQ==
=6fXc
-----END PGP SIGNATURE-----
Merge tag 'dmaengine_topic_slave_id_removal_5.17' of git://git.kernel.org/pub/scm/linux/kernel/git/vkoul/dmaengine into v4_20211204_digetx_support_hdmi_audio_on_nvidia_tegra20
dmaengine_topic_slave_id_removal_5.17
Tag for dmaengine slave_id removal topic branch which should be merged
into v5.17
This field is no longer set from any driver now, so remove the
last references as well.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Mark Brown <broonie@kernel.org>
Link: https://lore.kernel.org/r/20211122222203.4103644-3-arnd@kernel.org
Signed-off-by: Vinod Koul <vkoul@kernel.org>
When the hardware can only deal with a monotonically increasing
appl_ptr, this flag can be set.
In case the application requests a rewind, be it with a
snd_pcm_rewind() or with a direct change of a mmap'ed pointer followed
by a SNDRV_PCM_IOCTL_SYNC_PTR, this patch checks if a rewind
occurred and returns an error.
Credits to Takashi Iwai for identifying the path with SYNC_PTR and
suggesting the pointer checks.
Suggested-by: Takashi Iwai <tiwai@suse.de>
Reviewed-by: Takashi Iwai <tiwai@suse.de>
Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Link: https://lore.kernel.org/r/20211119230852.206310-3-pierre-louis.bossart@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
In some cases, the appl_ptr passed by userspace is not checked before
being used. This patch adds an unconditional check and returns an
error code should the appl_ptr exceed the ALSA 'boundary'.
Suggested-by: Takashi Iwai <tiwai@suse.de>
Reviewed-by: Takashi Iwai <tiwai@suse.de>
Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Link: https://lore.kernel.org/r/20211119230852.206310-2-pierre-louis.bossart@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The comment about the reused vmalloc helpers is no longer valid after
the recent change for the noncontig allocator. Drop the stale
comment.
Fixes: ad4f93ca41 ("ALSA: memalloc: Use proper SG helpers for noncontig allocations")
Link: https://lore.kernel.org/r/20211110063100.21359-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The recently introduced non-contiguous page allocation support helpers
are using the simplified code to calculate the page and DMA address
based on the vmalloc helpers, but this isn't quite right as the vmap
is valid only for the direct DMA.
This patch corrects those accessors to use the proper SG helpers
instead.
Fixes: a25684a956 ("ALSA: memalloc: Support for non-contiguous page allocation")
Tested-by: Alex Xu (Hello71) <alex_y_xu@yahoo.ca>
Link: https://lore.kernel.org/r/20211108151059.31898-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The recent refactoring of mmap handling caused Oops on some devices
that don't use the standard memory allocations. This patch addresses
it by allowing snd_dma_buffer_mmap() helper to receive the NULL
pointer dmab argument (and return an error appropriately).
Fixes: a202bd1ad8 ("ALSA: core: Move mmap handler into memalloc ops")
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20211107163911.13534-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Like the previous fix (commit c0317c0e87 "ALSA: timer: Fix
use-after-free problem"), we have to unlink slave timer instances
immediately at snd_timer_stop(), too. Otherwise it may leave a stale
entry in the list if the slave instance is freed before actually
running.
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20211105091517.21733-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Although we've covered all calls with NULL dma buffer pointer, so far,
there may be still some else in the wild. For catching such a case
more easily, add a WARN_ON_ONCE() in snd_dma_get_ops().
Fixes: 37af81c599 ("ALSA: core: Abstract memory alloc helpers")
Link: https://lore.kernel.org/r/20211105102103.28148-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
This reverts commit 2d9ea39917.
We've got a regression report showing that the audio got broken the
device over AMD IOMMU. The conversion assumed the wrong pointer /
page mapping for the indirect mapping case, and we need to correct
this urgently, so let's revert it for now.
Fixes: 2d9ea39917 ("ALSA: memalloc: Convert x86 SG-buffer handling with non-contiguous type")
Reported-and-tested-by: Alex Xu (Hello71) <alex_y_xu@yahoo.ca>
Link: https://lore.kernel.org/r/20211104180846.16340-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
When the timer instance was add into ack_list but was not currently in
process, the user could stop it via snd_timer_stop1() without delete it
from the ack_list. Then the user could free the timer instance and when
it was actually processed UAF occurred.
This issue could be reproduced via testcase snd_timer01 in ltp - running
several instances of that testcase at the same time.
What I actually met was that the ack_list of the timer broken and the
kernel went into deadloop with irqoff. That could be detected by
hardlockup detector on board or when we run it on qemu, we could use gdb
to dump the ack_list when the console has no response.
To fix this issue, we delete the timer instance from ack_list and
active_list unconditionally in snd_timer_stop1().
Signed-off-by: Wang Wensheng <wangwensheng4@huawei.com>
Suggested-by: Takashi Iwai <tiwai@suse.de>
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20211103033517.80531-1-wangwensheng4@huawei.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
We've had an x86-specific SG-buffer handling code, but now it can be
merged gracefully with the standard non-contiguous DMA pages.
After the migration, SNDRV_DMA_TYPE_DMA_SG becomes identical with
SNDRV_DMA_TYPE_NONCONTIG on x86, while others still fall back to
SNDRV_DMA_TYPE_DEV.
The remaining problem is about the SG-buffer with WC pages: the DMA
core stuff on x86 doesn't treat it well, so we still need some special
handling to manipulate the page attribute manually. The mmap handler
for SNDRV_DMA_TYPE_DEV_SG_WC still returns -ENOENT intentionally for
the fallback to the default handler.
Link: https://lore.kernel.org/r/20211017074859.24112-4-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Following to the addition of non-contiguous pages, this patch adds the
new contiguous non-coherent page allocation to the standard memalloc
helper. Like the previous non-contig type, this non-coherent type is
also directional and requires the explicit sync, too. Hence the
driver using this type of buffer may need to set
SNDRV_PCM_INFO_EXPLICIT_SYNC flag to the PCM hardware.info as well,
unless it's set up in the managed mode.
Link: https://lore.kernel.org/r/20211017074859.24112-3-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
This patch adds the support for allocation of non-contiguous DMA pages
in the common memalloc helper. It's another SG-buffer type, but
unlike the existing one, this is directional and requires the explicit
sync / invalidation of dirty pages on non-coherent architectures.
For this enhancement, the following points are changed:
- snd_dma_device stores the DMA direction.
- snd_dma_device stores need_sync flag indicating whether the explicit
sync is required or not.
- A new variant of helper functions, snd_dma_alloc_dir_pages() and
*_all() are introduced; the old snd_dma_alloc_pages() and *_all()
kept as just wrappers with DMA_BIDIRECTIONAL.
- A new helper snd_dma_buffer_sync() is introduced; this gets called
in the appropriate places.
- A new allocation type, SNDRV_DMA_TYPE_NONCONTIG, is introduced.
When the driver allocates pages with this new type, and it may require
the SNDRV_PCM_INFO_EXPLICIT_SYNC flag set to the PCM hardware.info for
taking the full control of PCM applptr and hwptr changes (that implies
disabling the mmap of control/status data). When the buffer
allocation is managed by snd_pcm_set_managed_buffer(), this flag is
automatically set depending on the result of dma_need_sync()
internally. Otherwise, if the buffer is managed manually, the driver
has to set the flag explicitly, too.
The explicit sync between CPU and device for non-coherent memory is
performed at the points before and after read/write transfer as well
as the applptr/hwptr syncptr ioctl. In the case of mmap mode,
user-space is supposed to call the syncptr ioctl with the hwptr flag
to update and fetch the status at first; this corresponds to CPU-sync.
Then user-space advances the applptr via syncptr ioctl again with
applptr flag, and this corresponds to the device sync with flushing.
Other than the DMA direction and the explicit sync, the usage of this
new buffer type is almost equivalent with the existing
SNDRV_DMA_TYPE_DEV_SG; you can get the page and the address via
snd_sgbuf_get_page() and snd_sgbuf_get_addr(), also calculate the
continuous pages via snd_sgbuf_get_chunk_size().
For those SG-page handling, the non-contig type shares the same ops
with the vmalloc handler. As we do always vmap the SG pages at first,
the actual address can be deduced from the vmapped address easily
without iterating the SG-list.
Link: https://lore.kernel.org/r/20211017074859.24112-2-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
On m68k, compiling drivers under SND_ISA causes build errors:
../sound/core/isadma.c: In function 'snd_dma_program':
../sound/core/isadma.c:33:17: error: implicit declaration of function 'claim_dma_lock' [-Werror=implicit-function-declaration]
33 | flags = claim_dma_lock();
| ^~~~~~~~~~~~~~
../sound/core/isadma.c:41:9: error: implicit declaration of function 'release_dma_lock' [-Werror=implicit-function-declaration]
41 | release_dma_lock(flags);
| ^~~~~~~~~~~~~~~~
../sound/isa/sb/sb16_main.c: In function 'snd_sb16_playback_prepare':
../sound/isa/sb/sb16_main.c:253:72: error: 'DMA_AUTOINIT' undeclared (first use in this function)
253 | snd_dma_program(dma, runtime->dma_addr, size, DMA_MODE_WRITE | DMA_AUTOINIT);
| ^~~~~~~~~~~~
../sound/isa/sb/sb16_main.c:253:72: note: each undeclared identifier is reported only once for each function it appears in
../sound/isa/sb/sb16_main.c: In function 'snd_sb16_capture_prepare':
../sound/isa/sb/sb16_main.c:322:71: error: 'DMA_AUTOINIT' undeclared (first use in this function)
322 | snd_dma_program(dma, runtime->dma_addr, size, DMA_MODE_READ | DMA_AUTOINIT);
| ^~~~~~~~~~~~
and more...
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Cc: Jaroslav Kysela <perex@perex.cz>
Cc: Takashi Iwai <tiwai@suse.com>
Cc: alsa-devel@alsa-project.org
Cc: linux-m68k@lists.linux-m68k.org
Cc: Geert Uytterhoeven <geert@linux-m68k.org>
Link: https://lore.kernel.org/r/20211016062602.3588-1-rdunlap@infradead.org
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Both snd_pcm_delay() and snd_pcm_hwsync() do the almost same thing.
The only difference is that the former calculate the delay, so unify
them as a code cleanup, and treat NULL delay argument only for hwsync
operation.
Also, the patch does a slight code refactoring in snd_pcm_delay().
The initialization of the delay value is done in the caller side now.
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Link: https://lore.kernel.org/r/20211014145323.26506-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
A back-merge of 5.15 branch into 5.16-devel branch for further
development of USB and ALSA core stuff that depends on 5.15 fixes.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Michael Forney reported an incorrect padding type that was defined in
the commit 80fe7430c7 ("ALSA: add new 32-bit layout for
snd_pcm_mmap_status/control") for PCM control mmap data.
His analysis is correct, and this caused the misplacements of PCM
control data on 32bit arch and 32bit compat mode.
The bug is that the __pad2 definition in __snd_pcm_mmap_control64
struct was wrongly with __pad_before_uframe, which should have been
__pad_after_uframe instead. This struct is used in SYNC_PTR ioctl and
control mmap. Basically this bug leads to two problems:
- The offset of avail_min field becomes wrong, it's placed right after
appl_ptr without padding on little-endian
- When appl_ptr and avail_min are read as 64bit values in kernel side,
the values become either zero or corrupted (mixed up)
One good news is that, because both user-space and kernel
misunderstand the wrong offset, at least, 32bit application running on
32bit kernel works as is. Also, 64bit applications are unaffected
because the padding size is zero. The remaining problem is the 32bit
compat mode; as mentioned in the above, avail_min is placed right
after appl_ptr on little-endian archs, 64bit kernel reads bogus values
for appl_ptr updates, which may lead to streaming bugs like jumping,
XRUN or whatever unexpected.
(However, we haven't heard any serious bug reports due to this over
years, so practically seen, it's fairly safe to assume that the impact
by this bug is limited.)
Ideally speaking, we should correct the wrong mmap status control
definition. But this would cause again incompatibility with the
existing binaries, and fixing it (e.g. by renumbering ioctls) would be
really messy.
So, as of this patch, we only correct the behavior of 32bit compat
mode and keep the rest as is. Namely, the SYNC_PTR ioctl is now
handled differently in compat mode to read/write the 32bit values at
the right offsets. The control mmap of 32bit apps on 64bit kernels
has been already disabled (which is likely rather an overlook, but
this worked fine at this time :), so covering SYNC_PTR ioctl should
suffice as a fallback.
Fixes: 80fe7430c7 ("ALSA: add new 32-bit layout for snd_pcm_mmap_status/control")
Reported-by: Michael Forney <mforney@mforney.org>
Reviewed-by: Arnd Bergmann <arnd@arndb.de>
Cc: <stable@vger.kernel.org>
Cc: Rich Felker <dalias@libc.org>
Link: https://lore.kernel.org/r/29QBMJU8DE71E.2YZSH8IHT5HMH@mforney.org
Link: https://lore.kernel.org/r/20211010075546.23220-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
In the case of hot-disconnection of a PCM device, all file operations
except for close should be rejected. This patch adds more sanity
checks in the file operation code paths.
Link: https://lore.kernel.org/r/20211006142214.3089-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
John Keeping reported and posted a patch for a potential UAF in
rawmidi sequencer destruction: the snd_rawmidi_dev_seq_free() may be
called after the associated rawmidi object got already freed.
After a deeper look, it turned out that the bug is rather the
incorrect private_free call order for a snd_seq_device. The
snd_seq_device private_free gets called at the release callback of the
sequencer device object, while this was rather expected to be executed
at the snd_device call chains that runs at the beginning of the whole
card-free procedure. It's been broken since the rewrite of
sequencer-device binding (although it hasn't surfaced because the
sequencer device release happens usually right along with the card
device release).
This patch corrects the private_free call to be done in the right
place, at snd_seq_device_dev_free().
Fixes: 7c37ae5c62 ("ALSA: seq: Rewrite sequencer device binding with standard bus")
Reported-and-tested-by: John Keeping <john@metanate.com>
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20210930114114.8645-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The new framing mode causes the user space regression, because
the alsa-lib code does not initialize the reserved space in
the params structure when the device is opened.
This change adds SNDRV_RAWMIDI_IOCTL_USER_PVERSION like we
do for the PCM interface for the protocol acknowledgment.
Cc: David Henningsson <coding@diwic.se>
Cc: <stable@vger.kernel.org>
Fixes: 08fdced60c ("ALSA: rawmidi: Add framing mode")
BugLink: https://github.com/alsa-project/alsa-lib/issues/178
Signed-off-by: Jaroslav Kysela <perex@perex.cz>
Link: https://lore.kernel.org/r/20210920171850.154186-1-perex@perex.cz
Signed-off-by: Takashi Iwai <tiwai@suse.de>
- Add -s option (strict mode) to merge_config.sh to make it fail when
any symbol is redefined.
- Show a warning if a different compiler is used for building external
modules.
- Infer --target from ARCH for CC=clang to let you cross-compile the
kernel without CROSS_COMPILE.
- Make the integrated assembler default (LLVM_IAS=1) for CC=clang.
- Add <linux/stdarg.h> to the kernel source instead of borrowing
<stdarg.h> from the compiler.
- Add Nick Desaulniers as a Kbuild reviewer.
- Drop stale cc-option tests.
- Fix the combination of CONFIG_TRIM_UNUSED_KSYMS and CONFIG_LTO_CLANG
to handle symbols in inline assembly.
- Show a warning if 'FORCE' is missing for if_changed rules.
- Various cleanups
-----BEGIN PGP SIGNATURE-----
iQJJBAABCgAzFiEEbmPs18K1szRHjPqEPYsBB53g2wYFAmExXHoVHG1hc2FoaXJv
eUBrZXJuZWwub3JnAAoJED2LAQed4NsGAZwP/iHdEZzuQ4cz2uXUaV0fevj9jjPU
zJ8wrrNabAiT6f5x861DsARQSR4OSt3zN0tyBNgZwUdotbe7ED5GegrgIUBMWlML
QskhTEIZj7TexAX/20vx671gtzI3JzFg4c9BuriXCFRBvychSevdJPr65gMDOesL
vOJnXe+SGXG2+fPWi/PxrcOItNRcveqo2GiWHT3g0Cv/DJUulu81gEkz3hrufnMR
cjMeSkV0nJJcvI755OQBOUnEuigW64k4m2WxHPG24tU8cQOCqV6lqwOfNQBAn4+F
OoaCMyPQT9gvGYwGExQMCXGg0wbUt1qnxzOVoA2qFCwbo+MFhqjBvPXab6VJm7CE
mY3RrTtvxSqBdHI6EGcYeLjhycK9b+LLoJ1qc3S9FK8It6NoFFp4XV0R6ItPBls7
mWi9VSpyI6k0AwLq+bGXEHvaX/bnnf/vfqn8H+w6mRZdXjFV8EB2DiOSRX/OqjVG
RnvTtXzWWThLyXvWR3Jox4+7X6728oL7akLemoeZI6oTbJDm7dQgwpz5HbSyHXLh
d+gUF3Y/6lqxT5N9GSVDxpD1bEMh2I7nGQ4M7WGbGas/3yUemF8wbBqGQo4a+YeD
d9vGAUxDp2PQTtL2sjFo5Gd4PZEM9g7vwWzRvHe0o5NxKEXcBg25b8cD1hxrN9Y4
Y1AAnc0kLO+My3PC
=lw3M
-----END PGP SIGNATURE-----
Merge tag 'kbuild-v5.15' of git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild
Pull Kbuild updates from Masahiro Yamada:
- Add -s option (strict mode) to merge_config.sh to make it fail when
any symbol is redefined.
- Show a warning if a different compiler is used for building external
modules.
- Infer --target from ARCH for CC=clang to let you cross-compile the
kernel without CROSS_COMPILE.
- Make the integrated assembler default (LLVM_IAS=1) for CC=clang.
- Add <linux/stdarg.h> to the kernel source instead of borrowing
<stdarg.h> from the compiler.
- Add Nick Desaulniers as a Kbuild reviewer.
- Drop stale cc-option tests.
- Fix the combination of CONFIG_TRIM_UNUSED_KSYMS and CONFIG_LTO_CLANG
to handle symbols in inline assembly.
- Show a warning if 'FORCE' is missing for if_changed rules.
- Various cleanups
* tag 'kbuild-v5.15' of git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild: (39 commits)
kbuild: redo fake deps at include/ksym/*.h
kbuild: clean up objtool_args slightly
modpost: get the *.mod file path more simply
checkkconfigsymbols.py: Fix the '--ignore' option
kbuild: merge vmlinux_link() between ARCH=um and other architectures
kbuild: do not remove 'linux' link in scripts/link-vmlinux.sh
kbuild: merge vmlinux_link() between the ordinary link and Clang LTO
kbuild: remove stale *.symversions
kbuild: remove unused quiet_cmd_update_lto_symversions
gen_compile_commands: extract compiler command from a series of commands
x86: remove cc-option-yn test for -mtune=
arc: replace cc-option-yn uses with cc-option
s390: replace cc-option-yn uses with cc-option
ia64: move core-y in arch/ia64/Makefile to arch/ia64/Kbuild
sparc: move the install rule to arch/sparc/Makefile
security: remove unneeded subdir-$(CONFIG_...)
kbuild: sh: remove unused install script
kbuild: Fix 'no symbols' warning when CONFIG_TRIM_UNUSD_KSYMS=y
kbuild: Switch to 'f' variants of integrated assembler flag
kbuild: Shuffle blank line to improve comment meaning
...
Delete/fixup few includes in anticipation of global -isystem compile
option removal.
Note: crypto/aegis128-neon-inner.c keeps <stddef.h> due to redefinition
of uintptr_t error (one definition comes from <stddef.h>, another from
<linux/types.h>).
Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
ALSA PCM core has an optimized way to communicate with user-space for
its control and status data via mmap on the supported architectures
like x86. Depending on the situation, however, we'd rather want to
enforce user-space notifying the applptr or hwptr change explicitly
via ioctl. For example, the upcoming non-contig and non-coherent
buffer handling would need an explicit sync, and this needs to catch
the applptr and hwptr changes. Also, ASoC SOF driver will have the
SPIB support that has the similar requirement for the explicit control
of the applptr and hwptr.
This patch adds the new PCM hardware info flag,
SNDRV_PCM_INFO_EXPLICIT_SYNC. When this flag is set, PCM core
disables both the control and the status mmap, which enforces
user-space to update via SYNC_PTR ioctl. In that way, drivers can
catch the applptr and hwptr update and apply the sync operation if
needed.
Link: https://lore.kernel.org/r/20210812113818.6479-1-tiwai@suse.de
Link: https://lore.kernel.org/r/20210610205326.1176400-1-pierre-louis.bossart@linux.intel.com
Link: https://lore.kernel.org/r/20210813082142.5375-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
This is an enhancement for the SG-style page handling in vmalloc
buffer handler to calculate the continuous pages.
When snd_sgbuf_get_chunk_size() is called for a vmalloc buffer,
currently we return only the size that fits into a single page.
However, this API call is rather supposed for obtaining the continuous
pages and most of vmalloc or noncontig buffers do have lots of
continuous pages indeed. So, in this patch, the callback now
calculates the possibly continuous pages up to the given size limit.
Note that the end address in the function is calculated from the last
byte, hence it's one byte shorter. This is because ofs + size can be
above the actual buffer size boundary.
Until now, this feature isn't really used, but it'll become useful in
a later patch that adds the non-contiguous buffer type that shares the
same callback function as vmalloc.
Link: https://lore.kernel.org/r/20210812113818.6479-1-tiwai@suse.de
Link: https://lore.kernel.org/r/20210813081645.4680-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Currently we check only the substream->dma_buffer as the preset of the
buffer configuration for verifying the availability of mmap. But a
few drivers rather set up the buffer in the own way without the
standard buffer preallocation using substream->dma_buffer, and they
miss the proper checks. (Now it's working more or less fine as most
of them are running only on x86).
Actually, they may set up the runtime dma_buffer (referred via
snd_pcm_get_dma_buf()) at the open callback, though. That is, this
could have been used as the primary source.
This patch changes the hw_support_mmap() function to check the runtime
dma buffer at first. It's usually NULL with the standard buffer
preallocation, and in that case, we continue checking
substream->dma_buffer as fallback.
Link: https://lore.kernel.org/r/20210809071829.22238-2-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The recent fix c4824ae7db ("ALSA: pcm: Fix mmap capability check")
restricts the mmap capability only to the drivers that properly set up
the buffers, but it caused a regression for a few drivers that manage
the buffer on its own way.
For those with UNKNOWN buffer type (i.e. the uninitialized / unused
substream->dma_buffer), just assume that the driver handles the mmap
properly and blindly trust the hardware info bit.
Fixes: c4824ae7db ("ALSA: pcm: Fix mmap capability check")
Reported-and-tested-by: Jeff Woods <jwoods@fnordco.com>
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/s5him0gpghv.wl-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The code refactoring to move the WC page handling into the common
memalloc layer caused a breakage for HD-audio HDMI. I overlooked that
the driver is using the SG-buffer, which isn't covered by the patch.
This patch adds the mmap workaround for WC pages to SG-buffer
handler. A caveat is that it falls back to the default handler by
returning an error after setting the pgprot, so it won't work in all
cases but merely for PCM (which is currently the only use case).
Fixes: 623c101083 ("ALSA: memalloc: Fix pgprot for WC mmap on x86")
Reported-and-tested-by: Andy Lavr <andy.lavr@gmail.com>
Link: https://lore.kernel.org/r/20210808080034.20337-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
In the recent fix commit eda80d7c9c ("ALSA: memalloc: Fix regression
with SNDRV_DMA_TYPE_CONTINUOUS"), we replaced the pfn argument of the
remap_page_pfn() call from the uninitialized dmab->addr. It was the
right fix, but it'd be more generic if we actually initialize
dmab->area for SNDRV_DMA_TYPE_CONTINOUS, too. e.g. the field is used
in the common snd_sgbuf_get_addr(), too.
This patch adds the initialization of addr field and does revert of
the previous change to refer to it again in the mmap call.
Link: https://lore.kernel.org/r/20210804074125.8170-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
We have a special handling of WC pages on x86, and it's currently
specific to HD-audio. The last forgotten piece was the pgprot setup
for the mmap with WC pages.
This patch moves the pgprot setup for WC pages from HD-audio-specific
mmap callback to the common helper code. It allows us to remove the
superfluous mmap callback in HD-audio and its prepare_mmap
redirection.
Link: https://lore.kernel.org/r/20210804061329.29265-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
There are the generic DMA API calls for allocating and managing the
pages with the write-combined attribute. Let's use them for all
architectures but x86; x86 still needs the special handling to
override the page attributes.
Acked-by: Mark Brown <broonie@kernel.org>
Link: https://lore.kernel.org/r/20210802072815.13551-5-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
A few drivers want to have rather the exact buffer preallocation at
the driver probe time and keep using it for the whole operations
without allowing dynamic buffer allocation. For satisfying the
demands, this patch extends the managed buffer allocation API
slightly.
Namely, when 0 is passed to max argument of the allocation helper
functions snd_pcm_set_managed_buffer*(), it treats as if the fixed
size allocation of the given size. If the pre-allocation fails in
this mode, the function returns now -ENOMEM. Otherwise, i.e. max
argument is non-zero, the function never returns -ENOMEM but tries to
fall back to the smaller chunks and allows the dynamic allocation
later -- which is still the default behavior until now.
For more intuitive use, also two new helpers are added for handling
the fixed size buffer allocation, too: snd_pcm_set_fixed_buffer() and
snd_pcm_set_fixed_buffer_all().
Acked-by: Mark Brown <broonie@kernel.org>
Link: https://lore.kernel.org/r/20210802072815.13551-4-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
SNDRV_DMA_TYPE_DEV_UC and SNDRV_DMA_TYPE_DEV_UC_SG are incorrectly
named as if they were for the uncached memory, while actually we set
the pages as write-combined. Rename them to reflect the right
attribute.
Acked-by: Mark Brown <broonie@kernel.org>
Link: https://lore.kernel.org/r/20210802072815.13551-3-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Return the pointer directly from alloc ops instead of setting
dmab->area at each place. It simplifies the code a bit.
Acked-by: Mark Brown <broonie@kernel.org>
Link: https://lore.kernel.org/r/20210802072815.13551-2-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
It turned out that the current implementation of the port subscription
is racy. The subscription contains two linked lists, and we have to
add to or delete from both lists. Since both connection and
disconnection procedures perform the same order for those two lists
(i.e. src list, then dest list), when a deletion happens during a
connection procedure, the src list may be deleted before the dest list
addition completes, and this may lead to a use-after-free or an Oops,
even though the access to both lists are protected via mutex.
The simple workaround for this race is to change the access order for
the disconnection, namely, dest list, then src list. This assures
that the connection has been established when disconnecting, and also
the concurrent deletion can be avoided.
Reported-and-tested-by: folkert <folkert@vanheusden.com>
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20210801182754.GP890690@belle.intranet.vanheusden.com
Link: https://lore.kernel.org/r/20210803114312.2536-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The recent code refactoring made the mmap of continuous pages to be
done via the own helper snd_dma_continuous_mmap() with
remap_pfn_range(). There I overlooked that dmab->addr isn't set for
the allocation with SNDRV_DMA_TYPE_CONTINUOUS. This resulted always
in an error at mmap with this buffer type on the system such as
Intel SST Baytrail driver.
This patch fixes the regression by passing the correct address.
Fixes: 30b7ba6972 ("ALSA: core: Add continuous and vmalloc mmap ops")
Reported-by: Hans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/8d6674da-7d7b-803e-acc9-7de6cb1223fa@redhat.com
Link: https://lore.kernel.org/r/20210801113801.31290-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
At the transition to the devres-managed card release, we've put the
check of double-free at trigger_card_release(). But this wasn't
enough, as the code path calls snd_card_free() again, and it would
lead to the doubly snd_card_free() calls.
Actually the v1 patch was correct to handle this, but I forgot that
corner case and moved the check to the more obvious place as I thought
it's clearer. But, as usual, devils live in details.
This patch corrects the check of the double-free to the right place,
with a bit more comments.
Fixes: e8ad415b7a ("ALSA: core: Add managed card creation")
Link: https://lore.kernel.org/r/20210731083446.26680-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
MIDI Passthrough sequencer client is assigned always to the fixed
number 14, while it's wrongly documented in the comments as if 62,
which was an old number that was used during development. Fix all
those numbers.
Link: https://lore.kernel.org/r/20210727105232.7321-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The recent rewrite of the memory allocation helpers also changed the
page extraction to a common helper, snd_sgbuf_get_page(). But this
assumes implicitly that the buffer was allocated via the standard
helper (usually via preallocation), and didn't consider the case of
the manual buffer handling.
This patch fixes it and also covers the manual buffer management.
Fixes: 37af81c599 ("ALSA: core: Abstract memory alloc helpers")
Link: https://lore.kernel.org/r/20210720092732.12412-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The hw_support_mmap() doesn't cover all memory allocation types and
might use a wrong device pointer for checking the capability.
Check the all memory allocation types more completely.
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20210720092640.12338-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Mark Brown