public inbox for linux-remoteproc@vger.kernel.org
 help / color / mirror / Atom feed
From: Arnaud POULIQUEN <arnaud.pouliquen@st.com>
To: Mathieu Poirier <mathieu.poirier@linaro.org>
Cc: "ohad@wizery.com" <ohad@wizery.com>,
	"bjorn.andersson@linaro.org" <bjorn.andersson@linaro.org>,
	"guennadi.liakhovetski@linux.intel.com" 
	<guennadi.liakhovetski@linux.intel.com>,
	"linux-remoteproc@vger.kernel.org"
	<linux-remoteproc@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v2 2/9] rpmsg: Introduce __rpmsg{16|32|64} types
Date: Fri, 16 Oct 2020 11:41:43 +0200	[thread overview]
Message-ID: <b5635aa9-c3e2-78ba-13ae-bfee1e429537@st.com> (raw)
In-Reply-To: <20201015193243.GD1450102@xps15>



On 10/15/20 9:32 PM, Mathieu Poirier wrote:
> Good day,
> 
> On Wed, Oct 14, 2020 at 06:31:49PM +0200, Arnaud POULIQUEN wrote:
>> Hi Mathieu,
>>
>> On 10/14/20 1:25 AM, Mathieu Poirier wrote:
>>> Introduce __rpmsg{16|32|64} types along with byte order conversion
>>> functions based on an rpmsg_device operation as a foundation to
>>> make RPMSG modular and transport agnostic.
>>>
>>> Suggested-by: Guennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com>
>>> Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
>>> ---
>>>  include/linux/rpmsg.h            | 51 ++++++++++++++++++++++++
>>>  include/linux/rpmsg_byteorder.h  | 67 ++++++++++++++++++++++++++++++++
>>>  include/uapi/linux/rpmsg_types.h | 11 ++++++
>>>  3 files changed, 129 insertions(+)
>>>  create mode 100644 include/linux/rpmsg_byteorder.h
>>>  create mode 100644 include/uapi/linux/rpmsg_types.h
>>>
>>> diff --git a/include/linux/rpmsg.h b/include/linux/rpmsg.h
>>> index 9fe1c54ae995..165e4c6d4cd3 100644
>>> --- a/include/linux/rpmsg.h
>>> +++ b/include/linux/rpmsg.h
>>> @@ -17,6 +17,7 @@
>>>  #include <linux/kref.h>
>>>  #include <linux/mutex.h>
>>>  #include <linux/poll.h>
>>> +#include <linux/rpmsg_byteorder.h>
>>>  
>>>  #define RPMSG_ADDR_ANY		0xFFFFFFFF
>>>  
>>> @@ -40,6 +41,7 @@ typedef int (*rpmsg_rx_cb_t)(struct rpmsg_device *, void *, int, void *, u32);
>>>  
>>>  /**
>>>   * struct rpmsg_device_ops - indirection table for the rpmsg_device operations
>>> + * @is_little_endian:	returns true if using little endian byte ordering
>>>   * @create_ept:		create backend-specific endpoint, required
>>>   * @announce_create:	announce presence of new channel, optional
>>>   * @announce_destroy:	announce destruction of channel, optional
>>> @@ -49,6 +51,7 @@ typedef int (*rpmsg_rx_cb_t)(struct rpmsg_device *, void *, int, void *, u32);
>>>   * advertise new channels implicitly by creating the endpoints.
>>>   */
>>>  struct rpmsg_device_ops {
>>> +	bool (*is_little_endian)(struct rpmsg_device *rpdev);
>>>  	struct rpmsg_endpoint *(*create_ept)(struct rpmsg_device *rpdev,
>>>  					    rpmsg_rx_cb_t cb, void *priv,
>>>  					    struct rpmsg_channel_info chinfo);
>>> @@ -129,6 +132,54 @@ struct rpmsg_driver {
>>>  	int (*callback)(struct rpmsg_device *, void *, int, void *, u32);
>>>  };
>>>  
>>> +static inline u16 rpmsg16_to_cpu(struct rpmsg_device *rpdev, __rpmsg16 val)
>>> +{
>>> +	if (!rpdev || !rpdev->ops || !rpdev->ops->is_little_endian)
>>> +		return __rpmsg16_to_cpu(rpmsg_is_little_endian(), val);
>>> +	else
>>> +		return __rpmsg16_to_cpu(rpdev->ops->is_little_endian(rpdev), val);
>>> +}
>>> +
>>> +static inline __rpmsg16 cpu_to_rpmsg16(struct rpmsg_device *rpdev, u16 val)
>>> +{
>>> +	if (!rpdev || !rpdev->ops || !rpdev->ops->is_little_endian)
>>> +		return __cpu_to_rpmsg16(rpmsg_is_little_endian(), val);
>>> +	else
>>> +		return __cpu_to_rpmsg16(rpdev->ops->is_little_endian(rpdev), val);
>>> +}
>>> +
>>> +static inline u32 rpmsg32_to_cpu(struct rpmsg_device *rpdev, __rpmsg32 val)
>>> +{
>>> +	if (!rpdev || !rpdev->ops || !rpdev->ops->is_little_endian)
>>> +		return __rpmsg32_to_cpu(rpmsg_is_little_endian(), val);
>>> +	else
>>> +		return __rpmsg32_to_cpu(rpdev->ops->is_little_endian(rpdev), val);
>>> +}
>>> +
>>> +static inline __rpmsg32 cpu_to_rpmsg32(struct rpmsg_device *rpdev, u32 val)
>>> +{
>>> +	if (!rpdev || !rpdev->ops || !rpdev->ops->is_little_endian)
>>> +		return __cpu_to_rpmsg32(rpmsg_is_little_endian(), val);
>>> +	else
>>> +		return __cpu_to_rpmsg32(rpdev->ops->is_little_endian(rpdev), val);
>>> +}
>>> +
>>> +static inline u64 rpmsg64_to_cpu(struct rpmsg_device *rpdev, __rpmsg64 val)
>>> +{
>>> +	if (!rpdev || !rpdev->ops || !rpdev->ops->is_little_endian)
>>> +		return __rpmsg64_to_cpu(rpmsg_is_little_endian(), val);
>>> +	else
>>> +		return __rpmsg64_to_cpu(rpdev->ops->is_little_endian(rpdev), val);
>>> +}
>>> +
>>> +static inline __rpmsg64 cpu_to_rpmsg64(struct rpmsg_device *rpdev, u64 val)
>>> +{
>>> +	if (!rpdev || !rpdev->ops || !rpdev->ops->is_little_endian)
>>> +		return __cpu_to_rpmsg64(rpmsg_is_little_endian(), val);
>>> +	else
>>> +		return __cpu_to_rpmsg64(rpdev->ops->is_little_endian(rpdev), val);
>>> +}
>>> +
>>>  #if IS_ENABLED(CONFIG_RPMSG)
>>>  
>>>  int register_rpmsg_device(struct rpmsg_device *dev);
>>> diff --git a/include/linux/rpmsg_byteorder.h b/include/linux/rpmsg_byteorder.h
>>> new file mode 100644
>>> index 000000000000..c0f565dbad6d
>>> --- /dev/null
>>> +++ b/include/linux/rpmsg_byteorder.h
>>> @@ -0,0 +1,67 @@
>>> +/* SPDX-License-Identifier: GPL-2.0 */
>>> +/*
>>> + * Follows implementation found in linux/virtio_byteorder.h
>>> + */
>>> +#ifndef _LINUX_RPMSG_BYTEORDER_H
>>> +#define _LINUX_RPMSG_BYTEORDER_H
>>> +#include <linux/types.h>
>>> +#include <uapi/linux/rpmsg_types.h>
>>> +
>>> +static inline bool rpmsg_is_little_endian(void)
>>> +{
>>> +#ifdef __LITTLE_ENDIAN
>>> +	return true;
>>> +#else
>>> +	return false;
>>> +#endif
>>> +}
>>
>> A suggestion:
>>
>> static inline bool rpmsg_is_little_endian(void)
>> #if defined(__BYTE_ORDER)
>> #  if __BYTE_ORDER == __BIG_ENDIAN
>> 	return true;
>> #  elif __BYTE_ORDER == __LITTLE_ENDIAN
>> 	return false;
>> #  else
>> #    warning "unknown endianess, set to little by default"
>> 	return true;
>> #  endif
>> #endif
>> }
> 
> I found that __BYTE_ORDER is not defined stm32mp157 - have you used it before? 

