Received: by 2002:a25:31c3:0:0:0:0:0 with SMTP id x186csp4367940ybx; Mon, 4 Nov 2019 12:10:00 -0800 (PST) X-Google-Smtp-Source: APXvYqx0kw88FC0JIyXqH3wFpv+UcW9GxZZ4dcv4iGV+5VZQTg5CrWAseU9t0V33zqXddG+cr5vr X-Received: by 2002:a17:906:edb7:: with SMTP id sa23mr25465114ejb.327.1572898200736; Mon, 04 Nov 2019 12:10:00 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1572898200; cv=none; d=google.com; s=arc-20160816; b=pDYNJFvuNBaU9iHFl8GkzrNC5f+W+ua1j8+RSKR360gtYfIUQobktrNhwhqnZfwJvM cg4Bqw5jJ2lPslLXdNHi2zqezYEzbD7HZ83Kt+ZdaFyGLKNx4nq43XIVvOsQXIoM6dxf 9UTEoMizj3T/kNgGpipu51P3957c7OqN/3fgWpT66Fb5iogJUYChFRdppsKiR0fqva60 o/g1lQoDOjYlLl2dwxzcK+iwGZJzRr+jxPlzfzcMclviiom7ZLrPhtzda52gNdhZiqGF YZrTGE2bc71zFkgjWJlDeIJAmKoZmj69NpfxASEw5jgGxL+gbJe1SJ+zoRJJcXwmZ4aI IP4w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject; bh=wL06AxBrFSytPsd95LfQGIfyN5ClEsw2F1oS859KFIs=; b=I8i+9zlil+Gojvv6nIwYPBVv5miM5K6ISPtTG9kuKPoBvAWjIBpp63IedOEO/4ICCO W3d3yZ2YV1q65DKyJOvGPamqRGkxWB40kFoLGAfrblR9ezIH1vTm/TwSPdU6mk5c69Cz f++9TvuGQmKkMrEz+hkq3mpVwgJR5enzDplc/HG95ZCTI9VknMhKropuicY6ncY246qh nb4EYJnAeUD5SLvhyhQUAw8wqMeWcdTMd8xJYVnFF1rpNuWkM+4JZFDhyBx5F0GhzRcH Cmm+M+0Z4NKqfUEzseHS7A0jkSoF3Nq1Ck9/gyy8P1cP5yMK2cIbpJ2ABVOzWcsFGD8l Qu3A== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id d36si7085118ede.44.2019.11.04.12.09.36; Mon, 04 Nov 2019 12:10:00 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728882AbfKDUIz (ORCPT + 99 others); Mon, 4 Nov 2019 15:08:55 -0500 Received: from mga07.intel.com ([134.134.136.100]:12893 "EHLO mga07.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728332AbfKDUIz (ORCPT ); Mon, 4 Nov 2019 15:08:55 -0500 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga005.jf.intel.com ([10.7.209.41]) by orsmga105.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 04 Nov 2019 12:08:54 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.68,268,1569308400"; d="scan'208";a="376445080" Received: from crojewsk-mobl1.ger.corp.intel.com (HELO [10.251.83.74]) ([10.251.83.74]) by orsmga005.jf.intel.com with ESMTP; 04 Nov 2019 12:08:47 -0800 Subject: Re: [PATCH 13/14] soundwire: intel: free all resources on hw_free() To: Pierre-Louis Bossart Cc: alsa-devel@alsa-project.org, linux-kernel@vger.kernel.org, tiwai@suse.de, broonie@kernel.org, vkoul@kernel.org, gregkh@linuxfoundation.org, jank@cadence.com, srinivas.kandagatla@linaro.org, slawomir.blauciak@intel.com, Bard liao , Rander Wang , Ranjani Sridharan , Sanyog Kale References: <20191023212823.608-1-pierre-louis.bossart@linux.intel.com> <20191023212823.608-14-pierre-louis.bossart@linux.intel.com> From: Cezary Rojewski Message-ID: <42403ea0-e337-81b6-f11a-2a32c1473750@intel.com> Date: Mon, 4 Nov 2019 21:08:45 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: <20191023212823.608-14-pierre-louis.bossart@linux.intel.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2019-10-23 23:28, Pierre-Louis Bossart wrote: > Make sure all calls to the SoundWire stream API are done and involve > callback > > Signed-off-by: Rander Wang > Signed-off-by: Pierre-Louis Bossart > --- > drivers/soundwire/intel.c | 40 +++++++++++++++++++++++++++++++++++++-- > 1 file changed, 38 insertions(+), 2 deletions(-) > > diff --git a/drivers/soundwire/intel.c b/drivers/soundwire/intel.c > index af24fa048add..cad1c0b64ee3 100644 > --- a/drivers/soundwire/intel.c > +++ b/drivers/soundwire/intel.c > @@ -548,6 +548,25 @@ static int intel_params_stream(struct sdw_intel *sdw, > return -EIO; > } > > +static int intel_free_stream(struct sdw_intel *sdw, > + struct snd_pcm_substream *substream, > + struct snd_soc_dai *dai, > + int link_id) > +{ > + struct sdw_intel_link_res *res = sdw->link_res; > + struct sdw_intel_stream_free_data free_data; > + > + free_data.substream = substream; > + free_data.dai = dai; > + free_data.link_id = link_id; > + > + if (res->ops && res->ops->free_stream && res->dev) Can res->dev even be null? > + return res->ops->free_stream(res->dev, > + &free_data); > + > + return 0; > +} > + > /* > * bank switch routines > */ > @@ -816,6 +835,7 @@ static int > intel_hw_free(struct snd_pcm_substream *substream, struct snd_soc_dai *dai) > { > struct sdw_cdns *cdns = snd_soc_dai_get_drvdata(dai); > + struct sdw_intel *sdw = cdns_to_intel(cdns); > struct sdw_cdns_dma_data *dma; > int ret; > > @@ -823,12 +843,28 @@ intel_hw_free(struct snd_pcm_substream *substream, struct snd_soc_dai *dai) > if (!dma) > return -EIO; > > + ret = sdw_deprepare_stream(dma->stream); > + if (ret) { > + dev_err(dai->dev, "sdw_deprepare_stream: failed %d", ret); > + return ret; > + } > + I understand that you want to be transparent to caller with failure reasons via dev_err/_warn. However, sdw_deprepare_stream already dumps all the logs we need. The same applies for most of the other calls (and not just in this patch..). Do we really need to be that verbose? Maybe just agree on caller -or- subject being the source for the messaging, align existing usages and thus preventing further duplication? Not forcing anything, just asking for your opinion on this. > ret = sdw_stream_remove_master(&cdns->bus, dma->stream); > - if (ret < 0) > + if (ret < 0) { > dev_err(dai->dev, "remove master from stream %s failed: %d\n", > dma->stream->name, ret); > + return ret; > + } > > - return ret; > + ret = intel_free_stream(sdw, substream, dai, sdw->instance); > + if (ret < 0) { > + dev_err(dai->dev, "intel_free_stream: failed %d", ret); > + return ret; > + } > + > + sdw_release_stream(dma->stream); > + > + return 0; > } Given the structure of this function, shouldn't the generic flow be handled by upper layer i.e. part of sdw core?. Apart from intel_free_stream, the rest looks pretty generic to me and this sole call could easily be extracted into ops. > > static void intel_shutdown(struct snd_pcm_substream *substream, >