Re: [PATCH 08/10] rpmsg: core: Add RPMSG byte conversion operations

From: Mathieu Poirier <mathieu.poirier@linaro.org>
To: Arnaud POULIQUEN <arnaud.pouliquen@st.com>
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>,
	Loic PALLARDY <loic.pallardy@st.com>,
	"linux-remoteproc@vger.kernel.org"
	<linux-remoteproc@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 08/10] rpmsg: core: Add RPMSG byte conversion operations
Date: Tue, 22 Sep 2020 13:46:36 -0600	[thread overview]
Message-ID: <20200922194636.GC931970@xps15> (raw)
In-Reply-To: <90c14e71-4c2b-9089-93d4-685b075873a9@st.com>

On Tue, Sep 22, 2020 at 04:34:53PM +0200, Arnaud POULIQUEN wrote:
> 
> 
> On 9/22/20 2:09 AM, Mathieu Poirier wrote:
> > Add RPMSG device specific byte conversion operations as a first
> > step to separate the RPMSG name space service from the virtIO
> > transport layer.
> > 
> > Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
> > ---
> >  drivers/rpmsg/rpmsg_core.c     | 51 ++++++++++++++++++++++++++++++++++
> >  drivers/rpmsg/rpmsg_internal.h | 12 ++++++++
> >  2 files changed, 63 insertions(+)
> > 
> > diff --git a/drivers/rpmsg/rpmsg_core.c b/drivers/rpmsg/rpmsg_core.c
> > index 50a835eaf1ba..66ad5b5f1e87 100644
> > --- a/drivers/rpmsg/rpmsg_core.c
> > +++ b/drivers/rpmsg/rpmsg_core.c
> > @@ -20,6 +20,57 @@
> >  
> >  #include "rpmsg_internal.h"
> >  
> > +/**
> > + * rpmsg{16|32}_to_cpu()
> > + * cpu_to_rpmsg[16|32}() - rpmsg device specific byte conversion functions to
> > + *			   perform byte conversion between rpmsg device and the
> > + *			   transport layer it is operating on.
> > + */
> > +
> > +u16 rpmsg16_to_cpu(struct rpmsg_device *rpdev, u16 val)
> > +{
> > +	if (WARN_ON(!rpdev))
> > +		return -EINVAL;
> > +	if (!rpdev->ops || !rpdev->ops->transport16_to_cpu)
> > +		return -EPERM;
> > +
> > +	return rpdev->ops->transport16_to_cpu(rpdev, val);
> > +}
> > +EXPORT_SYMBOL(rpmsg16_to_cpu);
> > +
> > +u16 cpu_to_rpmsg16(struct rpmsg_device *rpdev, u16 val)
> > +{
> > +	if (WARN_ON(!rpdev))
> > +		return -EINVAL;
> > +	if (!rpdev->ops || !rpdev->ops->cpu_to_transport16)
> > +		return -EPERM;
> > +
> > +	return rpdev->ops->cpu_to_transport16(rpdev, val);
> > +}
> > +EXPORT_SYMBOL(cpu_to_rpmsg16);
> > +
> > +u32 rpmsg32_to_cpu(struct rpmsg_device *rpdev, u32 val)
> > +{
> > +	if (WARN_ON(!rpdev))
> > +		return -EINVAL;
> > +	if (!rpdev->ops || !rpdev->ops->transport32_to_cpu)
> > +		return -EPERM;
> > +
> > +	return rpdev->ops->transport32_to_cpu(rpdev, val);
> > +}
> > +EXPORT_SYMBOL(rpmsg32_to_cpu);
> > +
> > +u32 cpu_to_rpmsg32(struct rpmsg_device *rpdev, u32 val)
> > +{
> > +	if (WARN_ON(!rpdev))
> > +		return -EINVAL;
> > +	if (!rpdev->ops || !rpdev->ops->cpu_to_transport32)
> > +		return -EPERM;
> 
> Alternative could be to choice the processor endianness ( it was the case
> before the virtio patch to set the endianness

That's a good idea.

> 
> > +
> > +	return rpdev->ops->cpu_to_transport32(rpdev, val);
> > +}
> > +EXPORT_SYMBOL(cpu_to_rpmsg32);
> > +
> >  /**
> >   * rpmsg_create_channel() - create a new rpmsg channel
> >   * using its name and address info.
> > diff --git a/drivers/rpmsg/rpmsg_internal.h b/drivers/rpmsg/rpmsg_internal.h
> > index 2e65386f191e..2f0ad1a52698 100644
> > --- a/drivers/rpmsg/rpmsg_internal.h
> > +++ b/drivers/rpmsg/rpmsg_internal.h
> > @@ -81,6 +81,8 @@ struct virtio_rpmsg_channel {
> >  
> >  /**
> >   * struct rpmsg_device_ops - indirection table for the rpmsg_device operations
> > + * @transport{16|32}_to_cpu: byte conversion from rpmsg device to transport layer
> > + * @cpu_to_transport{16|32}: byte conversion from transport layer to rpmsg device
> >   * @create_channel:	create backend-specific channel, optional
> >   * @release_channel:	release backend-specific channel, optional
> >   * @create_ept:		create backend-specific endpoint, required
> > @@ -92,6 +94,10 @@ struct virtio_rpmsg_channel {
> >   * advertise new channels implicitly by creating the endpoints.
> >   */
> >  struct rpmsg_device_ops {
> > +	u16 (*transport16_to_cpu)(struct rpmsg_device *rpdev, u16 val);
> > +	u16 (*cpu_to_transport16)(struct rpmsg_device *rpdev, u16 val);
> > +	u32 (*transport32_to_cpu)(struct rpmsg_device *rpdev, u32 val);
> > +	u32 (*cpu_to_transport32)(struct rpmsg_device *rpdev, u32 val);
> 
> This trigg me a suggestion. Perhaps it would be simpler to have only on ops
> to get the endianness.
> 

Another good idea, I'll look into it.

Thanks for the comments,
Mathieu

> Regards
> Arnaud
> 
> >  	struct rpmsg_device *(*create_channel)(struct rpmsg_device *rpdev,
> >  					     struct rpmsg_channel_info *chinfo);
> >  	int (*release_channel)(struct rpmsg_device *rpdev,
> > @@ -148,6 +154,12 @@ rpmsg_create_channel(struct rpmsg_device *rpdev,
> >  		     struct rpmsg_channel_info *chinfo);
> >  int rpmsg_release_channel(struct rpmsg_device *rpdev,
> >  			  struct rpmsg_channel_info *chinfo);
> > +
> > +u16 rpmsg16_to_cpu(struct rpmsg_device *rpdev, u16 val);
> > +u16 cpu_to_rpmsg16(struct rpmsg_device *rpdev, u16 val);
> > +u32 rpmsg32_to_cpu(struct rpmsg_device *rpdev, u32 val);
> > +u32 cpu_to_rpmsg32(struct rpmsg_device *rpdev, u32 val);
> > +
> >  /**
> >   * rpmsg_chrdev_register_device() - register chrdev device based on rpdev
> >   * @rpdev:	prepared rpdev to be used for creating endpoints
> > 