linux-kernel - Re: [PATCH v26 25/33] ALSA: usb-audio: Save UAC sample size information

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: <b8700e13-2b61-4888-8b7d-c6ab7d713198@linux.intel.com>
Date: Fri, 30 Aug 2024 11:42:04 +0200
From: Pierre-Louis Bossart <pierre-louis.bossart@...ux.intel.com>
To: Wesley Cheng <quic_wcheng@...cinc.com>, srinivas.kandagatla@...aro.org,
 mathias.nyman@...el.com, perex@...ex.cz, conor+dt@...nel.org,
 dmitry.torokhov@...il.com, corbet@....net, broonie@...nel.org,
 lgirdwood@...il.com, tiwai@...e.com, krzk+dt@...nel.org,
 Thinh.Nguyen@...opsys.com, bgoswami@...cinc.com, robh@...nel.org,
 gregkh@...uxfoundation.org
Cc: linux-kernel@...r.kernel.org, devicetree@...r.kernel.org,
 linux-sound@...r.kernel.org, linux-input@...r.kernel.org,
 linux-usb@...r.kernel.org, linux-arm-msm@...r.kernel.org,
 linux-doc@...r.kernel.org, alsa-devel@...a-project.org
Subject: Re: [PATCH v26 25/33] ALSA: usb-audio: Save UAC sample size
 information



On 8/29/24 21:40, Wesley Cheng wrote:
> Within the UAC descriptor, there is information describing the size of a
> sample (bSubframeSize/bSubslotSize) and the number of relevant bits
> (bBitResolution).  Currently, fmt_bits carries only the bit resolution,
> however, some offloading entities may also require the overall size of the
> sample.  Save this information in a separate parameter, as depending on the
> UAC format type, the sample size can not easily be decoded from other
> existing parameters.
> 
> Signed-off-by: Wesley Cheng <quic_wcheng@...cinc.com>
> ---
>  sound/usb/card.h   | 1 +
>  sound/usb/format.c | 1 +
>  2 files changed, 2 insertions(+)
> 
> diff --git a/sound/usb/card.h b/sound/usb/card.h
> index 23d9e6fc69e7..15cda1730076 100644
> --- a/sound/usb/card.h
> +++ b/sound/usb/card.h
> @@ -15,6 +15,7 @@ struct audioformat {
>  	unsigned int channels;		/* # channels */
>  	unsigned int fmt_type;		/* USB audio format type (1-3) */
>  	unsigned int fmt_bits;		/* number of significant bits */
> +	unsigned int fmt_sz;		/* overall audio sub frame/slot size */
>  	unsigned int frame_size;	/* samples per frame for non-audio */
>  	unsigned char iface;		/* interface number */
>  	unsigned char altsetting;	/* corresponding alternate setting */
> diff --git a/sound/usb/format.c b/sound/usb/format.c
> index 3b45d0ee7693..5fde543536a8 100644
> --- a/sound/usb/format.c
> +++ b/sound/usb/format.c
> @@ -80,6 +80,7 @@ static u64 parse_audio_format_i_type(struct snd_usb_audio *chip,
>  	}
>  
>  	fp->fmt_bits = sample_width;
> +	fp->fmt_sz = sample_bytes;
>  
>  	if ((pcm_formats == 0) &&
>  	    (format == 0 || format == (1 << UAC_FORMAT_TYPE_I_UNDEFINED))) {

Should this patch be added first? I mean, I don't see any dependency on
USB offload

I am actually confused as to how the regular USB audio path deals with
format, this must be inferred somewhere from the fmt_bits. Probably a
question for Takashi :-)