This patch converts the es1938 driver code to use the new unified PCM
copy callback. It's a straightforward conversion from *_user() to
*_iter() variants in most parts.
Note that copy_from/to_iter() returns the copied bytes, hence the
error condition is adjusted accordingly.
Link: https://lore.kernel.org/r/20230815190136.8987-8-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
This patch converts the SB Emu8000 driver code to use the new unified
PCM copy callback. The conversion is a bit complicated because of
many open code in emu8000_pcm.c. GET_VAL() and LOOP_WRITE() macros
were rewritten / simplified with copy_from_iter(). As
copy_from_iter() updates the internal offset value, we can drop the
corresponding part, too.
Link: https://lore.kernel.org/r/20230815190136.8987-7-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
This patch converts the GUS driver code to use the new unified PCM
copy callback. It's a straightforward conversion from *_user() to
*_iter() variants.
Note that copy_from/to_iter() returns the copied bytes, hence the
error condition is adjusted accordingly.
Link: https://lore.kernel.org/r/20230815190136.8987-6-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Add two more helpers for copying memory between iov_iter and iomem,
which will be used by the new PCM copy ops in a few drivers.
The existing helpers became wrappers of those now.
Note that copy_from/to_iter() returns the copied bytes, hence the
error condition is adjusted accordingly.
Link: https://lore.kernel.org/r/20230815190136.8987-4-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
iov_iter is a universal interface to copy the data chunk from/to
user-space and kernel in a unified manner. This API can fit for ALSA
PCM copy ops, too; we had to split to copy_user and copy_kernel in the
past, and those can be unified to a single ops with iov_iter.
This patch adds a new PCM copy ops that passes iov_iter for copying
both kernel and user-space in the same way. This patch touches only
the ALSA PCM core part, and the actual users will be replaced in the
following patches.
The expansion of iov_iter is done in the PCM core right before calling
each copy callback. It's a bit suboptimal, but I took this now as
it's the most straightforward replacement. The more conversion to
iov_iter in the caller side is a TODO for future.
As of now, the old copy_user and copy_kernel ops are still kept.
Once after all users are converted, we'll drop the old copy_user and
copy_kernel ops, too.
Link: https://lore.kernel.org/r/20230815190136.8987-3-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Create tas2781 side codec HDA driver for Lenovo Laptops. The quantity
of the speakers has been define in ACPI. All of the tas2781s in the
laptop will be aggregated as one audio speaker. The code supports
realtek codec as the primary codec. Code offers several controls for
digtial/analog gain setting during playback, and other for eq params
setting in case of different audio profiles, such as music, voice,
movie, etc.
[ adjusted patch to be applied to the latest for-next branch -- tiwai ]
Signed-off-by: Shenghao Ding <shenghao-ding@ti.com>
Link: https://lore.kernel.org/r/20230818085836.1442-2-shenghao-ding@ti.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Integrate tas2781 configs for Lenovo Laptops. All of the tas2781s in the
laptop will be aggregated as one audio device. The code support realtek
as the primary codec. Rename "struct cs35l41_dev_name" to
"struct scodec_dev_name" for all other side codecs instead of the certain
one.
Signed-off-by: Shenghao Ding <shenghao-ding@ti.com>
Link: https://lore.kernel.org/r/20230818085836.1442-1-shenghao-ding@ti.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
So far we use the embedded struct device for each PCM substreams in
struct snd_pcm. This may result in UAF when the delayed kobj release
is used; each corresponding struct device is still accessed at the
(delayed) device release, while the snd_pcm object may be already
gone.
As a workaround, detach the struct device from the snd_pcm object by
allocating via the new snd_device_alloc() helper.
A caveat is that we store the PCM substream pointer to drvdata since
the device resume and others require the access to it.
This patch is based on the fix Curtis posted initially. In this
patch, the changes are split and use the new helper function instead.
Link: https://lore.kernel.org/r/20230801171928.1460120-1-cujomalainey@chromium.org
Reviewed-by: Jaroslav Kysela <perex@perex.cz>
Signed-off-by: Curtis Malainey <cujomalainey@chromium.org>
Tested-by: Curtis Malainey <cujomalainey@chromium.org>
Link: https://lore.kernel.org/r/20230816160252.23396-4-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Embedding the ctl_dev in the snd_card object may result in UAF when
the delayed kobj release is used; at the delayed kobj release, it
still accesses the struct device itself while the card memory (that
embeds the struct device) may be already gone.
As a workaround, detach the struct device from the card object by
allocating via the new snd_device_alloc() helper. The rest are just
replacing ctl_dev access to the pointer.
This is based on the fix Curtis posted initially. In this patch, the
changes are split and use the new helper function instead.
Link: https://lore.kernel.org/r/20230801171928.1460120-1-cujomalainey@chromium.org
Reviewed-by: Jaroslav Kysela <perex@perex.cz>
Signed-off-by: Curtis Malainey <cujomalainey@chromium.org>
Tested-by: Curtis Malainey <cujomalainey@chromium.org>
Link: https://lore.kernel.org/r/20230816160252.23396-3-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Some systems using CS35L41 with HDA were released without some
required _DSD properties in ACPI. To support these special cases,
add an api to configure the correct properties for systems with
this issue.
This initial commit moves the no _DSD support for Lenovo
Legion Laptops (CLSA0100, CLSA0101) into a new framework which
can be extended to support additional laptops in the future.
Signed-off-by: Stefan Binding <sbinding@opensource.cirrus.com>
Link: https://lore.kernel.org/r/20230815161033.3519-1-sbinding@opensource.cirrus.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
A RAM firmware can only be downloaded if the CS35L56 is currently
running from ROM firmware. The driver must not try to overwrite
the RAM if the CS35L56 is already running from that RAM.
Firmware can be downloaded in these two cases:
- The BIOS has already patched the firmware (secured mode).
In this case the firmware files will only contain tunings that
are safe to overwrite.
- The CS35L56 is running the built-in ROM firmware.
After a RAM firmware has been downloaded it can only be cleared by
hard resetting CS35L56. Some systems only hard-reset during
power-on and do not give the driver control of hard reset.
Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com>
Link: https://lore.kernel.org/r/20230731165726.7940-8-rf@opensource.cirrus.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Always call cs_dsp_power_up() and cs_dsp_run() in
cs35l56_hda_fw_load() even if there aren't any firmware files
to download. Also, if there aren't any firmware files to
download there is no need to do cs35l56_firmware_shutdown() and
cs35l56_system_reset().
If there aren't any firmware files there's no need to write
anything to the CS35L56 registers to make it work - it will
already be running the ROM firmware. So it's not strictly
necessary to start cs_dsp.
But it's perfectly ok to call cs_dsp_power_up() and
cs_dsp_run() without downloading any firmware. This avoids
having to support a state where audio is playing but cs_dsp
is not running.
Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com>
Link: https://lore.kernel.org/r/20230731165726.7940-5-rf@opensource.cirrus.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Only call regcache_mark_dirty() in cs35l56_hda_fw_load() if
the CS35L56 was SYSTEM_RESET.
recache_mark_dirty() changes the behaviour of regcache_sync()
to write out cache values that are not the default value, and
skip cache values that are the default.
AUDIO_REINIT does not reset the registers. regcache_mark_dirty()
after AUDIO_REINIT could cause the regcache_sync() to sync
registers incorrectly because it will assume that all registers
have reset to default.
Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com>
Link: https://lore.kernel.org/r/20230731165726.7940-3-rf@opensource.cirrus.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Move the call to cs_dsp_run() in cs35l56_hda_fw_load() so that it
is after the CS35L56 has been reset/reinit'd and the regmap
cache has been synced.
cs_dsp_run() syncs up ALSA control cache values with the DSP memory
so this must not be done until the firmware has reinitialized.
Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com>
Link: https://lore.kernel.org/r/20230731165726.7940-2-rf@opensource.cirrus.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
`strncpy` is deprecated for use on NUL-terminated destination strings [1].
A suitable replacement is `strscpy` [2] due to the fact that it
guarantees NUL-termination on its destination buffer argument which is
_not_ always the case for `strncpy`!
It should be noted that, in this case, the destination buffer has a
length strictly greater than the source string. Moreover, the source
string is NUL-terminated (and so is the destination) which means there
was no real bug happening here. Nonetheless, this patch would get us one
step closer to eliminating the `strncpy` API in the kernel, as its use
is too ambiguous. We need to favor less ambiguous replacements such as:
strscpy, strscpy_pad, strtomem and strtomem_pad (amongst others).
Technically, my patch yields subtly different behavior. The original
implementation with `strncpy` would fill the entire destination buffer
with null bytes [3] while `strscpy` will leave the junk, uninitialized
bytes trailing after the _mandatory_ NUL-termination. So, if somehow
`card->driver` or `card->shortname` require this NUL-padding behavior
then `strscpy_pad` should be used. My interpretation, though, is that
the aforementioned fields are just fine as NUL-terminated strings.
Please correct my assumptions if needed and I'll send in a v2.
[1]: www.kernel.org/doc/html/latest/process/deprecated.html#strncpy-on-nul-terminated-strings
[2]: manpages.debian.org/testing/linux-manual-4.8/strscpy.9.en.html
[3]: https://linux.die.net/man/3/strncpy
Link: https://github.com/KSPP/linux/issues/90
Link: https://lore.kernel.org/r/20230727-sound-xen-v1-1-89dd161351f1@google.com (related ALSA patch)
Signed-off-by: Justin Stitt <justinstitt@google.com>
Link: https://lore.kernel.org/r/20230727-sound-usb-bcd2000-v1-1-0dc73684b2f0@google.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
`strncpy` is deprecated for use on NUL-terminated destination strings [1].
A suitable replacement is `strscpy` [2] due to the fact that it
guarantees NUL-termination on its destination buffer argument which is
_not_ always the case for `strncpy`!
It should be noted that, in this case, the destination buffer has a
length strictly greater than the source string. Moreover, the source
string is NUL-terminated (and so is the destination) which means there
was no real bug happening here. Nonetheless, this patch would get us one
step closer to eliminating the `strncpy` API in the kernel, as its use
is too ambiguous. We need to favor less ambiguous replacements such as:
strscpy, strscpy_pad, strtomem and strtomem_pad (amongst others).
Technically, my patch yields subtly different behavior. The original
implementation with `strncpy` would fill the entire destination buffer
with null bytes [3] while `strscpy` will leave the junk, uninitialized
bytes trailing after the _mandatory_ NUL-termination. So, if somehow
`pcm->name` or `card->driver/shortname/longname` require this
NUL-padding behavior then `strscpy_pad` should be used. My
interpretation, though, is that the aforementioned fields are just fine
as NUL-terminated strings. Please correct my assumptions if needed and
I'll send in a v2.
[1]: www.kernel.org/doc/html/latest/process/deprecated.html#strncpy-on-nul-terminated-strings
[2]: manpages.debian.org/testing/linux-manual-4.8/strscpy.9.en.html
[3]: https://linux.die.net/man/3/strncpy
Link: https://github.com/KSPP/linux/issues/90
Signed-off-by: Justin Stitt <justinstitt@google.com>
Reviewed-by: Kees Cook <keescook@chromium.org>
Link: https://lore.kernel.org/r/20230727-sound-xen-v1-1-89dd161351f1@google.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
