Messages in this thread | | | Date | Wed, 14 Oct 2015 13:53:58 -0700 | From | Bjorn Andersson <> | Subject | Re: [PATCH v2 5/7] soc: qcom: smd: Support opening additional channels |
| |
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
| |