linux-kernel - Re: [PATCH 1/2] ALSA: pcm: add SNDRV_PCM_FORMAT_{S,U}20

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <s5hwp2h4dto.wl-tiwai@suse.de>
Date:   Thu, 23 Nov 2017 09:08:35 +0100
From:   Takashi Iwai <tiwai@...e.de>
To:     " Maciej S. Szmigiero " <mail@...iej.szmigiero.name>
Cc:     "Nicolin Chen" <nicoleotsuka@...il.com>,
        "Xiubo Li" <Xiubo.Lee@...il.com>,
        "Jaroslav Kysela" <perex@...ex.cz>, "Timur Tabi" <timur@...i.org>,
        <alsa-devel@...a-project.org>,
        "Liam Girdwood" <lgirdwood@...il.com>,
        "Mark Brown" <broonie@...nel.org>, <linuxppc-dev@...ts.ozlabs.org>,
        "Fabio Estevam" <fabio.estevam@....com>,
        "linux-kernel" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 1/2] ALSA: pcm: add SNDRV_PCM_FORMAT_{S,U}20_4

On Wed, 22 Nov 2017 20:17:34 +0100,
 Maciej S. Szmigiero  wrote:
> 
> This format is similar to existing SNDRV_PCM_FORMAT_{S,U}20_3 that keep
> 20-bit PCM samples in 3 bytes, however i.MX6 platform SSI FIFO does not
> allow 3-byte accesses (including DMA) so a 4-byte format is needed for it.
> 
> Signed-off-by: Maciej S. Szmigiero <mail@...iej.szmigiero.name>
> ---
>  include/sound/pcm.h         |  8 ++++++++
>  include/sound/soc-dai.h     |  2 ++
>  include/uapi/sound/asound.h | 10 +++++++++-
>  sound/core/pcm_misc.c       | 16 ++++++++++++++++
>  4 files changed, 35 insertions(+), 1 deletion(-)
> 
> diff --git a/include/sound/pcm.h b/include/sound/pcm.h
> index 24febf9e177c..7ad2d3f0934f 100644
> --- a/include/sound/pcm.h
> +++ b/include/sound/pcm.h
> @@ -191,6 +191,10 @@ struct snd_pcm_ops {
>  #define SNDRV_PCM_FMTBIT_DSD_U32_LE	_SNDRV_PCM_FMTBIT(DSD_U32_LE)
>  #define SNDRV_PCM_FMTBIT_DSD_U16_BE	_SNDRV_PCM_FMTBIT(DSD_U16_BE)
>  #define SNDRV_PCM_FMTBIT_DSD_U32_BE	_SNDRV_PCM_FMTBIT(DSD_U32_BE)
> +#define SNDRV_PCM_FMTBIT_S20_4LE	_SNDRV_PCM_FMTBIT(S20_4LE)
> +#define SNDRV_PCM_FMTBIT_U20_4LE	_SNDRV_PCM_FMTBIT(U20_4LE)
> +#define SNDRV_PCM_FMTBIT_S20_4BE	_SNDRV_PCM_FMTBIT(S20_4BE)
> +#define SNDRV_PCM_FMTBIT_U20_4BE	_SNDRV_PCM_FMTBIT(U20_4BE)

The conventional names aren't with "4" suffix,
e.g. SNDRV_PCM_FMTBIT_S20_LE.

Also, there are still empty slots under 32, e.g. start from 25.
The formats over 31 were used for 3 bytes or other unusual formats
(although nowadays it makes little sense), and the slots < 32 would
fit for 4 bytes linear format.

It's still an open question whether we should increase the protocol
number when we add a new PCM format definition.  I guess it's not, as
the ABI behavior itself doesn't change, but I might have overlooked
some possible breakage.


thanks,

Takashi