All of lore.kernel.org
 help / color / mirror / Atom feed
From: Suman Anna <s-anna@ti.com>
To: Arnaud Pouliquen <arnaud.pouliquen@st.com>,
	Ohad Ben-Cohen <ohad@wizery.com>,
	Bjorn Andersson <bjorn.andersson@linaro.org>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Jiri Slaby <jslaby@suse.com>,
	xiang xiao <xiaoxiang781216@gmail.com>,
	linux-kernel@vger.kernel.org, linux-remoteproc@vger.kernel.org
Cc: Fabien DESSENNE <fabien.dessenne@st.com>,
	linux-stm32@st-md-mailman.stormreply.com,
	Alan Cox <gnomes@lxorguk.ukuu.org.uk>
Subject: Re: [PATCH v5 1/2] rpmsg: core: add API to get message length
Date: Tue, 3 Sep 2019 11:06:06 -0500	[thread overview]
Message-ID: <2a81a04d-e4f9-b9c8-57ec-47f8e140235a@ti.com> (raw)
In-Reply-To: <f6f2ad3e-123a-268b-2586-544752c54db7@st.com>

Hi Arnaud,

On 9/3/19 4:49 AM, Arnaud Pouliquen wrote:
> hi Suman
> 
> On 8/29/19 12:34 AM, Suman Anna wrote:
>> Hi Arnaud,
>>
>> On 8/28/19 10:19 AM, Arnaud Pouliquen wrote:
>>> Return the rpmsg buffer size for sending message, so rpmsg users
>>> can split a long message in several sub rpmsg buffers.
>>
>> Thanks for the patch, I also have a need for the same to be able to
>> compute permissible payload size. Minor comments below.
> 
> Thanks for your review. i will update it ASAP. Then if you need it and
> ack it, i suppose that we could request Bjorn to integrate it in a first
> step, if the rpmsg tty driver has not a level of quality sufficient to
> be accepted...

Yeah, this patch can always be merged independently ahead of the rpmsg
tty driver. Anyways, the tty patch will have to be picked up by a
separate maintainer right. So, it would be nice to get the revised
version get into 5.4

regards
Suman

