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
next prev parent 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).