linux-kernel - Re: [PATCH v7 06/33] ASoC: Add SOC USB APIs for adding an USB backend

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: <cdd947b2-0272-723b-77ad-c81c5417eac7@quicinc.com>
Date:   Wed, 27 Sep 2023 12:57:48 -0700
From:   Wesley Cheng <quic_wcheng@...cinc.com>
To:     Mark Brown <broonie@...nel.org>
CC:     <mathias.nyman@...el.com>, <gregkh@...uxfoundation.org>,
        <lgirdwood@...il.com>, <perex@...ex.cz>, <tiwai@...e.com>,
        <agross@...nel.org>, <andersson@...nel.org>,
        <konrad.dybcio@...aro.org>, <robh+dt@...nel.org>,
        <krzysztof.kozlowski+dt@...aro.org>, <conor+dt@...nel.org>,
        <srinivas.kandagatla@...aro.org>, <bgoswami@...cinc.com>,
        <Thinh.Nguyen@...opsys.com>, <linux-kernel@...r.kernel.org>,
        <linux-usb@...r.kernel.org>, <alsa-devel@...a-project.org>,
        <linux-arm-msm@...r.kernel.org>, <devicetree@...r.kernel.org>
Subject: Re: [PATCH v7 06/33] ASoC: Add SOC USB APIs for adding an USB backend

Hi Mark,

On 9/27/2023 7:48 AM, Mark Brown wrote:
> On Thu, Sep 21, 2023 at 02:48:16PM -0700, Wesley Cheng wrote:
> 
>> +static struct device_node *snd_soc_find_phandle(struct device *dev)
>> +{
>> +	struct device_node *node;
>> +
>> +	node = of_parse_phandle(dev->of_node, "usb-soc-be", 0);
> 
> Very nitpicky but this function possibly wants a _usb_ in the name, not
> that it *super* matters with it being static.  Or it could just be
> inlined into the only user and not worry about the naming at all.
> 

Thanks for the review!  Sure, let me reshuffle things around a bit and 
just get rid of this function entirely and inline it to the API below.

>> +/**
>> + * snd_soc_usb_get_priv_data() - Retrieve private data stored
>> + * @dev: device reference
>> + *
>> + * Fetch the private data stored in the USB SND SOC structure.
>> + *
>> + */
>> +void *snd_soc_usb_get_priv_data(struct device *dev)
>> +{
>> +	struct snd_soc_usb *ctx;
>> +
>> +	ctx = snd_soc_find_usb_ctx(dev);
>> +	if (!ctx) {
>> +		/* Check if backend device */
>> +		mutex_lock(&ctx_mutex);
>> +		list_for_each_entry(ctx, &usb_ctx_list, list) {
>> +			if (dev->of_node == ctx->dev->of_node) {
>> +				mutex_unlock(&ctx_mutex);
>> +				goto out;
>> +			}
>> +		}
>> +		mutex_unlock(&ctx_mutex);
>> +		ctx = NULL;
>> +	}
> 
> This seems a lot more expensive than I'd expect for a get_priv_data
> operation, usually it's just a container_of() or other constant time
> pulling out of a pointer rather than a linked list walk - the sort of
> thing that people put at the start of functions and do all the time.
> If we need this I think it needs a name that's more clearly tied to the
> use case.
> 
> I didn't actually find the user of this though?

So the end user of this would be the qc_audio_offload driver, within 
prepare_qmi_response().  This is to fetch some information about the 
DPCM backend during the stream enable request.

Previously, I limited the # of snd_soc_usb ports to be registered to 
one, but that would affect the scalability of this layer.  Hence, adding 
a list instead increased the complexity.  Will rename this accordingly.

Thanks
Wesley Cheng