linux-kernel - Re: [PATCH v9 07/34] 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: <fb9c9c18-7383-da2f-86e3-348999b065bd@quicinc.com>
Date:   Tue, 17 Oct 2023 19:07:18 -0700
From:   Wesley Cheng <quic_wcheng@...cinc.com>
To:     Pierre-Louis Bossart <pierre-louis.bossart@...ux.intel.com>,
        <mathias.nyman@...el.com>, <gregkh@...uxfoundation.org>,
        <lgirdwood@...il.com>, <broonie@...nel.org>, <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>
CC:     <linux-usb@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
        <alsa-devel@...a-project.org>, <linux-arm-msm@...r.kernel.org>,
        <devicetree@...r.kernel.org>
Subject: Re: [PATCH v9 07/34] ASoC: Add SOC USB APIs for adding an USB backend

Hi Pierre,

On 10/17/2023 2:48 PM, Pierre-Louis Bossart wrote:
> 
> 
> On 10/17/23 15:00, Wesley Cheng wrote:
>> Some platforms may have support for offloading USB audio devices to a
>> dedicated audio DSP.  Introduce a set of APIs that allow for management of
>> USB sound card and PCM devices enumerated by the USB SND class driver.
>> This allows for the ASoC components to be aware of what USB devices are
> 
> USB devices or USB endpoints? or both?
> 

USB devices.  At least in our case, which endpoints being used will be 
part of handling of the stream start QMI request coming from the audio 
DSP at a later stage.

>> available for offloading.
> 
>> +/**
>> + * struct snd_soc_usb_device
>> + * @card_idx - sound card index associated with USB device
>> + * @chip_idx - USB sound chip array index
>> + * @num_playback - number of playback streams
>> + * @num_capture - number of capture streams
> 
> presumably excluding explicit feedback streams?
> 

That's correct.  This doesn't include explicit streams.  This is going 
to be done during the stage mentioned above.  We find the alternate USB 
interface that supports the requested audio profile.  From there the USB 
SND already checks for if any feedback mechanism is used.

>> + **/
>> +struct snd_soc_usb_device {
>> +	int card_idx;
>> +	int chip_idx;
>> +	int num_playback;
>> +	int num_capture;
>> +};
>> +
>> +/**
>> + * struct snd_soc_usb
>> + * @list - list head for SND SOC struct list
>> + * @dev - USB backend device reference
>> + * @component - reference to ASoC component
>> + * @connection_status_cb - callback to notify connection events
>> + * @priv_data - driver data
>> + **/
>> +struct snd_soc_usb {
>> +	struct list_head list;
>> +	struct device *dev;
> 
> usbdev for consistency with the API below?
> 

This is not the usbdev, but the device reference to the DPCM backend DAI 
(q6usb)

>> +	struct snd_soc_component *component;
> 
> could you use component only and infer the device from component->dev?
> 

True, will look into that.

>> +	int (*connection_status_cb)(struct snd_soc_usb *usb,
>> +			struct snd_soc_usb_device *sdev, bool connected);
>> +	void *priv_data;
>> +};
>> +
>> +int snd_soc_usb_connect(struct device *usbdev, struct snd_soc_usb_device *sdev);
>> +int snd_soc_usb_disconnect(struct device *usbdev, struct snd_soc_usb_device *sdev);
>> +void *snd_soc_usb_get_priv_data(struct device *usbdev);
>> +
>> +struct snd_soc_usb *snd_soc_usb_add_port(struct device *dev, void *priv,
> 
> struct device *usbdev for consistency ?
> 
>> +			int (*connection_cb)(struct snd_soc_usb *usb,
>> +			struct snd_soc_usb_device *sdev, bool connected));
>> +int snd_soc_usb_remove_port(struct device *dev);
> 
> struct device *usbdev for consistency ?
> 
> 
>> +struct snd_soc_usb *snd_soc_usb_add_port(struct device *dev, void *priv,
>> +			int (*connection_cb)(struct snd_soc_usb *usb,
>> +			struct snd_soc_usb_device *sdev, bool connected))> +{
>> +	struct snd_soc_usb *usb;
>> +
>> +	usb = devm_kzalloc(dev, sizeof(*usb), GFP_KERNEL);
>> +	if (!usb)
>> +		return ERR_PTR(-ENOMEM);
>> +
>> +	usb->connection_status_cb = connection_cb;
>> +	usb->dev = dev;
>> +	usb->priv_data = priv;
>> +
>> +	mutex_lock(&ctx_mutex);
>> +	list_add_tail(&usb->list, &usb_ctx_list);
>> +	mutex_unlock(&ctx_mutex);
>> +
>> +	return usb;
>> +}
>> +EXPORT_SYMBOL_GPL(snd_soc_usb_add_port);
>> +
>> +/**
>> + * snd_soc_usb_remove_port() - Remove a USB backend port
>> + * @dev: USB backend device
>> + *
>> + * Remove a USB backend device from USB SND SOC.  Memory is freed when USB
>> + * backend is removed.
> 
> when the USB backend driver is unbound?
> 

Will rename.

>> + *
>> + */
>> +int snd_soc_usb_remove_port(struct device *dev)
>> +{
>> +	struct snd_soc_usb *ctx, *tmp;
>> +
>> +	mutex_lock(&ctx_mutex);
>> +	list_for_each_entry_safe(ctx, tmp, &usb_ctx_list, list) {
>> +		if (ctx->dev == dev) {
>> +			list_del(&ctx->list);
>> +			break;
>> +		}
>> +	}
>> +	mutex_unlock(&ctx_mutex);
>> +
>> +	return 0;
> 
> can this return void to align with the current trend?
> 

Sure.

>> +}
>> +EXPORT_SYMBOL_GPL(snd_soc_usb_remove_port);
>> +
>> +/**
>> + * snd_soc_usb_connect() - Notification of USB device connection
>> + * @usbdev: USB bus device
>> + * @card_idx: USB SND card instance
>> + *
>> + * Notify of a new USB SND device connection.  The card_idx can be used to
>> + * handle how the DPCM backend selects, which device to enable USB offloading
>> + * on.
> 
> card_idx is not used below, and I don't see how this relates to a
> notification?
> 

Will fix this comment.

Thanks
Wesley Cheng