> 
> Regards
> Arnaud
>>
>>>
>>> Signed-off-by: Arnaud Pouliquen <arnaud.pouliquen@st.com>
>>> ---
>>> V4 to V5 :
>>>    - rename rpmsg_get_buf_payload_size to rpmsg_get_mtu
>>>
>>>   drivers/rpmsg/rpmsg_core.c       | 21 +++++++++++++++++++++
>>>   drivers/rpmsg/rpmsg_internal.h   |  2 ++
>>>   drivers/rpmsg/virtio_rpmsg_bus.c | 10 ++++++++++
>>>   include/linux/rpmsg.h            | 10 ++++++++++
>>>   4 files changed, 43 insertions(+)
>>>
>>> diff --git a/drivers/rpmsg/rpmsg_core.c b/drivers/rpmsg/rpmsg_core.c
>>> index 8122807db380..daca2e24fc71 100644
>>> --- a/drivers/rpmsg/rpmsg_core.c
>>> +++ b/drivers/rpmsg/rpmsg_core.c
>>> @@ -283,6 +283,27 @@ int rpmsg_trysend_offchannel(struct
>>> rpmsg_endpoint *ept, u32 src, u32 dst,
>>>   }
>>>   EXPORT_SYMBOL(rpmsg_trysend_offchannel);
>>>   +/**
>>> + * rpmsg_get_mtu() - get maximum transmission buffer size for
>>> sending message.
>>> + * @ept: the rpmsg endpoint
>>> + *
>>> + * This function returns maximum buffer size available for a single
>>> message.
>>> + *
>>> + * Return: the maximum transmission size on success and an
>>> appropriate error
>>> + * value on failure.
>>> + */
>>> +
>>> +ssize_t rpmsg_get_mtu(struct rpmsg_endpoint *ept)
>>> +{
>>> +    if (WARN_ON(!ept))
>>> +        return -EINVAL;
>>> +    if (!ept->ops->get_buf_mtu)
>>
>> How about calling the ops just get_mtu or rename the function to follow
>> the ops name, like all the others.
>>
>>> +        return -ENXIO;
>>
>> Perhaps ENOTSUPP or EOPNOTSUPP.
>>
>>> +
>>> +    return ept->ops->get_buf_mtu(ept);
>>> +}
>>> +EXPORT_SYMBOL(rpmsg_get_mtu);
>>> +
>>>   /*
>>>    * match an rpmsg channel with a channel info struct.
>>>    * this is used to make sure we're not creating rpmsg devices for
>>> channels
>>> diff --git a/drivers/rpmsg/rpmsg_internal.h
>>> b/drivers/rpmsg/rpmsg_internal.h
>>> index 0d791c30b7ea..645c402569ac 100644
>>> --- a/drivers/rpmsg/rpmsg_internal.h
>>> +++ b/drivers/rpmsg/rpmsg_internal.h
>>> @@ -46,6 +46,7 @@ struct rpmsg_device_ops {
>>>    * @trysend:        see @rpmsg_trysend(), required
>>>    * @trysendto:        see @rpmsg_trysendto(), optional
>>>    * @trysend_offchannel:    see @rpmsg_trysend_offchannel(), optional
>>> + * @get_buf_payload_size: see @rpmsg_get_buf_payload_size(), optional
>>
>> Missed updating the kerneldoc to the new name.
>>
>>>    *
>>>    * Indirection table for the operations that a rpmsg backend should
>>> implement.
>>>    * In addition to @destroy_ept, the backend must at least implement
>>> @send and
>>> @@ -65,6 +66,7 @@ struct rpmsg_endpoint_ops {
>>>                    void *data, int len);
>>>       __poll_t (*poll)(struct rpmsg_endpoint *ept, struct file *filp,
>>>                    poll_table *wait);
>>> +    ssize_t (*get_buf_mtu)(struct rpmsg_endpoint *ept);
>>>   };
>>>     int rpmsg_register_device(struct rpmsg_device *rpdev);
>>> diff --git a/drivers/rpmsg/virtio_rpmsg_bus.c
>>> b/drivers/rpmsg/virtio_rpmsg_bus.c
>>> index e757f0038a1c..f80b1ad23e7e 100644
>>> --- a/drivers/rpmsg/virtio_rpmsg_bus.c
>>> +++ b/drivers/rpmsg/virtio_rpmsg_bus.c
>>> @@ -178,6 +178,7 @@ static int virtio_rpmsg_trysendto(struct
>>> rpmsg_endpoint *ept, void *data,
>>>                     int len, u32 dst);
>>>   static int virtio_rpmsg_trysend_offchannel(struct rpmsg_endpoint
>>> *ept, u32 src,
>>>                          u32 dst, void *data, int len);
>>> +static ssize_t virtio_get_buf_mtu(struct rpmsg_endpoint *ept);
>>
>> Minor nit, virtio_rpmsg_ prefix similar to all the other ops.
>>
>> regards
>> Suman
>>
>>>     static const struct rpmsg_endpoint_ops virtio_endpoint_ops = {
>>>       .destroy_ept = virtio_rpmsg_destroy_ept,
>>> @@ -187,6 +188,7 @@ static const struct rpmsg_endpoint_ops
>>> virtio_endpoint_ops = {
>>>       .trysend = virtio_rpmsg_trysend,
>>>       .trysendto = virtio_rpmsg_trysendto,
>>>       .trysend_offchannel = virtio_rpmsg_trysend_offchannel,
>>> +    .get_buf_mtu = virtio_get_buf_mtu,
>>>   };
>>>     /**
>>> @@ -702,6 +704,14 @@ static int
>>> virtio_rpmsg_trysend_offchannel(struct rpmsg_endpoint *ept, u32 src,
>>>       return rpmsg_send_offchannel_raw(rpdev, src, dst, data, len,
>>> false);
>>>   }
>>>   +static ssize_t virtio_get_buf_mtu(struct rpmsg_endpoint *ept)
>>> +{
>>> +    struct rpmsg_device *rpdev = ept->rpdev;
>>> +    struct virtio_rpmsg_channel *vch = to_virtio_rpmsg_channel(rpdev);
>>> +
>>> +    return vch->vrp->buf_size - sizeof(struct rpmsg_hdr);
>>> +}
>>> +
>>>   static int rpmsg_recv_single(struct virtproc_info *vrp, struct
>>> device *dev,
>>>                    struct rpmsg_hdr *msg, unsigned int len)
>>>   {
>>> diff --git a/include/linux/rpmsg.h b/include/linux/rpmsg.h
>>> index 9fe156d1c018..9d638bf2bdce 100644
>>> --- a/include/linux/rpmsg.h
>>> +++ b/include/linux/rpmsg.h
>>> @@ -135,6 +135,8 @@ int rpmsg_trysend_offchannel(struct
>>> rpmsg_endpoint *ept, u32 src, u32 dst,
>>>   __poll_t rpmsg_poll(struct rpmsg_endpoint *ept, struct file *filp,
>>>               poll_table *wait);
>>>   +ssize_t rpmsg_get_mtu(struct rpmsg_endpoint *ept);
>>> +
>>>   #else
>>>     static inline int register_rpmsg_device(struct rpmsg_device *dev)
>>> @@ -242,6 +244,14 @@ static inline __poll_t rpmsg_poll(struct
>>> rpmsg_endpoint *ept,
>>>       return 0;
>>>   }
>>>   +static ssize_t rpmsg_get_mtu(struct rpmsg_endpoint *ept)
>>> +{
>>> +    /* This shouldn't be possible */
>>> +    WARN_ON(1);
>>> +
>>> +    return -ENXIO;
>>> +}
>>> +
>>>   #endif /* IS_ENABLED(CONFIG_RPMSG) */
>>>     /* use a macro to avoid include chaining to get THIS_MODULE */
>>>
>>

