From: Greg Kroah-Hartman Date: Sun, 7 Nov 2021 14:49:17 +0000 (+0100) Subject: 5.14-stable patches X-Git-Tag: v4.4.292~46 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=8c16ac7e6b4d9fb969e20ff995dbd47b2310fef5;p=thirdparty%2Fkernel%2Fstable-queue.git 5.14-stable patches added patches: alsa-pci-cs46xx-fix-set-up-buffer-type-properly.patch alsa-pci-rme-set-up-buffer-type-properly.patch alsa-pcm-check-mmap-capability-of-runtime-dma-buffer-at-first.patch --- diff --git a/queue-5.14/alsa-pci-cs46xx-fix-set-up-buffer-type-properly.patch b/queue-5.14/alsa-pci-cs46xx-fix-set-up-buffer-type-properly.patch new file mode 100644 index 00000000000..d1608b94402 --- /dev/null +++ b/queue-5.14/alsa-pci-cs46xx-fix-set-up-buffer-type-properly.patch @@ -0,0 +1,95 @@ +From 4d9e9153f1c64d91a125c6967bc0bfb0bb653ea0 Mon Sep 17 00:00:00 2001 +From: Takashi Iwai +Date: Mon, 9 Aug 2021 09:18:29 +0200 +Subject: ALSA: pci: cs46xx: Fix set up buffer type properly + +From: Takashi Iwai + +commit 4d9e9153f1c64d91a125c6967bc0bfb0bb653ea0 upstream. + +CS46xx driver switches the buffer depending on the number of periods, +and in some cases it switches to the own buffer without updating the +buffer type properly. This may cause a problem with the mmap on +exotic architectures that require the own mmap call for the coherent +DMA buffer. + +This patch addresses the potential breakage by replacing the buffer +setup with the proper macro. It also simplifies the source code, +too. + +Link: https://lore.kernel.org/r/20210809071829.22238-4-tiwai@suse.de +Signed-off-by: Takashi Iwai +Signed-off-by: Greg Kroah-Hartman +--- + sound/pci/cs46xx/cs46xx_lib.c | 30 ++++++++---------------------- + 1 file changed, 8 insertions(+), 22 deletions(-) + +--- a/sound/pci/cs46xx/cs46xx_lib.c ++++ b/sound/pci/cs46xx/cs46xx_lib.c +@@ -1121,9 +1121,7 @@ static int snd_cs46xx_playback_hw_params + if (params_periods(hw_params) == CS46XX_FRAGS) { + if (runtime->dma_area != cpcm->hw_buf.area) + snd_pcm_lib_free_pages(substream); +- runtime->dma_area = cpcm->hw_buf.area; +- runtime->dma_addr = cpcm->hw_buf.addr; +- runtime->dma_bytes = cpcm->hw_buf.bytes; ++ snd_pcm_set_runtime_buffer(substream, &cpcm->hw_buf); + + + #ifdef CONFIG_SND_CS46XX_NEW_DSP +@@ -1143,11 +1141,8 @@ static int snd_cs46xx_playback_hw_params + #endif + + } else { +- if (runtime->dma_area == cpcm->hw_buf.area) { +- runtime->dma_area = NULL; +- runtime->dma_addr = 0; +- runtime->dma_bytes = 0; +- } ++ if (runtime->dma_area == cpcm->hw_buf.area) ++ snd_pcm_set_runtime_buffer(substream, NULL); + err = snd_pcm_lib_malloc_pages(substream, params_buffer_bytes(hw_params)); + if (err < 0) { + #ifdef CONFIG_SND_CS46XX_NEW_DSP +@@ -1196,9 +1191,7 @@ static int snd_cs46xx_playback_hw_free(s + if (runtime->dma_area != cpcm->hw_buf.area) + snd_pcm_lib_free_pages(substream); + +- runtime->dma_area = NULL; +- runtime->dma_addr = 0; +- runtime->dma_bytes = 0; ++ snd_pcm_set_runtime_buffer(substream, NULL); + + return 0; + } +@@ -1287,16 +1280,11 @@ static int snd_cs46xx_capture_hw_params( + if (runtime->periods == CS46XX_FRAGS) { + if (runtime->dma_area != chip->capt.hw_buf.area) + snd_pcm_lib_free_pages(substream); +- runtime->dma_area = chip->capt.hw_buf.area; +- runtime->dma_addr = chip->capt.hw_buf.addr; +- runtime->dma_bytes = chip->capt.hw_buf.bytes; ++ snd_pcm_set_runtime_buffer(substream, &chip->capt.hw_buf); + substream->ops = &snd_cs46xx_capture_ops; + } else { +- if (runtime->dma_area == chip->capt.hw_buf.area) { +- runtime->dma_area = NULL; +- runtime->dma_addr = 0; +- runtime->dma_bytes = 0; +- } ++ if (runtime->dma_area == chip->capt.hw_buf.area) ++ snd_pcm_set_runtime_buffer(substream, NULL); + err = snd_pcm_lib_malloc_pages(substream, params_buffer_bytes(hw_params)); + if (err < 0) + return err; +@@ -1313,9 +1301,7 @@ static int snd_cs46xx_capture_hw_free(st + + if (runtime->dma_area != chip->capt.hw_buf.area) + snd_pcm_lib_free_pages(substream); +- runtime->dma_area = NULL; +- runtime->dma_addr = 0; +- runtime->dma_bytes = 0; ++ snd_pcm_set_runtime_buffer(substream, NULL); + + return 0; + } diff --git a/queue-5.14/alsa-pci-rme-set-up-buffer-type-properly.patch b/queue-5.14/alsa-pci-rme-set-up-buffer-type-properly.patch new file mode 100644 index 00000000000..97a4a2dc50c --- /dev/null +++ b/queue-5.14/alsa-pci-rme-set-up-buffer-type-properly.patch @@ -0,0 +1,73 @@ +From 0899a7a23047f106c06888769d6cd6ff43d7395f Mon Sep 17 00:00:00 2001 +From: Takashi Iwai +Date: Mon, 9 Aug 2021 09:18:28 +0200 +Subject: ALSA: pci: rme: Set up buffer type properly + +From: Takashi Iwai + +commit 0899a7a23047f106c06888769d6cd6ff43d7395f upstream. + +Although the regression of the mmap was fixed in the recent commit +dc0dc8a73e8e ("ALSA: pcm: Fix mmap breakage without explicit buffer +setup"), RME9652 and HDSP drivers have still potential issues with +their mmap handling. Namely, they use the default mmap handler +without the standard buffer preallocation, and PCM core wouldn't use +the coherent DMA mapping. It's practically OK on x86, but on some +exotic architectures, it wouldn't work. + +This patch addresses the potential breakage by replacing the buffer +setup with the proper macro. It also simplifies the source code, +too. + +Link: https://lore.kernel.org/r/20210809071829.22238-3-tiwai@suse.de +Signed-off-by: Takashi Iwai +Signed-off-by: Greg Kroah-Hartman +--- + sound/pci/rme9652/hdsp.c | 6 ++---- + sound/pci/rme9652/rme9652.c | 6 ++---- + 2 files changed, 4 insertions(+), 8 deletions(-) + +--- a/sound/pci/rme9652/hdsp.c ++++ b/sound/pci/rme9652/hdsp.c +@@ -4518,8 +4518,7 @@ static int snd_hdsp_playback_open(struct + snd_pcm_set_sync(substream); + + runtime->hw = snd_hdsp_playback_subinfo; +- runtime->dma_area = hdsp->playback_buffer; +- runtime->dma_bytes = HDSP_DMA_AREA_BYTES; ++ snd_pcm_set_runtime_buffer(substream, hdsp->playback_dma_buf); + + hdsp->playback_pid = current->pid; + hdsp->playback_substream = substream; +@@ -4595,8 +4594,7 @@ static int snd_hdsp_capture_open(struct + snd_pcm_set_sync(substream); + + runtime->hw = snd_hdsp_capture_subinfo; +- runtime->dma_area = hdsp->capture_buffer; +- runtime->dma_bytes = HDSP_DMA_AREA_BYTES; ++ snd_pcm_set_runtime_buffer(substream, hdsp->capture_dma_buf); + + hdsp->capture_pid = current->pid; + hdsp->capture_substream = substream; +--- a/sound/pci/rme9652/rme9652.c ++++ b/sound/pci/rme9652/rme9652.c +@@ -2279,8 +2279,7 @@ static int snd_rme9652_playback_open(str + snd_pcm_set_sync(substream); + + runtime->hw = snd_rme9652_playback_subinfo; +- runtime->dma_area = rme9652->playback_buffer; +- runtime->dma_bytes = RME9652_DMA_AREA_BYTES; ++ snd_pcm_set_runtime_buffer(substream, rme9652->playback_dma_buf); + + if (rme9652->capture_substream == NULL) { + rme9652_stop(rme9652); +@@ -2339,8 +2338,7 @@ static int snd_rme9652_capture_open(stru + snd_pcm_set_sync(substream); + + runtime->hw = snd_rme9652_capture_subinfo; +- runtime->dma_area = rme9652->capture_buffer; +- runtime->dma_bytes = RME9652_DMA_AREA_BYTES; ++ snd_pcm_set_runtime_buffer(substream, rme9652->capture_dma_buf); + + if (rme9652->playback_substream == NULL) { + rme9652_stop(rme9652); diff --git a/queue-5.14/alsa-pcm-check-mmap-capability-of-runtime-dma-buffer-at-first.patch b/queue-5.14/alsa-pcm-check-mmap-capability-of-runtime-dma-buffer-at-first.patch new file mode 100644 index 00000000000..2b9c618efcd --- /dev/null +++ b/queue-5.14/alsa-pcm-check-mmap-capability-of-runtime-dma-buffer-at-first.patch @@ -0,0 +1,63 @@ +From cbea6e5a7772b7a5b80baa8f98fd77853487fd2a Mon Sep 17 00:00:00 2001 +From: Takashi Iwai +Date: Mon, 9 Aug 2021 09:18:27 +0200 +Subject: ALSA: pcm: Check mmap capability of runtime dma buffer at first + +From: Takashi Iwai + +commit cbea6e5a7772b7a5b80baa8f98fd77853487fd2a upstream. + +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 +Signed-off-by: Greg Kroah-Hartman +--- + sound/core/pcm_native.c | 9 +++++++-- + 1 file changed, 7 insertions(+), 2 deletions(-) + +--- a/sound/core/pcm_native.c ++++ b/sound/core/pcm_native.c +@@ -243,13 +243,18 @@ int snd_pcm_info_user(struct snd_pcm_sub + + static bool hw_support_mmap(struct snd_pcm_substream *substream) + { ++ struct snd_dma_buffer *dmabuf; ++ + if (!(substream->runtime->hw.info & SNDRV_PCM_INFO_MMAP)) + return false; + + if (substream->ops->mmap || substream->ops->page) + return true; + +- switch (substream->dma_buffer.dev.type) { ++ dmabuf = snd_pcm_get_dma_buf(substream); ++ if (!dmabuf) ++ dmabuf = &substream->dma_buffer; ++ switch (dmabuf->dev.type) { + case SNDRV_DMA_TYPE_UNKNOWN: + /* we can't know the device, so just assume that the driver does + * everything right +@@ -259,7 +264,7 @@ static bool hw_support_mmap(struct snd_p + case SNDRV_DMA_TYPE_VMALLOC: + return true; + default: +- return dma_can_mmap(substream->dma_buffer.dev.dev); ++ return dma_can_mmap(dmabuf->dev.dev); + } + } + diff --git a/queue-5.14/series b/queue-5.14/series new file mode 100644 index 00000000000..437bfb52c96 --- /dev/null +++ b/queue-5.14/series @@ -0,0 +1,3 @@ +alsa-pcm-check-mmap-capability-of-runtime-dma-buffer-at-first.patch +alsa-pci-rme-set-up-buffer-type-properly.patch +alsa-pci-cs46xx-fix-set-up-buffer-type-properly.patch