linux-kernel - Re: [PATCH v15 41/50] ASoC: Add SND kcontrol for fetching USB offload status

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]

Date: Tue, 13 Feb 2024 13:10:24 +0100
From: Takashi Iwai <tiwai@...e.de>
To: Wesley Cheng <quic_wcheng@...cinc.com>
Cc: <srinivas.kandagatla@...aro.org>,
	<mathias.nyman@...el.com>,
	<perex@...ex.cz>,
	<conor+dt@...nel.org>,
	<corbet@....net>,
	<lgirdwood@...il.com>,
	<andersson@...nel.org>,
	<krzysztof.kozlowski+dt@...aro.org>,
	<gregkh@...uxfoundation.org>,
	<Thinh.Nguyen@...opsys.com>,
	<broonie@...nel.org>,
	<bgoswami@...cinc.com>,
	<tiwai@...e.com>,
	<robh+dt@...nel.org>,
	<konrad.dybcio@...aro.org>,
	<linux-kernel@...r.kernel.org>,
	<devicetree@...r.kernel.org>,
	<linux-sound@...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 v15 41/50] ASoC: Add SND kcontrol for fetching USB offload status

On Tue, 13 Feb 2024 01:54:13 +0100,
Wesley Cheng wrote:
> 
> Add a kcontrol to the platform sound card to fetch the current offload
> status.  This can allow for userspace to ensure/check which USB SND
> resources are actually busy versus having to attempt opening the USB SND
> devices, which will result in an error if offloading is active.
> 
> An example of fetching the USB offloading status would look like:
> tinymix -D 0 get 'USB Offload Playback Route Status'
> -1, -1 (range -1->32) --> [Offload is idle]
> 
> tinymix -D 0 get 'USB Offload Playback Route Status'
> 1, 0 (range -1->32)  --> [Offload active on card#1 pcm#0]

Ah, I didn't notice until now that the second value is the PCM index.

> +static int snd_soc_usb_offload_status_info(struct snd_kcontrol *kcontrol,
> +			      struct snd_ctl_elem_info *uinfo)
> +{
> +	struct snd_soc_component *component = snd_kcontrol_chip(kcontrol);
> +	struct snd_soc_usb *ctx = snd_soc_find_usb_ctx(component->dev->of_node);
> +
> +	uinfo->type = SNDRV_CTL_ELEM_TYPE_INTEGER;
> +	uinfo->count = 2*ctx->num_supported_streams;
> +	uinfo->value.integer.min = -1;
> +	uinfo->value.integer.max = SNDRV_CARDS;

Then it's bogus to set SNDRV_CARDS as max.  The PCM index number is
independent from the card number.  In theory, it can be even more than
the card max (very unlikely, though).

Wouldn't it be more intuitive to provide two different controls, one
for card number and one for PCM index number?


thanks,

Takashi