linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: bjorn.andersson@linaro.org (Bjorn Andersson)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 06/14] rpmsg: Indirect all virtio related function calls
Date: Thu, 18 Aug 2016 11:13:52 -0700	[thread overview]
Message-ID: <20160818181352.GV26240@tuxbot> (raw)
In-Reply-To: <D0C04901035AEF47BB4C8387F4AA41F53C5D85@SAFEX1NODE23.st.com>

On Thu 18 Aug 05:14 PDT 2016, Loic PALLARDY wrote:

> > diff --git a/drivers/rpmsg/virtio_rpmsg_bus.c
[..]
> >  struct rpmsg_endpoint *rpmsg_create_ept(struct rpmsg_device *rpdev,
> >  					rpmsg_rx_cb_t cb, void *priv, u32
> > addr)
> >  {
> > -	return __rpmsg_create_ept(rpdev->vrp, rpdev, cb, priv, addr);
> > +	return rpdev->create_ept(rpdev, cb, priv, addr);
> Hi Bjorn,
> 
> It will be good to test if pointer is valid before calling function.
> 

Per the rpmsg_send() implementation, I can make it loud but friendlier
by:

if (WARN_ON(!rpdev))
	return -EINVAL;

[..]
> > 
> > +static const struct rpmsg_device virtio_rpmsg_ops = {
> > +	.create_ept = virtio_rpmsg_create_ept,
> > +	.destroy_ept = virtio_rpmsg_destroy_ept,
> > +	.send = virtio_rpmsg_send,
> > +	.sendto = virtio_rpmsg_sendto,
> > +	.send_offchannel = virtio_rpmsg_send_offchannel,
> > +	.trysend = virtio_rpmsg_trysend,
> > +	.trysendto = virtio_rpmsg_trysendto,
> > +	.trysend_offchannel = virtio_rpmsg_trysend_offchannel,
> > +	.announce_create = virtio_rpmsg_announce_create,
> > +	.announce_destroy = virtio_rpmsg_announce_destroy,
> > +};
> Why not creating a dedicated ops struct like other framework?
> Here ops are mixed with other parameters.
> 

That's a good suggestion...

> > +
> >  /*
> >   * create an rpmsg channel using its name and address info.
> >   * this function will be used to create both static and dynamic
> > @@ -511,6 +568,9 @@ static struct rpmsg_device
> > *rpmsg_create_channel(struct virtproc_info *vrp,
> >  	if (!rpdev)
> >  		return NULL;
> > 
> > +	/* Assign callbacks for rpmsg_channel */
> > +	*rpdev = virtio_rpmsg_ops;
> It is not a simple affectation behind this operation, more a memcopy of the complete struct.
> Not easy to read from my pov.

...and would clean this up. I'll do that.

> > +
> >  	rpdev->vrp = vrp;
> >  	rpdev->src = chinfo->src;
> >  	rpdev->dst = chinfo->dst;
> > @@ -793,11 +853,17 @@ out:
> >  int rpmsg_send(struct rpmsg_endpoint *ept, void *data, int len)
> >  {
> >  	struct rpmsg_device *rpdev = ept->rpdev;
> > +
> > +	return rpdev->send(ept, data, len);
> Test pointer before using it

Yeah, this would follow from the earlier patch.

> 
> > +}
> > +
[..]
> > diff --git a/include/linux/rpmsg.h b/include/linux/rpmsg.h
[..]
> > u32);
> > +	struct rpmsg_endpoint *(*create_ept)(struct rpmsg_device *rpdev,
> > +					    rpmsg_rx_cb_t cb, void *priv, u32
> > addr);
> > +	void (*destroy_ept)(struct rpmsg_endpoint *ept);
> > +
> > +	int (*send)(struct rpmsg_endpoint *ept, void *data, int len);
> > +	int (*sendto)(struct rpmsg_endpoint *ept, void *data, int len, u32
> > dst);
> > +	int (*send_offchannel)(struct rpmsg_endpoint *ept, u32 src, u32 dst,
> > +				  void *data, int len);
> > +
> > +	int (*trysend)(struct rpmsg_endpoint *ept, void *data, int len);
> > +	int (*trysendto)(struct rpmsg_endpoint *ept, void *data, int len, u32
> > dst);
> > +	int (*trysend_offchannel)(struct rpmsg_endpoint *ept, u32 src, u32
> > dst,
> > +			     void *data, int len);
> > +
> > +	int (*announce_create)(struct rpmsg_device *ept);
> > +	int (*announce_destroy)(struct rpmsg_device *ept);
> > +};
> It will be nice to document if ops are mandatory or optional.
> 

I'll break them out in a ops struct and throw in some kerneldoc in both
cases.

Thanks for the feedback!

Regards,
Bjorn

  reply	other threads:[~2016-08-18 18:13 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-08-16  0:17 [PATCH 00/14] Split rpmsg into a framework Bjorn Andersson
2016-08-16  0:17 ` [PATCH 01/14] rpmsg: Enable matching devices with drivers based on DT Bjorn Andersson
2016-08-16  0:17 ` [PATCH 02/14] rpmsg: Name rpmsg devices based on channel id Bjorn Andersson
2016-08-16  0:17 ` [PATCH 03/14] rpmsg: rpmsg_send() operations takes rpmsg_endpoint Bjorn Andersson
2016-08-18  7:36   ` Loic PALLARDY
2016-08-18 18:04     ` Bjorn Andersson
2016-08-16  0:17 ` [PATCH 04/14] rpmsg: Internalize rpmsg_send() implementations Bjorn Andersson
2016-08-16  0:17 ` [PATCH 05/14] rpmsg: Unify rpmsg device vs channel naming Bjorn Andersson
2016-08-16  0:17 ` [PATCH 06/14] rpmsg: Indirect all virtio related function calls Bjorn Andersson
2016-08-18 12:14   ` Loic PALLARDY
2016-08-18 18:13     ` Bjorn Andersson [this message]
2016-08-16  0:17 ` [PATCH 07/14] rpmsg: Split off generic tail of create_channel() Bjorn Andersson
2016-08-16  0:17 ` [PATCH 08/14] rpmsg: Split rpmsg core and virtio backend Bjorn Andersson
2016-08-18 11:59   ` Loic PALLARDY
2016-08-18 18:09     ` Bjorn Andersson
2016-08-16  0:17 ` [PATCH 09/14] rpmsg: Internalize rpmsg core ops Bjorn Andersson
2016-08-16  0:17 ` [PATCH 10/14] rpmsg: virtio: Internalize vrp pointer Bjorn Andersson
2016-08-16  0:17 ` [PATCH 11/14] rpmsg: Move virtio specifics from public header Bjorn Andersson
2016-08-16  0:17 ` [PATCH 12/14] rpmsg: Make rpmsg_create_ept() take channel_info struct Bjorn Andersson
2016-08-16  0:17 ` [PATCH 13/14] rpmsg: Allow callback to return errors Bjorn Andersson
2016-08-16  0:17 ` [PATCH 14/14] rpmsg: Introduce Qualcomm SMD backend Bjorn Andersson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20160818181352.GV26240@tuxbot \
    --to=bjorn.andersson@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).