linux-kernel - Re: [PATCH v15 29/50] ALSA: usb-audio: qcom: Introduce QC USB SND offloading support

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: <289ae266-c1a4-796a-1f87-387d8ec98646@quicinc.com>
Date: Tue, 13 Feb 2024 14:48:31 -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 29/50] ALSA: usb-audio: qcom: Introduce QC USB SND
 offloading support

Hi Takashi,

On 2/13/2024 2:59 AM, Takashi Iwai wrote:
> On Tue, 13 Feb 2024 01:54:01 +0100,
> Wesley Cheng wrote:
>> +static int __init qc_usb_audio_offload_init(void)
>> +{
>> +	struct uaudio_qmi_svc *svc;
>> +	int ret;
>> +
>> +	svc = kzalloc(sizeof(struct uaudio_qmi_svc), GFP_KERNEL);
>> +	if (!svc)
>> +		return -ENOMEM;
>> +
>> +	svc->uaudio_wq = create_singlethread_workqueue("uaudio_svc");
>> +	if (!svc->uaudio_wq) {
>> +		ret = -ENOMEM;
>> +		goto free_svc;
>> +	}
> 
> Do we need a dedicated workqueue?  I don't mind much, but an own
> workqueue isn't usually needed unless specifically required such as
> the request quantity control or isolation.
> 

I think we can remove this.  I checked the QMI interface implementation 
and looks like they are running all the notifications on its own WQ, so 
doing duplicate work with queuing to our own WQ here in qc_audio_offload.

Thanks
Wesley Cheng