From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754634AbbJNUyK (ORCPT ); Wed, 14 Oct 2015 16:54:10 -0400 Received: from seldrel01.sonyericsson.com ([37.139.156.2]:14465 "EHLO seldrel01.sonyericsson.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754141AbbJNUyH (ORCPT ); Wed, 14 Oct 2015 16:54:07 -0400 Date: Wed, 14 Oct 2015 13:53:58 -0700 From: Bjorn Andersson To: yfw CC: Andy Gross , "linux-arm-msm@vger.kernel.org" , "linux-soc@vger.kernel.org" , "linux-kernel@vger.kernel.org" , Srinivas Kandagatla Subject: Re: [PATCH v2 5/7] soc: qcom: smd: Support opening additional channels Message-ID: <20151014205358.GK24668@usrtlx11787.corpusers.net> References: <1444423685-14717-1-git-send-email-bjorn.andersson@sonymobile.com> <1444423685-14717-6-git-send-email-bjorn.andersson@sonymobile.com> <561E701C.5070105@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <561E701C.5070105@linaro.org> User-Agent: Mutt/1.5.22 (2013-10-16) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed 14 Oct 08:09 PDT 2015, yfw wrote: > Hi Bjorn, > > On 2015/10/10 4:48, Bjorn Andersson wrote: > > With the qcom_smd_open_channel() API we allow SMD devices to open > > additional SMD channels, to allow implementation of multi-channel SMD > > devices - like Bluetooth. > > > > Channels are opened from the same edge as the calling SMD device is tied > > to. > > [..] > > +/** > > + * qcom_smd_open_channel() - claim additional channels on the same edge > > + * @sdev: smd_device handle > > + * @name: channel name > > + * @cb: callback method to use for incoming data > > + * > > + * Returns a channel handle on success, or -EPROBE_DEFER if the channel isn't > > + * ready. > > + */ > > +struct qcom_smd_channel *qcom_smd_open_channel(struct qcom_smd_device *sdev, > > + const char *name, > > + qcom_smd_cb_t cb) > > +{ > > + struct qcom_smd_channel *channel; > > + struct qcom_smd_edge *edge = sdev->channel->edge; > > + int ret; > > + > > + /* Wait up to HZ for the channel to appear */ > > + ret = wait_event_interruptible_timeout(edge->new_channel_event, > > + (channel = qcom_smd_find_channel(edge, name)) != NULL, > > + HZ); > > + if (!ret) > > + return ERR_PTR(-ETIMEDOUT); > > + > > + if (channel->state != SMD_CHANNEL_CLOSED) { > > + dev_err(&sdev->dev, "channel %s is busy\n", channel->name); > > + return ERR_PTR(-EBUSY); > > + } > > + > > + channel->qsdev = sdev; > > + ret = qcom_smd_channel_open(channel, cb); > > + if (ret) { > > + channel->qsdev = NULL; > > + return ERR_PTR(ret); > > + } > > + > > + /* > > + * Append the list of channel to the channels associated with the sdev > > + */ > > + list_add_tail(&channel->dev_list, &sdev->channel->dev_list); > > + > > + return channel; > > +} > > +EXPORT_SYMBOL(qcom_smd_open_channel); > > + > Do we need qcom_smd_close_channel API here? > On success the channel is associated with the qcom_smd_device, which tears down all associated channels on destruction. I have not yet seen any reason for decoupling the life cycle of a channel further from the device (in most cases it's very must 1:1). But I will update the comment above to clarify this fact, thanks! Regards, Bjorn