WARNING: multiple messages have this Message-ID (diff)
From: Suman Anna <s-anna@ti.com>
To: Arnaud Pouliquen <arnaud.pouliquen@st.com>,
	Ohad Ben-Cohen <ohad@wizery.com>,
	Bjorn Andersson <bjorn.andersson@linaro.org>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Jiri Slaby <jslaby@suse.com>,
	xiang xiao <xiaoxiang781216@gmail.com>,
	<linux-kernel@vger.kernel.org>,
	<linux-remoteproc@vger.kernel.org>
Cc: Fabien DESSENNE <fabien.dessenne@st.com>,
	<linux-stm32@st-md-mailman.stormreply.com>,
	Alan Cox <gnomes@lxorguk.ukuu.org.uk>
Subject: Re: [PATCH v5 1/2] rpmsg: core: add API to get message length
Date: Tue, 3 Sep 2019 11:06:06 -0500	[thread overview]
Message-ID: <2a81a04d-e4f9-b9c8-57ec-47f8e140235a@ti.com> (raw)
In-Reply-To: <f6f2ad3e-123a-268b-2586-544752c54db7@st.com>

Hi Arnaud,

On 9/3/19 4:49 AM, Arnaud Pouliquen wrote:
> hi Suman
> 
> On 8/29/19 12:34 AM, Suman Anna wrote:
>> Hi Arnaud,
>>
>> On 8/28/19 10:19 AM, Arnaud Pouliquen wrote:
>>> Return the rpmsg buffer size for sending message, so rpmsg users
>>> can split a long message in several sub rpmsg buffers.
>>
>> Thanks for the patch, I also have a need for the same to be able to
>> compute permissible payload size. Minor comments below.
> 
> Thanks for your review. i will update it ASAP. Then if you need it and
> ack it, i suppose that we could request Bjorn to integrate it in a first
> step, if the rpmsg tty driver has not a level of quality sufficient to
> be accepted...

Yeah, this patch can always be merged independently ahead of the rpmsg
tty driver. Anyways, the tty patch will have to be picked up by a
separate maintainer right. So, it would be nice to get the revised
version get into 5.4

regards
Suman

