Received: by 2002:a05:6358:701b:b0:131:369:b2a3 with SMTP id 27csp4237018rwo; Tue, 25 Jul 2023 02:59:32 -0700 (PDT) X-Google-Smtp-Source: APBJJlF4dNo2uTZUGfcbjHUYPj2MMh8UCr0CbK6h1HcGVc1sKF2vn8ZPB8NE/jMxoqxEkYBnkfyr X-Received: by 2002:a17:906:77d8:b0:993:d8be:53f5 with SMTP id m24-20020a17090677d800b00993d8be53f5mr12599755ejn.14.1690279172532; Tue, 25 Jul 2023 02:59:32 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1690279172; cv=none; d=google.com; s=arc-20160816; b=hTwxJeIepGXMW2jAHJ7DmfSB+tvIrZOW981MnG3tVKsR2ycPb6AVqG7yI/uun5X75Q qfH2SGauwjgmVl/tSNeN0/Zff88GZxND6P81AaDtn0XvlL8dZx8ycRo93f6gA9FVSq+8 nozi+96qpLi5HDcCh3iBNqGFMgWwf6arrYISt2THcFWGMPVL18rOtCqw3kXVED2Av22D dduRqO1fAg1aCO6OwtvA4Zu0rMLLIQifXP+8jTTLWziDiYhJzBvMeCOsPsiY8mnNrsMc CvhQ3DHdBd+2S+Ex07EVPg5W3nZBvXSrnPJzUAOLNwKl2dGKBiTRg7zwM0mP+Hfo/Ry6 LHww== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to:from :references:cc:to:content-language:subject:user-agent:mime-version :date:message-id:dkim-signature; bh=0y4G374r12LvLi6Y3+dvpQ64Uzp8GzbTn1/SGqCX6gE=; fh=RV4Zwgtyz9+1cBYdu9isDG/DnzGaMCOdk+A0J9ZnIAM=; b=ib3AilJPrkSgC9S2kmozkGuLbBcFQA82vK9G1YA0W2nak6pFCucLboDOu4mFSkMUs5 oDE6C7VBs8mLSDpdOzSAHruk8dL/WW7XXCy3PWkeiX3vhbWMBH/7AR1+tgTTGQe34VeC S2npepx7a2Tnv+JUP/Vl0vSQtnKV81eVWntU4vkyZDY6WzOe9T+G1QEFX1Lt2A/bnA5e V+AShBNWycJxZe/oPoCd3ewfggymY7gZHGiaLl/SqwloYqtiUleZSJSM+LM7nOz5nL7L bbG9zhpD4sco9/zDhdZcHQe364j7MpgUb9+hmQNkisZrqb/KQigcIqzJd1otU2ZrOiAR NM4g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=R1HAjGzL; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id l11-20020a170906414b00b009932d9ef1b7si7926197ejk.917.2023.07.25.02.59.07; Tue, 25 Jul 2023 02:59:32 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=R1HAjGzL; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232241AbjGYJSc (ORCPT + 99 others); Tue, 25 Jul 2023 05:18:32 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:55610 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233025AbjGYJS0 (ORCPT ); Tue, 25 Jul 2023 05:18:26 -0400 Received: from mga05.intel.com (mga05.intel.com [192.55.52.43]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 8C9DD11B; Tue, 25 Jul 2023 02:18:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1690276705; x=1721812705; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=+Q06PentsIanzmdfnoZS42vyVmRdVGNF/39w4Rf8BrE=; b=R1HAjGzLkOuzwRsJZAoTh1ul1Pfppk/Xu1/91a8tmBbVHRpz+qWNHipg oY9/L1G4w6yAocYxAmo7PWqKwijRAhCvVSFVI4wIazHBDpWiuPGlEYoz/ s375y8DVRQDp0CQHm/3AlQJrv0CL8K7mY62ztLlxSEUHu8Zy7JcI8WGJT H6m1sMCPtzV9vRqdD/idJXUmVNlmbAWVgEmwVcUeEIKPsEYp2vICznIIE XrfrR+Ih72DBr66uoqCLWYQFltRuRrXz1Zi6bV2Q3EraBjm8SrLjhx1IP mjAlJKlx9vBmS3E9LCDaANAsK02xj58rm7tXZkL/tsX0BCZtcJrFVZZ55 g==; X-IronPort-AV: E=McAfee;i="6600,9927,10781"; a="454048788" X-IronPort-AV: E=Sophos;i="6.01,230,1684825200"; d="scan'208";a="454048788" Received: from orsmga007.jf.intel.com ([10.7.209.58]) by fmsmga105.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 25 Jul 2023 02:18:24 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10781"; a="719980272" X-IronPort-AV: E=Sophos;i="6.01,230,1684825200"; d="scan'208";a="719980272" Received: from mongola-mobl.ger.corp.intel.com (HELO [10.249.37.129]) ([10.249.37.129]) by orsmga007-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 25 Jul 2023 02:18:17 -0700 Message-ID: <9e391c7d-f45b-42f4-fae4-72fba32482db@linux.intel.com> Date: Tue, 25 Jul 2023 10:10:06 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Firefox/102.0 Thunderbird/102.13.0 Subject: Re: [PATCH v4 06/32] ASoC: Add SOC USB APIs for adding an USB backend Content-Language: en-US To: Wesley Cheng , agross@kernel.org, andersson@kernel.org, robh+dt@kernel.org, krzysztof.kozlowski+dt@linaro.org, conor+dt@kernel.org, catalin.marinas@arm.com, will@kernel.org, mathias.nyman@intel.com, gregkh@linuxfoundation.org, lgirdwood@gmail.com, broonie@kernel.org, perex@perex.cz, tiwai@suse.com, srinivas.kandagatla@linaro.org, bgoswami@quicinc.com, Thinh.Nguyen@synopsys.com Cc: linux-arm-msm@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-usb@vger.kernel.org, alsa-devel@alsa-project.org, quic_jackp@quicinc.com, oneukum@suse.com, albertccwang@google.com, o-takashi@sakamocchi.jp References: <20230725023416.11205-1-quic_wcheng@quicinc.com> <20230725023416.11205-7-quic_wcheng@quicinc.com> From: Pierre-Louis Bossart In-Reply-To: <20230725023416.11205-7-quic_wcheng@quicinc.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_EF,NICE_REPLY_A,RCVD_IN_DNSWL_MED, SPF_HELO_NONE,SPF_NONE,T_SCC_BODY_TEXT_LINE,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > +/** > + * struct snd_soc_usb > + * @list - list head for SND SOC struct list > + * @dev - USB backend device reference > + * @component - reference to DAPM component ASoC component, not DAPM. > + * @connection_status_cb - callback to notify connection events > + * @priv_data - driver data > + **/ > +struct snd_soc_usb { > + struct list_head list; > + struct device *dev; > + struct snd_soc_component *component; > + int (*connection_status_cb)(struct snd_soc_usb *usb, int card_idx, > + int connected); It's not clear what 'connected' really refers to, is this a boolean really or is this a "connection_event? > + void *priv_data; > +}; > + > +int snd_soc_usb_connect(struct device *usbdev, int card_idx); > +int snd_soc_usb_disconnect(struct device *usbdev); > +void snd_soc_usb_set_priv_data(struct device *dev, void *priv); this function is not part of this patch, is this intentional to have a get but not a set? > +void *snd_soc_usb_get_priv_data(struct device *usbdev); you are using 'usbdev' and 'dev' for the same type of parameters, why not align on one set of definition with a consistent naming. > +static struct snd_soc_usb *snd_soc_find_usb_ctx(struct device *dev) > +{ > + struct device_node *node; > + struct snd_soc_usb *ctx = NULL; this init doesn't seem required? > + > + node = snd_soc_find_phandle(dev); > + if (IS_ERR(node)) > + return NULL; > + > + mutex_lock(&ctx_mutex); > + list_for_each_entry(ctx, &usb_ctx_list, list) { > + if (ctx->dev->of_node == node) { > + of_node_put(node); > + mutex_unlock(&ctx_mutex); > + return ctx; > + } > + } > + of_node_put(node); > + mutex_unlock(&ctx_mutex); > + > + return NULL; > +} > + > +/** > + * 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); so in this function you walk through the usb_ctx_list with locking... > + if (!ctx) { > + /* Check if backend device */ > + list_for_each_entry(ctx, &usb_ctx_list, list) { ... and here you walk again through the list without locking. Something's weird here, if this was intentional you need to add comments. > + if (dev->of_node == ctx->dev->of_node) > + goto out; > + } > + ctx = NULL; > + } > +out: > + return ctx ? ctx->priv_data : NULL; > +} > +EXPORT_SYMBOL_GPL(snd_soc_usb_get_priv_data); > + > +/** > + * snd_soc_usb_add_port() - Add a USB backend port > + * @dev: USB backend device > + * @priv: private data > + * @connection_cb: connection status callback > + * > + * Register a USB backend device to the SND USB SOC framework. Memory is > + * allocated as part of the USB backend device. > + * > + */ > +struct snd_soc_usb *snd_soc_usb_add_port(struct device *dev, void *priv, > + int (*connection_cb)(struct snd_soc_usb *usb, int card_idx, > + int 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; back to my comment above, you don't seem to need the set_priv_data() ? > + > + 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_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 USB backend selects, which device to enable offloading on. "USB backend" is confusing, not sure if this is the same concept as DPCM "backend" or something else. Please try to avoid overloaded terms. > + * > + */ > +int snd_soc_usb_connect(struct device *usbdev, int card_idx) > +{ > + struct snd_soc_usb *ctx; > + > + if (!usbdev) > + return -ENODEV; > + > + ctx = snd_soc_find_usb_ctx(usbdev); > + if (!ctx) > + return -ENODEV; > + > + if (ctx->connection_status_cb) > + ctx->connection_status_cb(ctx, card_idx, 1); so either the 'connected' value is 1... > + > + return 0; > +} > +EXPORT_SYMBOL_GPL(snd_soc_usb_connect); > + > +/** > + * snd_soc_usb_disconnect() - Notification of USB device disconnection > + * @usbdev: USB bus device > + * > + * Notify of a new USB SND device disconnection to the USB backend. > + * > + */ > +int snd_soc_usb_disconnect(struct device *usbdev) > +{ > + struct snd_soc_usb *ctx; > + > + if (!usbdev) > + return -ENODEV; > + > + ctx = snd_soc_find_usb_ctx(usbdev); > + if (!ctx) > + return -ENODEV; > + > + if (ctx->connection_status_cb) > + ctx->connection_status_cb(ctx, -1, 0); ...and here it's zero. should this 'connected' parameter be a boolean then with true/false value, or do you want to add enums/defines for more flexibility down the road? > + > + return 0; > +} > +EXPORT_SYMBOL_GPL(snd_soc_usb_disconnect);