linux-kernel - Re: [PATCH v15 39/50] ASoC: Introduce SND kcontrols to select sound card and PCM device

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: <f2952acb-4f9e-9283-a5bc-1b62164df9bc@quicinc.com>
Date: Wed, 14 Feb 2024 14:57:46 -0800
From: Wesley Cheng <quic_wcheng@...cinc.com>
To: Takashi Iwai <tiwai@...e.de>
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 39/50] ASoC: Introduce SND kcontrols to select sound
 card and PCM device

Hi Takashi,

On 2/13/2024 2:54 AM, Takashi Iwai wrote:
> On Tue, 13 Feb 2024 01:54:11 +0100,
> Wesley Cheng wrote:
>>
>> +static int soc_usb_get_offload_dev(struct snd_kcontrol *kcontrol,
>> +				   struct snd_ctl_elem_value *ucontrol)
>> +{
>> +	struct snd_soc_component *component = snd_kcontrol_chip(kcontrol);
>> +	struct snd_soc_usb *ctx = snd_soc_usb_find_priv_data(component->dev);
>> +	int ret = 0;
>> +
>> +	mutex_lock(&ctx_mutex);
>> +	if (ctx && ctx->get_offload_dev)
>> +		ret = ctx->get_offload_dev(kcontrol, ucontrol);
>> +	mutex_unlock(&ctx_mutex);
> 
> It might be safer to initialize the values with -1 in case when the
> callback isn't available?
> 

Make sense, will do.

>>   /**
>>    * snd_soc_usb_get_components_tag() - Retrieve SOC USB component tag
>>    * @playback: direction of audio stream
>> @@ -157,6 +218,12 @@ EXPORT_SYMBOL_GPL(snd_soc_usb_free_port);
>>    */
>>   int snd_soc_usb_add_port(struct snd_soc_usb *usb)
>>   {
>> +	int ret;
>> +
>> +	ret = snd_soc_usb_control_init(usb->component);
>> +	if (ret < 0)
>> +		return ret;
>> +
>>   	mutex_lock(&ctx_mutex);
>>   	list_add_tail(&usb->list, &usb_ctx_list);
>>   	mutex_unlock(&ctx_mutex);
> 
> We may need to remove the control element upon the driver removal,
> too?  In theory, you can unload the offload stuff while snd-usb-audio
> is still active.
> 

This is managing the control for the ASoC platform card that supports 
offloading.  If we compile the different kernel entities as modules, we 
see that the soc_usb layer has the following users:

soc_usb 16384 3 q6usb,snd_usb_audio_qmi,snd_soc_qcom_offload_utils

So we'd need to remove all these modules before we can unload soc_usb. 
The entity which would be related to the kcontrols created for the ASoC 
sound card would be the q6usb module.  Since the q6usb module is tightly 
coupled with the platform soundcard itself in our design, for the q6usb 
module to be removed, we have to remove the entire ASoC sound card. (in 
which the kcontrols will also be removed)

However, that might not always be the case...so its a good idea to just 
manually remove the kcontrols in soc-usb as you guided.

Thanks
Wesley Cheng