> 
> Regards
> Arnaud
>>
>>>
>>> Signed-off-by: Arnaud Pouliquen <arnaud.pouliquen@st.com>
>>> ---
>>> V4 to V5 :
>>>    - rename rpmsg_get_buf_payload_size to rpmsg_get_mtu
>>>
>>>   drivers/rpmsg/rpmsg_core.c       | 21 +++++++++++++++++++++
>>>   drivers/rpmsg/rpmsg_internal.h   |  2 ++
>>>   drivers/rpmsg/virtio_rpmsg_bus.c | 10 ++++++++++
>>>   include/linux/rpmsg.h            | 10 ++++++++++
>>>   4 files changed, 43 insertions(+)
>>>
>>> diff --git a/drivers/rpmsg/rpmsg_core.c b/drivers/rpmsg/rpmsg_core.c
>>> index 8122807db380..daca2e24fc71 100644
>>> --- a/drivers/rpmsg/rpmsg_core.c
>>> +++ b/drivers/rpmsg/rpmsg_core.c
>>> @@ -283,6 +283,27 @@ int rpmsg_trysend_offchannel(struct
>>> rpmsg_endpoint *ept, u32 src, u32 dst,
>>>   }
>>>   EXPORT_SYMBOL(rpmsg_trysend_offchannel);
>>>   +/**
>>> + * rpmsg_get_mtu() - get maximum transmission buffer size for
>>> sending message.
>>> + * @ept: the rpmsg endpoint
>>> + *
>>> + * This function returns maximum buffer size available for a single
>>> message.
>>> + *
>>> + * Return: the maximum transmission size on success and an
>>> appropriate error
>>> + * value on failure.
>>> + */
>>> +
>>> +ssize_t rpmsg_get_mtu(struct rpmsg_endpoint *ept)
>>> +{
>>> +    if (WARN_ON(!ept))
>>> +        return -EINVAL;
>>> +    if (!ept->ops->get_buf_mtu)
>>
>> How about calling the ops just get_mtu or rename the function to follow
>> the ops name, like all the others.
>>
>>> +        return -ENXIO;
>>
>> Perhaps ENOTSUPP or EOPNOTSUPP.
>>
>>> +
>>> +    return ept->ops->get_buf_mtu(ept);
>>> +}
>>> +EXPORT_SYMBOL(rpmsg_get_mtu);
>>> +
>>>   /*
>>>    * match an rpmsg channel with a channel info struct.
>>>    * this is used to make sure we're not creating rpmsg devices for
>>> channels
>>> diff --git a/drivers/rpmsg/rpmsg_internal.h
>>> b/drivers/rpmsg/rpmsg_internal.h
>>> index 0d791c30b7ea..645c402569ac 100644
>>> --- a/drivers/rpmsg/rpmsg_internal.h
>>> +++ b/drivers/rpmsg/rpmsg_internal.h
>>> @@ -46,6 +46,7 @@ struct rpmsg_device_ops {
>>>    * @trysend:        see @rpmsg_trysend(), required
>>>    * @trysendto:        see @rpmsg_trysendto(), optional
>>>    * @trysend_offchannel:    see @rpmsg_trysend_offchannel(), optional
>>> + * @get_buf_payload_size: see @rpmsg_get_buf_payload_size(), optional
>>
>> Missed updating the kerneldoc to the new name.
>>
>>>    *
>>>    * Indirection table for the operations that a rpmsg backend should
>>> implement.
>>>    * In addition to @destroy_ept, the backend must at least implement
>>> @send and
>>> @@ -65,6 +66,7 @@ struct rpmsg_endpoint_ops {
>>>                    void *data, int len);
>>>       __poll_t (*poll)(struct rpmsg_endpoint *ept, struct file *filp,
>>>                    poll_table *wait);
>>> +    ssize_t (*get_buf_mtu)(struct rpmsg_endpoint *ept);
>>>   };
>>>     int rpmsg_register_device(struct rpmsg_device *rpdev);
>>> diff --git a/drivers/rpmsg/virtio_rpmsg_bus.c
>>> b/drivers/rpmsg/virtio_rpmsg_bus.c
>>> index e757f0038a1c..f80b1ad23e7e 100644
>>> --- a/drivers/rpmsg/virtio_rpmsg_bus.c
>>> +++ b/drivers/rpmsg/virtio_rpmsg_bus.c
>>> @@ -178,6 +178,7 @@ static int virtio_rpmsg_trysendto(struct
>>> rpmsg_endpoint *ept, void *data,
>>>                     int len, u32 dst);
>>>   static int virtio_rpmsg_trysend_offchannel(struct rpmsg_endpoint
>>> *ept, u32 src,
>>>                          u32 dst, void *data, int len);
>>> +static ssize_t virtio_get_buf_mtu(struct rpmsg_endpoint *ept);
>>
>> Minor nit, virtio_rpmsg_ prefix similar to all the other ops.
>>
>> regards
>> Suman
>>
>>>     static const struct rpmsg_endpoint_ops virtio_endpoint_ops = {
>>>       .destroy_ept = virtio_rpmsg_destroy_ept,
>>> @@ -187,6 +188,7 @@ static const struct rpmsg_endpoint_ops
>>> virtio_endpoint_ops = {
>>>       .trysend = virtio_rpmsg_trysend,
>>>       .trysendto = virtio_rpmsg_trysendto,
>>>       .trysend_offchannel = virtio_rpmsg_trysend_offchannel,
>>> +    .get_buf_mtu = virtio_get_buf_mtu,
>>>   };
>>>     /**
>>> @@ -702,6 +704,14 @@ static int
>>> virtio_rpmsg_trysend_offchannel(struct rpmsg_endpoint *ept, u32 src,
>>>       return rpmsg_send_offchannel_raw(rpdev, src, dst, data, len,
>>> false);
>>>   }
>>>   +static ssize_t virtio_get_buf_mtu(struct rpmsg_endpoint *ept)
>>> +{
>>> +    struct rpmsg_device *rpdev = ept->rpdev;
>>> +    struct virtio_rpmsg_channel *vch = to_virtio_rpmsg_channel(rpdev);
>>> +
>>> +    return vch->vrp->buf_size - sizeof(struct rpmsg_hdr);
>>> +}
>>> +
>>>   static int rpmsg_recv_single(struct virtproc_info *vrp, struct
>>> device *dev,
>>>                    struct rpmsg_hdr *msg, unsigned int len)
>>>   {
>>> diff --git a/include/linux/rpmsg.h b/include/linux/rpmsg.h
>>> index 9fe156d1c018..9d638bf2bdce 100644
>>> --- a/include/linux/rpmsg.h
>>> +++ b/include/linux/rpmsg.h
>>> @@ -135,6 +135,8 @@ int rpmsg_trysend_offchannel(struct
>>> rpmsg_endpoint *ept, u32 src, u32 dst,
>>>   __poll_t rpmsg_poll(struct rpmsg_endpoint *ept, struct file *filp,
>>>               poll_table *wait);
>>>   +ssize_t rpmsg_get_mtu(struct rpmsg_endpoint *ept);
>>> +
>>>   #else
>>>     static inline int register_rpmsg_device(struct rpmsg_device *dev)
>>> @@ -242,6 +244,14 @@ static inline __poll_t rpmsg_poll(struct
>>> rpmsg_endpoint *ept,
>>>       return 0;
>>>   }
>>>   +static ssize_t rpmsg_get_mtu(struct rpmsg_endpoint *ept)
>>> +{
>>> +    /* This shouldn't be possible */
>>> +    WARN_ON(1);
>>> +
>>> +    return -ENXIO;
>>> +}
>>> +
>>>   #endif /* IS_ENABLED(CONFIG_RPMSG) */
>>>     /* use a macro to avoid include chaining to get THIS_MODULE */
>>>
>>


  reply	other threads:[~2019-09-03 16:06 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-28 15:19 [PATCH v5 0/2] TTY: add rpmsg tty driver Arnaud Pouliquen
2019-08-28 15:19 ` Arnaud Pouliquen
2019-08-28 15:19 ` [PATCH v5 1/2] rpmsg: core: add API to get message length Arnaud Pouliquen
2019-08-28 15:19   ` Arnaud Pouliquen
2019-08-28 22:34   ` Suman Anna
2019-08-28 22:34     ` Suman Anna
2019-09-03  9:49     ` Arnaud Pouliquen
2019-09-03  9:49       ` Arnaud Pouliquen
2019-09-03 16:06       ` Suman Anna [this message]
2019-09-03 16:06         ` Suman Anna
2019-09-04  8:14         ` Arnaud Pouliquen
2019-09-04  8:14           ` Arnaud Pouliquen
2019-08-28 15:19 ` [PATCH v5 2/2] tty: add rpmsg driver Arnaud Pouliquen
2019-08-28 15:19   ` Arnaud Pouliquen
2019-08-29 19:39   ` kbuild test robot
2019-08-29 19:39     ` kbuild test robot
2019-08-29 21:21   ` kbuild test robot
2019-08-29 21:21     ` kbuild test robot

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=2a81a04d-e4f9-b9c8-57ec-47f8e140235a@ti.com \
    --to=s-anna@ti.com \
    --cc=arnaud.pouliquen@st.com \
    --cc=bjorn.andersson@linaro.org \
    --cc=fabien.dessenne@st.com \
    --cc=gnomes@lxorguk.ukuu.org.uk \
    --cc=gregkh@linuxfoundation.org \
    --cc=jslaby@suse.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-remoteproc@vger.kernel.org \
    --cc=linux-stm32@st-md-mailman.stormreply.com \
    --cc=ohad@wizery.com \
    --cc=xiaoxiang781216@gmail.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.