From 98c3fa3a9d7a2e405ad5a656793d0117bed00881 Mon Sep 17 00:00:00 2001 From: Takashi Iwai Date: Sun, 8 Aug 2021 09:01:16 +0200 Subject: [PATCH] ALSA: pcm: Fix mmap breakage without explicit buffer setup commit dc0dc8a73e8e4dc33fba93dfe23356cc5a500c57 upstream. The recent fix c4824ae7db41 ("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: c4824ae7db41 ("ALSA: pcm: Fix mmap capability check") Reported-and-tested-by: Jeff Woods Cc: Link: https://lore.kernel.org/r/s5him0gpghv.wl-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman --- sound/core/pcm_native.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/sound/core/pcm_native.c b/sound/core/pcm_native.c index b36c8d94d4dab..c5ef5182fcf19 100644 --- a/sound/core/pcm_native.c +++ b/sound/core/pcm_native.c @@ -251,7 +251,10 @@ static bool hw_support_mmap(struct snd_pcm_substream *substream) switch (substream->dma_buffer.dev.type) { case SNDRV_DMA_TYPE_UNKNOWN: - return false; + /* we can't know the device, so just assume that the driver does + * everything right + */ + return true; case SNDRV_DMA_TYPE_CONTINUOUS: case SNDRV_DMA_TYPE_VMALLOC: return true;