Good point! it seems not defined for some architectures...something strange is that
it is used in some generic code (e.g.[1]) but it works considering little by default... 

I saw this implementation in Linux kernel code, for instance [2].
that's said,  __LITTLE_ENDIAN or __BIG_ENDIAN seems always defined regarding [3].
So just forget this suggestion...

[1]https://elixir.bootlin.com/linux/latest/source/include/math-emu/double.h#L59
[2]https://elixir.bootlin.com/linux/latest/source/tools/lib/bpf/btf.c#L506
[3]https://elixir.bootlin.com/linux/latest/source/include/linux/kconfig.h#L12

> 
>>
>> Otherwise
>>
>> Reviewed-by:  Arnaud Pouliquen <arnaud.pouliquen@st.com>
>>
>> Thanks,
>> Arnaud
>>
>>> +
>>> +static inline u16 __rpmsg16_to_cpu(bool little_endian, __rpmsg16 val)
>>> +{
>>> +	if (little_endian)
>>> +		return le16_to_cpu((__force __le16)val);
>>> +	else
>>> +		return be16_to_cpu((__force __be16)val);
>>> +}
>>> +
>>> +static inline __rpmsg16 __cpu_to_rpmsg16(bool little_endian, u16 val)
>>> +{
>>> +	if (little_endian)
>>> +		return (__force __rpmsg16)cpu_to_le16(val);
>>> +	else
>>> +		return (__force __rpmsg16)cpu_to_be16(val);
>>> +}
>>> +
>>> +static inline u32 __rpmsg32_to_cpu(bool little_endian, __rpmsg32 val)
>>> +{
>>> +	if (little_endian)
>>> +		return le32_to_cpu((__force __le32)val);
>>> +	else
>>> +		return be32_to_cpu((__force __be32)val);
>>> +}
>>> +
>>> +static inline __rpmsg32 __cpu_to_rpmsg32(bool little_endian, u32 val)
>>> +{
>>> +	if (little_endian)
>>> +		return (__force __rpmsg32)cpu_to_le32(val);
>>> +	else
>>> +		return (__force __rpmsg32)cpu_to_be32(val);
>>> +}
>>> +
>>> +static inline u64 __rpmsg64_to_cpu(bool little_endian, __rpmsg64 val)
>>> +{
>>> +	if (little_endian)
>>> +		return le64_to_cpu((__force __le64)val);
>>> +	else
>>> +		return be64_to_cpu((__force __be64)val);
>>> +}
>>> +
>>> +static inline __rpmsg64 __cpu_to_rpmsg64(bool little_endian, u64 val)
>>> +{
>>> +	if (little_endian)
>>> +		return (__force __rpmsg64)cpu_to_le64(val);
>>> +	else
>>> +		return (__force __rpmsg64)cpu_to_be64(val);
>>> +}
>>> +
>>> +#endif /* _LINUX_RPMSG_BYTEORDER_H */
>>> diff --git a/include/uapi/linux/rpmsg_types.h b/include/uapi/linux/rpmsg_types.h
>>> new file mode 100644
>>> index 000000000000..36e3b9404391
>>> --- /dev/null
>>> +++ b/include/uapi/linux/rpmsg_types.h
>>> @@ -0,0 +1,11 @@
>>> +/* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */
>>> +#ifndef _UAPI_LINUX_RPMSG_TYPES_H
>>> +#define _UAPI_LINUX_RPMSG_TYPES_H
>>> +
>>> +#include <linux/types.h>
>>> +
>>> +typedef __u16 __bitwise __rpmsg16;
>>> +typedef __u32 __bitwise __rpmsg32;
>>> +typedef __u64 __bitwise __rpmsg64;
>>> +
>>> +#endif /* _UAPI_LINUX_RPMSG_TYPES_H */
>>>

  reply	other threads:[~2020-10-16  9:41 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-13 23:25 [PATCH v2 0/9] rpmsg: Make RPMSG name service modular Mathieu Poirier
2020-10-13 23:25 ` [PATCH v2 1/9] rpmsg: Move rpmsg_endpoint_ops to rpmsg.h Mathieu Poirier
2020-10-15  8:48   ` Arnaud POULIQUEN
2020-10-13 23:25 ` [PATCH v2 2/9] rpmsg: Introduce __rpmsg{16|32|64} types Mathieu Poirier
2020-10-14 16:31   ` Arnaud POULIQUEN
2020-10-15 19:32     ` Mathieu Poirier
2020-10-16  9:41       ` Arnaud POULIQUEN [this message]
2020-10-13 23:25 ` [PATCH v2 3/9] rpmsg: virtio: Move from virtio to rpmsg byte conversion Mathieu Poirier
2020-10-14 17:04   ` Arnaud POULIQUEN
2020-10-15 19:46     ` Mathieu Poirier
2020-10-13 23:25 ` [PATCH v2 4/9] rpmsg: Move rpmsg_hr and rpmsg_ns_msg to header file Mathieu Poirier
2020-10-15  8:33   ` Arnaud POULIQUEN
2020-10-15 20:19     ` Mathieu Poirier
2020-10-16  9:45       ` Arnaud POULIQUEN
2020-10-13 23:25 ` [PATCH v2 5/9] rpmsg: virtio: Rename rpmsg_create_channel Mathieu Poirier
2020-10-13 23:25 ` [PATCH v2 6/9] rpmsg: core: Add channel creation internal API Mathieu Poirier
2020-10-13 23:25 ` [PATCH v2 7/9] rpmsg: virtio: Add rpmsg channel device ops Mathieu Poirier
2020-10-13 23:25 ` [PATCH v2 8/9] rpmsg: Make rpmsg_{register|unregister}_device() public Mathieu Poirier
2020-10-15  8:47   ` Arnaud POULIQUEN
2020-10-13 23:25 ` [PATCH v2 9/9] rpmsg: Turn name service into a stand alone driver Mathieu Poirier
2020-10-14 10:18 ` [PATCH v2 0/9] rpmsg: Make RPMSG name service modular Guennadi Liakhovetski

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=b5635aa9-c3e2-78ba-13ae-bfee1e429537@st.com \
    --to=arnaud.pouliquen@st.com \
    --cc=bjorn.andersson@linaro.org \
    --cc=guennadi.liakhovetski@linux.intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-remoteproc@vger.kernel.org \
    --cc=mathieu.poirier@linaro.org \
    --cc=ohad@wizery.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox