[PATCH V7 0/3] rpmsg signaling/flowcontrol patches

[PATCH V7 0/3] rpmsg signaling/flowcontrol patches

[Sarannya S]

For rpmsg_set_flow_control, change "EXPORT_SYMBOL" to "EXPORT_SYMBOL_GPL".
Update destination parameter in rpmsg_set_flow_control().
 

Chris Lew (2):
  rpmsg: glink: Add support to handle signals command
  rpmsg: char: Add RPMSG GET/SET FLOWCONTROL IOCTL support

Deepak Kumar Singh (1):
  rpmsg: core: Add signal API support

 drivers/rpmsg/qcom_glink_native.c | 64 +++++++++++++++++++++++++++++++++++++++
 drivers/rpmsg/rpmsg_char.c        | 49 ++++++++++++++++++++++++++----
 drivers/rpmsg/rpmsg_core.c        | 21 +++++++++++++
 drivers/rpmsg/rpmsg_internal.h    |  2 ++
 include/linux/rpmsg.h             | 15 +++++++++
 include/uapi/linux/rpmsg.h        | 11 ++++++-
 6 files changed, 155 insertions(+), 7 deletions(-)

-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH V7 1/3] rpmsg: core: Add signal API support

[Sarannya S]

From: Deepak Kumar Singh <quic_deesin@quicinc.com>

Some transports like Glink support the state notifications between
clients using flow control signals similar to serial protocol signals.
Local glink client drivers can send and receive flow control status
to glink clients running on remote processors.

Add APIs to support sending and receiving of flow control status by
rpmsg clients.

Signed-off-by: Deepak Kumar Singh <quic_deesin@quicinc.com>
Signed-off-by: Sarannya S <quic_sarannya@quicinc.com>
---
 drivers/rpmsg/rpmsg_core.c     | 21 +++++++++++++++++++++
 drivers/rpmsg/rpmsg_internal.h |  2 ++
 include/linux/rpmsg.h          | 15 +++++++++++++++
 3 files changed, 38 insertions(+)

diff --git a/drivers/rpmsg/rpmsg_core.c b/drivers/rpmsg/rpmsg_core.c
index a2207c0..e8bbe05 100644
--- a/drivers/rpmsg/rpmsg_core.c
+++ b/drivers/rpmsg/rpmsg_core.c
@@ -331,6 +331,25 @@ int rpmsg_trysend_offchannel(struct rpmsg_endpoint *ept, u32 src, u32 dst,
 EXPORT_SYMBOL(rpmsg_trysend_offchannel);
 
 /**
+ * rpmsg_set_flow_control() - sets/clears serial flow control signals
+ * @ept:	the rpmsg endpoint
+ * @enable:	pause/resume incoming data flow	
+ * @dst:	destination address of the endpoint
+ *
+ * Return: 0 on success and an appropriate error value on failure.
+ */
+int rpmsg_set_flow_control(struct rpmsg_endpoint *ept, bool enable, u32 dst)
+{
+	if (WARN_ON(!ept))
+		return -EINVAL;
+	if (!ept->ops->set_flow_control)
+		return -ENXIO;
+
+	return ept->ops->set_flow_control(ept, enable, dst);
+}
+EXPORT_SYMBOL_GPL(rpmsg_set_flow_control);
+
+/**
  * rpmsg_get_mtu() - get maximum transmission buffer size for sending message.
  * @ept: the rpmsg endpoint
  *
@@ -539,6 +558,8 @@ static int rpmsg_dev_probe(struct device *dev)
 
 		rpdev->ept = ept;
 		rpdev->src = ept->addr;
+
+		ept->flow_cb = rpdrv->flowcontrol;
 	}
 
 	err = rpdrv->probe(rpdev);
diff --git a/drivers/rpmsg/rpmsg_internal.h b/drivers/rpmsg/rpmsg_internal.h
index 39b646d..b6efd3e 100644
--- a/drivers/rpmsg/rpmsg_internal.h
+++ b/drivers/rpmsg/rpmsg_internal.h
@@ -55,6 +55,7 @@ struct rpmsg_device_ops {
  * @trysendto:		see @rpmsg_trysendto(), optional
  * @trysend_offchannel:	see @rpmsg_trysend_offchannel(), optional
  * @poll:		see @rpmsg_poll(), optional
+ * @set_flow_control:	see @rpmsg_set_flow_control(), optional
  * @get_mtu:		see @rpmsg_get_mtu(), optional
  *
  * Indirection table for the operations that a rpmsg backend should implement.
@@ -75,6 +76,7 @@ struct rpmsg_endpoint_ops {
 			     void *data, int len);
 	__poll_t (*poll)(struct rpmsg_endpoint *ept, struct file *filp,
 			     poll_table *wait);
+	int (*set_flow_control)(struct rpmsg_endpoint *ept, bool enable, u32 dst);
 	ssize_t (*get_mtu)(struct rpmsg_endpoint *ept);
 };
 
diff --git a/include/linux/rpmsg.h b/include/linux/rpmsg.h
index 523c98b..a0e9d38 100644
--- a/include/linux/rpmsg.h
+++ b/include/linux/rpmsg.h
@@ -64,12 +64,14 @@ struct rpmsg_device {
 };
 
 typedef int (*rpmsg_rx_cb_t)(struct rpmsg_device *, void *, int, void *, u32);
+typedef int (*rpmsg_flowcontrol_cb_t)(struct rpmsg_device *, void *, bool);
 
 /**
  * struct rpmsg_endpoint - binds a local rpmsg address to its user
  * @rpdev: rpmsg channel device
  * @refcount: when this drops to zero, the ept is deallocated
  * @cb: rx callback handler
+ * @flow_cb: remote flow control callback handler
  * @cb_lock: must be taken before accessing/changing @cb
  * @addr: local rpmsg address
  * @priv: private data for the driver's use
@@ -92,6 +94,7 @@ struct rpmsg_endpoint {
 	struct rpmsg_device *rpdev;
 	struct kref refcount;
 	rpmsg_rx_cb_t cb;
+	rpmsg_flowcontrol_cb_t flow_cb;
 	struct mutex cb_lock;
 	u32 addr;
 	void *priv;
@@ -106,6 +109,7 @@ struct rpmsg_endpoint {
  * @probe: invoked when a matching rpmsg channel (i.e. device) is found
  * @remove: invoked when the rpmsg channel is removed
  * @callback: invoked when an inbound message is received on the channel
+ * @flowcontrol: invoked when remote side flow control status is received
  */
 struct rpmsg_driver {
 	struct device_driver drv;
@@ -113,6 +117,7 @@ struct rpmsg_driver {
 	int (*probe)(struct rpmsg_device *dev);
 	void (*remove)(struct rpmsg_device *dev);
 	int (*callback)(struct rpmsg_device *, void *, int, void *, u32);
+	int (*flowcontrol)(struct rpmsg_device *, void *, bool);
 };
 
 static inline u16 rpmsg16_to_cpu(struct rpmsg_device *rpdev, __rpmsg16 val)
@@ -192,6 +197,8 @@ __poll_t rpmsg_poll(struct rpmsg_endpoint *ept, struct file *filp,
 
 ssize_t rpmsg_get_mtu(struct rpmsg_endpoint *ept);
 
+int rpmsg_set_flow_control(struct rpmsg_endpoint *ept, bool enable, u32 dst);
+
 #else
 
 static inline int rpmsg_register_device_override(struct rpmsg_device *rpdev,
@@ -316,6 +323,14 @@ static inline ssize_t rpmsg_get_mtu(struct rpmsg_endpoint *ept)
 	return -ENXIO;
 }
 
+static inline int rpmsg_set_flow_control(struct rpmsg_endpoint *ept, bool enable, u32 dst)
+{
+	/* 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 */
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH V7 2/3] rpmsg: glink: Add support to handle signals command

[Sarannya S]

From: Chris Lew <quic_clew@quicinc.com>

Remote peripherals send signal notifications over glink with commandID 15.

Add support to send and receive the signal command and based signals
enable or disable flow control with remote host.

Signed-off-by: Chris Lew <quic_clew@quicinc.com>
Signed-off-by: Deepak Kumar Singh <quic_deesin@quicinc.com>
Signed-off-by: Sarannya S <quic_sarannya@quicinc.com>
---
 drivers/rpmsg/qcom_glink_native.c | 64 +++++++++++++++++++++++++++++++++++++++
 1 file changed, 64 insertions(+)

diff --git a/drivers/rpmsg/qcom_glink_native.c b/drivers/rpmsg/qcom_glink_native.c
index 01d2805..ff5e926 100644
--- a/drivers/rpmsg/qcom_glink_native.c
+++ b/drivers/rpmsg/qcom_glink_native.c
@@ -16,6 +16,7 @@
 #include <linux/rpmsg.h>
 #include <linux/sizes.h>
 #include <linux/slab.h>
+#include <linux/termios.h>
 #include <linux/workqueue.h>
 #include <linux/mailbox_client.h>
 
@@ -197,9 +198,15 @@ static const struct rpmsg_endpoint_ops glink_endpoint_ops;
 #define GLINK_CMD_TX_DATA_CONT		12
 #define GLINK_CMD_READ_NOTIF		13
 #define GLINK_CMD_RX_DONE_W_REUSE	14
+#define GLINK_CMD_SIGNALS		15
 
 #define GLINK_FEATURE_INTENTLESS	BIT(1)
 
+#define NATIVE_DTR_SIG			NATIVE_DSR_SIG
+#define NATIVE_DSR_SIG			BIT(31)
+#define NATIVE_RTS_SIG			NATIVE_CTS_SIG
+#define NATIVE_CTS_SIG			BIT(30)
+
 static void qcom_glink_rx_done_work(struct work_struct *work);
 
 static struct glink_channel *qcom_glink_alloc_channel(struct qcom_glink *glink,
@@ -1014,6 +1021,58 @@ static int qcom_glink_rx_open_ack(struct qcom_glink *glink, unsigned int lcid)
 	return 0;
 }
 
+/**
+ * qcom_glink_set_flow_control() - convert a signal cmd to wire format and
+ * 				   transmit
+ * @ept:	Rpmsg endpoint for channel.
+ * @enable:	True/False - enable or disable flow control
+ * @dst:	destination address of the endpoint
+ *
+ * Return: 0 on success or standard Linux error code.
+ */
+static int qcom_glink_set_flow_control(struct rpmsg_endpoint *ept, bool enable, u32 dst)
+{
+	struct glink_channel *channel = to_glink_channel(ept);
+	struct qcom_glink *glink = channel->glink;
+	struct glink_msg msg;
+	u32 sigs = 0;
+
+	if (enable)
+		sigs |= NATIVE_DTR_SIG | NATIVE_RTS_SIG;
+
+	msg.cmd = cpu_to_le16(GLINK_CMD_SIGNALS);
+	msg.param1 = cpu_to_le16(channel->lcid);
+	msg.param2 = cpu_to_le32(sigs);
+
+	return qcom_glink_tx(glink, &msg, sizeof(msg), NULL, 0, true);
+}
+
+static int qcom_glink_handle_signals(struct qcom_glink *glink,
+				     unsigned int rcid, unsigned int sigs)
+{
+	struct glink_channel *channel;
+	unsigned long flags;
+	bool enable = false;
+
+	spin_lock_irqsave(&glink->idr_lock, flags);
+	channel = idr_find(&glink->rcids, rcid);
+	spin_unlock_irqrestore(&glink->idr_lock, flags);
+	if (!channel) {
+		dev_err(glink->dev, "signal for non-existing channel\n");
+		return -EINVAL;
+	}
+
+	if (!channel->ept.flow_cb)
+		return 0;
+
+	if (sigs & (NATIVE_DSR_SIG | NATIVE_CTS_SIG))
+		enable = true;
+
+	channel->ept.flow_cb(channel->ept.rpdev, channel->ept.priv, enable);
+
+	return 0;
+}
+
 void qcom_glink_native_rx(struct qcom_glink *glink)
 {
 	struct glink_msg msg;
@@ -1075,6 +1134,10 @@ void qcom_glink_native_rx(struct qcom_glink *glink)
 			qcom_glink_handle_intent_req_ack(glink, param1, param2);
 			qcom_glink_rx_advance(glink, ALIGN(sizeof(msg), 8));
 			break;
+		case GLINK_CMD_SIGNALS:
+			qcom_glink_handle_signals(glink, param1, param2);
+			qcom_glink_rx_advance(glink, ALIGN(sizeof(msg), 8));
+			break;
 		default:
 			dev_err(glink->dev, "unhandled rx cmd: %d\n", cmd);
 			ret = -EINVAL;
@@ -1449,6 +1512,7 @@ static const struct rpmsg_endpoint_ops glink_endpoint_ops = {
 	.sendto = qcom_glink_sendto,
 	.trysend = qcom_glink_trysend,
 	.trysendto = qcom_glink_trysendto,
+	.set_flow_control = qcom_glink_set_flow_control,
 };
 
 static void qcom_glink_rpdev_release(struct device *dev)
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH V7 3/3] rpmsg: char: Add RPMSG GET/SET FLOWCONTROL IOCTL support

[Sarannya S]

From: Chris Lew <quic_clew@quicinc.com>

Add RPMSG_GET_OUTGOING_FLOWCONTROL and RPMSG_SET_INCOMING_FLOWCONTROL
IOCTL support for rpmsg char device nodes to get/set the low level
transport signals.

Signed-off-by: Chris Lew <quic_clew@quicinc.com>
Signed-off-by: Deepak Kumar Singh <quic_deesin@quicinc.com>
Signed-off-by: Sarannya S <quic_sarannya@quicinc.com>
---
 drivers/rpmsg/rpmsg_char.c | 49 ++++++++++++++++++++++++++++++++++++++++------
 include/uapi/linux/rpmsg.h | 11 ++++++++++-
 2 files changed, 53 insertions(+), 7 deletions(-)

diff --git a/drivers/rpmsg/rpmsg_char.c b/drivers/rpmsg/rpmsg_char.c
index a271fce..d50908f 100644
--- a/drivers/rpmsg/rpmsg_char.c
+++ b/drivers/rpmsg/rpmsg_char.c
@@ -23,6 +23,7 @@
 #include <linux/rpmsg.h>
 #include <linux/skbuff.h>
 #include <linux/slab.h>
+#include <linux/termios.h>
 #include <linux/uaccess.h>
 #include <uapi/linux/rpmsg.h>
 
@@ -68,6 +69,8 @@ struct rpmsg_eptdev {
 	struct sk_buff_head queue;
 	wait_queue_head_t readq;
 
+	bool remote_flow;
+	bool remote_flow_updated;
 };
 
 int rpmsg_chrdev_eptdev_destroy(struct device *dev, void *data)
@@ -116,6 +119,18 @@ static int rpmsg_ept_cb(struct rpmsg_device *rpdev, void *buf, int len,
 	return 0;
 }
 
+static int rpmsg_ept_flow_cb(struct rpmsg_device *rpdev, void *priv, bool enable)
+{
+	struct rpmsg_eptdev *eptdev = priv;
+
+	eptdev->remote_flow = enable;
+	eptdev->remote_flow_updated = true;
+
+	wake_up_interruptible(&eptdev->readq);
+
+	return 0;
+}
+
 static int rpmsg_eptdev_open(struct inode *inode, struct file *filp)
 {
 	struct rpmsg_eptdev *eptdev = cdev_to_eptdev(inode->i_cdev);
@@ -152,6 +167,7 @@ static int rpmsg_eptdev_open(struct inode *inode, struct file *filp)
 		return -EINVAL;
 	}
 
+	ept->flow_cb = rpmsg_ept_flow_cb;
 	eptdev->ept = ept;
 	filp->private_data = eptdev;
 	mutex_unlock(&eptdev->ept_lock);
@@ -172,6 +188,7 @@ static int rpmsg_eptdev_release(struct inode *inode, struct file *filp)
 		eptdev->ept = NULL;
 	}
 	mutex_unlock(&eptdev->ept_lock);
+	eptdev->remote_flow_updated = false;
 
 	/* Discard all SKBs */
 	skb_queue_purge(&eptdev->queue);
@@ -285,6 +302,9 @@ static __poll_t rpmsg_eptdev_poll(struct file *filp, poll_table *wait)
 	if (!skb_queue_empty(&eptdev->queue))
 		mask |= EPOLLIN | EPOLLRDNORM;
 
+	if (eptdev->remote_flow_updated)
+		mask |= EPOLLPRI;
+
 	mutex_lock(&eptdev->ept_lock);
 	mask |= rpmsg_poll(eptdev->ept, filp, wait);
 	mutex_unlock(&eptdev->ept_lock);
@@ -297,14 +317,31 @@ static long rpmsg_eptdev_ioctl(struct file *fp, unsigned int cmd,
 {
 	struct rpmsg_eptdev *eptdev = fp->private_data;
 
-	if (cmd != RPMSG_DESTROY_EPT_IOCTL)
-		return -EINVAL;
+	bool set;
+	int ret;
 
-	/* Don't allow to destroy a default endpoint. */
-	if (eptdev->default_ept)
-		return -EINVAL;
+	switch (cmd) {
+	case RPMSG_GET_OUTGOING_FLOWCONTROL:
+		eptdev->remote_flow_updated = false;
+		ret = put_user(eptdev->remote_flow, (int __user *)arg);
+		break;
+	case RPMSG_SET_INCOMING_FLOWCONTROL:
+		set = !!arg;
+		ret = rpmsg_set_flow_control(eptdev->ept, set, eptdev->chinfo.dst);
+		break;
+	case RPMSG_DESTROY_EPT_IOCTL:
+		/* Don't allow to destroy a default endpoint. */
+		if (eptdev->default_ept) {
+			ret = -EINVAL;
+			break;
+		}
+		ret = rpmsg_chrdev_eptdev_destroy(&eptdev->dev, NULL);
+		break;
+	default:
+		ret = -EINVAL;
+	}
 
-	return rpmsg_chrdev_eptdev_destroy(&eptdev->dev, NULL);
+	return ret;
 }
 
 static const struct file_operations rpmsg_eptdev_fops = {
diff --git a/include/uapi/linux/rpmsg.h b/include/uapi/linux/rpmsg.h
index 1637e68..c955e27 100644
--- a/include/uapi/linux/rpmsg.h
+++ b/include/uapi/linux/rpmsg.h
@@ -10,7 +10,6 @@
 #include <linux/types.h>
 
 #define RPMSG_ADDR_ANY		0xFFFFFFFF
-
 /**
  * struct rpmsg_endpoint_info - endpoint info representation
  * @name: name of service
@@ -43,4 +42,14 @@ struct rpmsg_endpoint_info {
  */
 #define RPMSG_RELEASE_DEV_IOCTL	_IOW(0xb5, 0x4, struct rpmsg_endpoint_info)
 
+/**
+ * Set the flow control for the remote rpmsg char device.
+ */
+#define RPMSG_GET_OUTGOING_FLOWCONTROL _IOW(0xb5, 0x5, struct rpmsg_endpoint_info)
+
+/**
+ * Set the flow control for the local rpmsg char device.
+ */
+#define RPMSG_SET_INCOMING_FLOWCONTROL _IOW(0xb5, 0x6, struct rpmsg_endpoint_info)
+
 #endif
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH V7 3/3] rpmsg: char: Add RPMSG GET/SET FLOWCONTROL IOCTL support

[Trilok Soni]

On 4/22/2023 3:42 AM, Sarannya S wrote:
> From: Chris Lew <quic_clew@quicinc.com>
> 
> Add RPMSG_GET_OUTGOING_FLOWCONTROL and RPMSG_SET_INCOMING_FLOWCONTROL
> IOCTL support for rpmsg char device nodes to get/set the low level
> transport signals.
> 
> Signed-off-by: Chris Lew <quic_clew@quicinc.com>
> Signed-off-by: Deepak Kumar Singh <quic_deesin@quicinc.com>
> Signed-off-by: Sarannya S <quic_sarannya@quicinc.com>

[...]

>   
>   static const struct file_operations rpmsg_eptdev_fops = {
> diff --git a/include/uapi/linux/rpmsg.h b/include/uapi/linux/rpmsg.h
> index 1637e68..c955e27 100644
> --- a/include/uapi/linux/rpmsg.h
> +++ b/include/uapi/linux/rpmsg.h
> @@ -10,7 +10,6 @@
>   #include <linux/types.h>
>   
>   #define RPMSG_ADDR_ANY		0xFFFFFFFF
> -

What is need of deleting this line in this patch? I am not sure if this 
was asked in earlier reviews.

---Trilok Soni

Re: [PATCH V7 1/3] rpmsg: core: Add signal API support

[Arnaud POULIQUEN]

Hello,

On 4/22/23 12:42, Sarannya S wrote:
> From: Deepak Kumar Singh <quic_deesin@quicinc.com>
> 
> Some transports like Glink support the state notifications between
> clients using flow control signals similar to serial protocol signals.
> Local glink client drivers can send and receive flow control status
> to glink clients running on remote processors.
> 
> Add APIs to support sending and receiving of flow control status by
> rpmsg clients.
> 
> Signed-off-by: Deepak Kumar Singh <quic_deesin@quicinc.com>
> Signed-off-by: Sarannya S <quic_sarannya@quicinc.com>
> ---
>  drivers/rpmsg/rpmsg_core.c     | 21 +++++++++++++++++++++
>  drivers/rpmsg/rpmsg_internal.h |  2 ++
>  include/linux/rpmsg.h          | 15 +++++++++++++++
>  3 files changed, 38 insertions(+)
> 
> diff --git a/drivers/rpmsg/rpmsg_core.c b/drivers/rpmsg/rpmsg_core.c
> index a2207c0..e8bbe05 100644
> --- a/drivers/rpmsg/rpmsg_core.c
> +++ b/drivers/rpmsg/rpmsg_core.c
> @@ -331,6 +331,25 @@ int rpmsg_trysend_offchannel(struct rpmsg_endpoint *ept, u32 src, u32 dst,
>  EXPORT_SYMBOL(rpmsg_trysend_offchannel);
>  
>  /**
> + * rpmsg_set_flow_control() - sets/clears serial flow control signals
> + * @ept:	the rpmsg endpoint
> + * @enable:	pause/resume incoming data flow	
> + * @dst:	destination address of the endpoint
> + *
> + * Return: 0 on success and an appropriate error value on failure.
> + */
> +int rpmsg_set_flow_control(struct rpmsg_endpoint *ept, bool enable, u32 dst)
> +{
> +	if (WARN_ON(!ept))
> +		return -EINVAL;
> +	if (!ept->ops->set_flow_control)
> +		return -ENXIO;

Here we return an error if the backend does not implement the ops.
But the set_flow_control ops is optional.
Should we return 0 instead with a debug message?

> +
> +	return ept->ops->set_flow_control(ept, enable, dst);
> +}
> +EXPORT_SYMBOL_GPL(rpmsg_set_flow_control);
> +
> +/**
>   * rpmsg_get_mtu() - get maximum transmission buffer size for sending message.
>   * @ept: the rpmsg endpoint
>   *
> @@ -539,6 +558,8 @@ static int rpmsg_dev_probe(struct device *dev)
>  
>  		rpdev->ept = ept;
>  		rpdev->src = ept->addr;
> +
> +		ept->flow_cb = rpdrv->flowcontrol;
>  	}
>  
>  	err = rpdrv->probe(rpdev);
> diff --git a/drivers/rpmsg/rpmsg_internal.h b/drivers/rpmsg/rpmsg_internal.h
> index 39b646d..b6efd3e 100644
> --- a/drivers/rpmsg/rpmsg_internal.h
> +++ b/drivers/rpmsg/rpmsg_internal.h
> @@ -55,6 +55,7 @@ struct rpmsg_device_ops {
>   * @trysendto:		see @rpmsg_trysendto(), optional
>   * @trysend_offchannel:	see @rpmsg_trysend_offchannel(), optional
>   * @poll:		see @rpmsg_poll(), optional
> + * @set_flow_control:	see @rpmsg_set_flow_control(), optional
>   * @get_mtu:		see @rpmsg_get_mtu(), optional
>   *
>   * Indirection table for the operations that a rpmsg backend should implement.
> @@ -75,6 +76,7 @@ struct rpmsg_endpoint_ops {
>  			     void *data, int len);
>  	__poll_t (*poll)(struct rpmsg_endpoint *ept, struct file *filp,
>  			     poll_table *wait);
> +	int (*set_flow_control)(struct rpmsg_endpoint *ept, bool enable, u32 dst);
>  	ssize_t (*get_mtu)(struct rpmsg_endpoint *ept);
>  };
>  
> diff --git a/include/linux/rpmsg.h b/include/linux/rpmsg.h
> index 523c98b..a0e9d38 100644
> --- a/include/linux/rpmsg.h
> +++ b/include/linux/rpmsg.h
> @@ -64,12 +64,14 @@ struct rpmsg_device {
>  };
>  
>  typedef int (*rpmsg_rx_cb_t)(struct rpmsg_device *, void *, int, void *, u32);
> +typedef int (*rpmsg_flowcontrol_cb_t)(struct rpmsg_device *, void *, bool);
>  
>  /**
>   * struct rpmsg_endpoint - binds a local rpmsg address to its user
>   * @rpdev: rpmsg channel device
>   * @refcount: when this drops to zero, the ept is deallocated
>   * @cb: rx callback handler
> + * @flow_cb: remote flow control callback handler
>   * @cb_lock: must be taken before accessing/changing @cb
>   * @addr: local rpmsg address
>   * @priv: private data for the driver's use
> @@ -92,6 +94,7 @@ struct rpmsg_endpoint {
>  	struct rpmsg_device *rpdev;
>  	struct kref refcount;
>  	rpmsg_rx_cb_t cb;
> +	rpmsg_flowcontrol_cb_t flow_cb;
>  	struct mutex cb_lock;
>  	u32 addr;
>  	void *priv;
> @@ -106,6 +109,7 @@ struct rpmsg_endpoint {
>   * @probe: invoked when a matching rpmsg channel (i.e. device) is found
>   * @remove: invoked when the rpmsg channel is removed
>   * @callback: invoked when an inbound message is received on the channel
> + * @flowcontrol: invoked when remote side flow control status is received
>   */
>  struct rpmsg_driver {
>  	struct device_driver drv;
> @@ -113,6 +117,7 @@ struct rpmsg_driver {
>  	int (*probe)(struct rpmsg_device *dev);
>  	void (*remove)(struct rpmsg_device *dev);
>  	int (*callback)(struct rpmsg_device *, void *, int, void *, u32);
> +	int (*flowcontrol)(struct rpmsg_device *, void *, bool);

I wonder here if we should also add a parameter for the remote source address.
This parameter is already exist for the
int (*callback)(struct rpmsg_device *, void *, int, void *, u32)
useful in case of point to multi point communication...

Regards,
Arnaud

>  };
>  
>  static inline u16 rpmsg16_to_cpu(struct rpmsg_device *rpdev, __rpmsg16 val)
> @@ -192,6 +197,8 @@ __poll_t rpmsg_poll(struct rpmsg_endpoint *ept, struct file *filp,
>  
>  ssize_t rpmsg_get_mtu(struct rpmsg_endpoint *ept);
>  
> +int rpmsg_set_flow_control(struct rpmsg_endpoint *ept, bool enable, u32 dst);
> +
>  #else
>  
>  static inline int rpmsg_register_device_override(struct rpmsg_device *rpdev,
> @@ -316,6 +323,14 @@ static inline ssize_t rpmsg_get_mtu(struct rpmsg_endpoint *ept)
>  	return -ENXIO;
>  }
>  
> +static inline int rpmsg_set_flow_control(struct rpmsg_endpoint *ept, bool enable, u32 dst)
> +{
> +	/* 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 */

Re: [PATCH V7 3/3] rpmsg: char: Add RPMSG GET/SET FLOWCONTROL IOCTL support

[Arnaud POULIQUEN]

On 4/22/23 12:42, Sarannya S wrote:
> From: Chris Lew <quic_clew@quicinc.com>
> 
> Add RPMSG_GET_OUTGOING_FLOWCONTROL and RPMSG_SET_INCOMING_FLOWCONTROL
> IOCTL support for rpmsg char device nodes to get/set the low level
> transport signals.
> 
> Signed-off-by: Chris Lew <quic_clew@quicinc.com>
> Signed-off-by: Deepak Kumar Singh <quic_deesin@quicinc.com>
> Signed-off-by: Sarannya S <quic_sarannya@quicinc.com>
> ---
>  drivers/rpmsg/rpmsg_char.c | 49 ++++++++++++++++++++++++++++++++++++++++------
>  include/uapi/linux/rpmsg.h | 11 ++++++++++-
>  2 files changed, 53 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/rpmsg/rpmsg_char.c b/drivers/rpmsg/rpmsg_char.c
> index a271fce..d50908f 100644
> --- a/drivers/rpmsg/rpmsg_char.c
> +++ b/drivers/rpmsg/rpmsg_char.c
> @@ -23,6 +23,7 @@
>  #include <linux/rpmsg.h>
>  #include <linux/skbuff.h>
>  #include <linux/slab.h>
> +#include <linux/termios.h>

Seems useless now

>  #include <linux/uaccess.h>
>  #include <uapi/linux/rpmsg.h>
>  
> @@ -68,6 +69,8 @@ struct rpmsg_eptdev {
>  	struct sk_buff_head queue;
>  	wait_queue_head_t readq;
>  
> +	bool remote_flow;
> +	bool remote_flow_updated;
>  };
>  
>  int rpmsg_chrdev_eptdev_destroy(struct device *dev, void *data)
> @@ -116,6 +119,18 @@ static int rpmsg_ept_cb(struct rpmsg_device *rpdev, void *buf, int len,
>  	return 0;
>  }
>  
> +static int rpmsg_ept_flow_cb(struct rpmsg_device *rpdev, void *priv, bool enable)
> +{
> +	struct rpmsg_eptdev *eptdev = priv;
> +
> +	eptdev->remote_flow = enable;
> +	eptdev->remote_flow_updated = true;
> +
> +	wake_up_interruptible(&eptdev->readq);
> +
> +	return 0;
> +}
> +
>  static int rpmsg_eptdev_open(struct inode *inode, struct file *filp)
>  {
>  	struct rpmsg_eptdev *eptdev = cdev_to_eptdev(inode->i_cdev);
> @@ -152,6 +167,7 @@ static int rpmsg_eptdev_open(struct inode *inode, struct file *filp)
>  		return -EINVAL;
>  	}
>  
> +	ept->flow_cb = rpmsg_ept_flow_cb;
>  	eptdev->ept = ept;
>  	filp->private_data = eptdev;
>  	mutex_unlock(&eptdev->ept_lock);
> @@ -172,6 +188,7 @@ static int rpmsg_eptdev_release(struct inode *inode, struct file *filp)
>  		eptdev->ept = NULL;
>  	}
>  	mutex_unlock(&eptdev->ept_lock);
> +	eptdev->remote_flow_updated = false;
>  
>  	/* Discard all SKBs */
>  	skb_queue_purge(&eptdev->queue);
> @@ -285,6 +302,9 @@ static __poll_t rpmsg_eptdev_poll(struct file *filp, poll_table *wait)
>  	if (!skb_queue_empty(&eptdev->queue))
>  		mask |= EPOLLIN | EPOLLRDNORM;
>  
> +	if (eptdev->remote_flow_updated)
> +		mask |= EPOLLPRI;
> +
>  	mutex_lock(&eptdev->ept_lock);
>  	mask |= rpmsg_poll(eptdev->ept, filp, wait);
>  	mutex_unlock(&eptdev->ept_lock);
> @@ -297,14 +317,31 @@ static long rpmsg_eptdev_ioctl(struct file *fp, unsigned int cmd,
>  {
>  	struct rpmsg_eptdev *eptdev = fp->private_data;
>  
> -	if (cmd != RPMSG_DESTROY_EPT_IOCTL)
> -		return -EINVAL;
> +	bool set;
> +	int ret;
>  
> -	/* Don't allow to destroy a default endpoint. */
> -	if (eptdev->default_ept)
> -		return -EINVAL;
> +	switch (cmd) {
> +	case RPMSG_GET_OUTGOING_FLOWCONTROL:
> +		eptdev->remote_flow_updated = false;
> +		ret = put_user(eptdev->remote_flow, (int __user *)arg);

If the rpmsg_set_flow_control is not implemented on remote side or in the
backend then we should return true by default.
Else the communication should not be possible if eptdev->remote_flow is not
initialized.

Perhaps adding a "flow_ctrl" boolean in the rpmsg_device (similar to the
"announce") would give the information if the flow control is supported or not.
This "flow_ctrl" boolean would be initialized by the backend.

Regards
Arnaud


> +		break;
> +	case RPMSG_SET_INCOMING_FLOWCONTROL:
> +		set = !!arg;
> +		ret = rpmsg_set_flow_control(eptdev->ept, set, eptdev->chinfo.dst);
> +		break;
> +	case RPMSG_DESTROY_EPT_IOCTL:
> +		/* Don't allow to destroy a default endpoint. */
> +		if (eptdev->default_ept) {
> +			ret = -EINVAL;
> +			break;
> +		}
> +		ret = rpmsg_chrdev_eptdev_destroy(&eptdev->dev, NULL);
> +		break;
> +	default:
> +		ret = -EINVAL;
> +	}
>  
> -	return rpmsg_chrdev_eptdev_destroy(&eptdev->dev, NULL);
> +	return ret;
>  }
>  
>  static const struct file_operations rpmsg_eptdev_fops = {
> diff --git a/include/uapi/linux/rpmsg.h b/include/uapi/linux/rpmsg.h
> index 1637e68..c955e27 100644
> --- a/include/uapi/linux/rpmsg.h
> +++ b/include/uapi/linux/rpmsg.h
> @@ -10,7 +10,6 @@
>  #include <linux/types.h>
>  
>  #define RPMSG_ADDR_ANY		0xFFFFFFFF
> -
>  /**
>   * struct rpmsg_endpoint_info - endpoint info representation
>   * @name: name of service
> @@ -43,4 +42,14 @@ struct rpmsg_endpoint_info {
>   */
>  #define RPMSG_RELEASE_DEV_IOCTL	_IOW(0xb5, 0x4, struct rpmsg_endpoint_info)
>  
> +/**
> + * Set the flow control for the remote rpmsg char device.
> + */
> +#define RPMSG_GET_OUTGOING_FLOWCONTROL _IOW(0xb5, 0x5, struct rpmsg_endpoint_info)
> +
> +/**
> + * Set the flow control for the local rpmsg char device.
> + */
> +#define RPMSG_SET_INCOMING_FLOWCONTROL _IOW(0xb5, 0x6, struct rpmsg_endpoint_info)
> +
>  #endif

Re: [PATCH V7 1/3] rpmsg: core: Add signal API support

[Bjorn Andersson]

On Mon, Apr 24, 2023 at 02:49:29PM +0200, Arnaud POULIQUEN wrote:
> Hello,
> 
> On 4/22/23 12:42, Sarannya S wrote:
> > From: Deepak Kumar Singh <quic_deesin@quicinc.com>
> > 
> > Some transports like Glink support the state notifications between
> > clients using flow control signals similar to serial protocol signals.
> > Local glink client drivers can send and receive flow control status
> > to glink clients running on remote processors.
> > 
> > Add APIs to support sending and receiving of flow control status by
> > rpmsg clients.
> > 
> > Signed-off-by: Deepak Kumar Singh <quic_deesin@quicinc.com>
> > Signed-off-by: Sarannya S <quic_sarannya@quicinc.com>
> > ---
> >  drivers/rpmsg/rpmsg_core.c     | 21 +++++++++++++++++++++
> >  drivers/rpmsg/rpmsg_internal.h |  2 ++
> >  include/linux/rpmsg.h          | 15 +++++++++++++++
> >  3 files changed, 38 insertions(+)
> > 
> > diff --git a/drivers/rpmsg/rpmsg_core.c b/drivers/rpmsg/rpmsg_core.c
> > index a2207c0..e8bbe05 100644
> > --- a/drivers/rpmsg/rpmsg_core.c
> > +++ b/drivers/rpmsg/rpmsg_core.c
> > @@ -331,6 +331,25 @@ int rpmsg_trysend_offchannel(struct rpmsg_endpoint *ept, u32 src, u32 dst,
> >  EXPORT_SYMBOL(rpmsg_trysend_offchannel);
> >  
> >  /**
> > + * rpmsg_set_flow_control() - sets/clears serial flow control signals
> > + * @ept:	the rpmsg endpoint
> > + * @enable:	pause/resume incoming data flow	
> > + * @dst:	destination address of the endpoint
> > + *
> > + * Return: 0 on success and an appropriate error value on failure.
> > + */
> > +int rpmsg_set_flow_control(struct rpmsg_endpoint *ept, bool enable, u32 dst)
> > +{
> > +	if (WARN_ON(!ept))
> > +		return -EINVAL;
> > +	if (!ept->ops->set_flow_control)
> > +		return -ENXIO;
> 
> Here we return an error if the backend does not implement the ops.
> But the set_flow_control ops is optional.
> Should we return 0 instead with a debug message?
> 

It seems reasonable to allow the software to react to the absence of
flow control support, so a debug message wouldn't help.

But advertising that more explicitly by returning something like
EOPNOTSUPP seems better.

Regards,
Bjorn

Re: [PATCH V7 2/3] rpmsg: glink: Add support to handle signals command

[Bjorn Andersson]

On Sat, Apr 22, 2023 at 04:12:06PM +0530, Sarannya S wrote:
> From: Chris Lew <quic_clew@quicinc.com>
> 
> Remote peripherals send signal notifications over glink with commandID 15.
> 
> Add support to send and receive the signal command and based signals
> enable or disable flow control with remote host.
> 
> Signed-off-by: Chris Lew <quic_clew@quicinc.com>
> Signed-off-by: Deepak Kumar Singh <quic_deesin@quicinc.com>
> Signed-off-by: Sarannya S <quic_sarannya@quicinc.com>
> ---
>  drivers/rpmsg/qcom_glink_native.c | 64 +++++++++++++++++++++++++++++++++++++++
>  1 file changed, 64 insertions(+)
> 
> diff --git a/drivers/rpmsg/qcom_glink_native.c b/drivers/rpmsg/qcom_glink_native.c
> index 01d2805..ff5e926 100644
> --- a/drivers/rpmsg/qcom_glink_native.c
> +++ b/drivers/rpmsg/qcom_glink_native.c
> @@ -16,6 +16,7 @@
>  #include <linux/rpmsg.h>
>  #include <linux/sizes.h>
>  #include <linux/slab.h>
> +#include <linux/termios.h>
>  #include <linux/workqueue.h>
>  #include <linux/mailbox_client.h>
>  
> @@ -197,9 +198,15 @@ static const struct rpmsg_endpoint_ops glink_endpoint_ops;
>  #define GLINK_CMD_TX_DATA_CONT		12
>  #define GLINK_CMD_READ_NOTIF		13
>  #define GLINK_CMD_RX_DONE_W_REUSE	14
> +#define GLINK_CMD_SIGNALS		15
>  
>  #define GLINK_FEATURE_INTENTLESS	BIT(1)
>  
> +#define NATIVE_DTR_SIG			NATIVE_DSR_SIG
> +#define NATIVE_DSR_SIG			BIT(31)
> +#define NATIVE_RTS_SIG			NATIVE_CTS_SIG
> +#define NATIVE_CTS_SIG			BIT(30)
> +
>  static void qcom_glink_rx_done_work(struct work_struct *work);
>  
>  static struct glink_channel *qcom_glink_alloc_channel(struct qcom_glink *glink,
> @@ -1014,6 +1021,58 @@ static int qcom_glink_rx_open_ack(struct qcom_glink *glink, unsigned int lcid)
>  	return 0;
>  }
>  
> +/**
> + * qcom_glink_set_flow_control() - convert a signal cmd to wire format and
> + * 				   transmit
> + * @ept:	Rpmsg endpoint for channel.
> + * @enable:	True/False - enable or disable flow control
> + * @dst:	destination address of the endpoint
> + *
> + * Return: 0 on success or standard Linux error code.
> + */
> +static int qcom_glink_set_flow_control(struct rpmsg_endpoint *ept, bool enable, u32 dst)
> +{
> +	struct glink_channel *channel = to_glink_channel(ept);
> +	struct qcom_glink *glink = channel->glink;
> +	struct glink_msg msg;
> +	u32 sigs = 0;
> +
> +	if (enable)
> +		sigs |= NATIVE_DTR_SIG | NATIVE_RTS_SIG;
> +
> +	msg.cmd = cpu_to_le16(GLINK_CMD_SIGNALS);
> +	msg.param1 = cpu_to_le16(channel->lcid);
> +	msg.param2 = cpu_to_le32(sigs);
> +
> +	return qcom_glink_tx(glink, &msg, sizeof(msg), NULL, 0, true);
> +}
> +
> +static int qcom_glink_handle_signals(struct qcom_glink *glink,
> +				     unsigned int rcid, unsigned int sigs)
> +{
> +	struct glink_channel *channel;
> +	unsigned long flags;
> +	bool enable = false;
> +
> +	spin_lock_irqsave(&glink->idr_lock, flags);
> +	channel = idr_find(&glink->rcids, rcid);
> +	spin_unlock_irqrestore(&glink->idr_lock, flags);
> +	if (!channel) {
> +		dev_err(glink->dev, "signal for non-existing channel\n");
> +		return -EINVAL;

You don't handle this return value, so this works fine. But the other
cases of returning an error to qcom_glink_native_rx() indicates that no
further messages should be processed (e.g. because there's no sufficient
data in the FIFO).

But getting a signal on a non-existing channel is not something that's
going to be resolved until we get the next interrupt, so I think you
shouldn't propagate this error.

Which means that it would be better to make the return type void of this
function.

> +	}
> +
> +	if (!channel->ept.flow_cb)
> +		return 0;
> +
> +	if (sigs & (NATIVE_DSR_SIG | NATIVE_CTS_SIG))
> +		enable = true;

I'd find it cleaner to skip the early initialization and have a single
point of assignment of enable, like:

	enable = sigs & NATIVE_DSR_SIG || sigs & NATIVE_CTS_SIG;


And consolidate the flow_cb query/invocation to one place:
	if (channel->eptf.flow_cb)
		channel->ept.flow_cb(, enable);

Regards,
Bjorn

> +
> +	channel->ept.flow_cb(channel->ept.rpdev, channel->ept.priv, enable);
> +
> +	return 0;
> +}
> +
>  void qcom_glink_native_rx(struct qcom_glink *glink)
>  {
>  	struct glink_msg msg;
> @@ -1075,6 +1134,10 @@ void qcom_glink_native_rx(struct qcom_glink *glink)
>  			qcom_glink_handle_intent_req_ack(glink, param1, param2);
>  			qcom_glink_rx_advance(glink, ALIGN(sizeof(msg), 8));
>  			break;
> +		case GLINK_CMD_SIGNALS:
> +			qcom_glink_handle_signals(glink, param1, param2);
> +			qcom_glink_rx_advance(glink, ALIGN(sizeof(msg), 8));
> +			break;
>  		default:
>  			dev_err(glink->dev, "unhandled rx cmd: %d\n", cmd);
>  			ret = -EINVAL;
> @@ -1449,6 +1512,7 @@ static const struct rpmsg_endpoint_ops glink_endpoint_ops = {
>  	.sendto = qcom_glink_sendto,
>  	.trysend = qcom_glink_trysend,
>  	.trysendto = qcom_glink_trysendto,
> +	.set_flow_control = qcom_glink_set_flow_control,
>  };
>  
>  static void qcom_glink_rpdev_release(struct device *dev)
> -- 
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> a Linux Foundation Collaborative Project
> 

Re: [PATCH V7 3/3] rpmsg: char: Add RPMSG GET/SET FLOWCONTROL IOCTL support

[Bjorn Andersson]

On Sat, Apr 22, 2023 at 04:12:07PM +0530, Sarannya S wrote:
> From: Chris Lew <quic_clew@quicinc.com>
> 
> Add RPMSG_GET_OUTGOING_FLOWCONTROL and RPMSG_SET_INCOMING_FLOWCONTROL
> IOCTL support for rpmsg char device nodes to get/set the low level
> transport signals.
> 
> Signed-off-by: Chris Lew <quic_clew@quicinc.com>
> Signed-off-by: Deepak Kumar Singh <quic_deesin@quicinc.com>
> Signed-off-by: Sarannya S <quic_sarannya@quicinc.com>
> ---
>  drivers/rpmsg/rpmsg_char.c | 49 ++++++++++++++++++++++++++++++++++++++++------
>  include/uapi/linux/rpmsg.h | 11 ++++++++++-
>  2 files changed, 53 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/rpmsg/rpmsg_char.c b/drivers/rpmsg/rpmsg_char.c
> index a271fce..d50908f 100644
> --- a/drivers/rpmsg/rpmsg_char.c
> +++ b/drivers/rpmsg/rpmsg_char.c
> @@ -23,6 +23,7 @@
>  #include <linux/rpmsg.h>
>  #include <linux/skbuff.h>
>  #include <linux/slab.h>
> +#include <linux/termios.h>
>  #include <linux/uaccess.h>
>  #include <uapi/linux/rpmsg.h>
>  
> @@ -68,6 +69,8 @@ struct rpmsg_eptdev {
>  	struct sk_buff_head queue;
>  	wait_queue_head_t readq;
>  
> +	bool remote_flow;

I was about to agree with Arnaud, that this needs to be defaulted to
true. But the flag means "has the remote asked for flow to be limited".

As such, the name of this variable is misleading. Please rename it
"remote_flow_restricted" or something like that.

And please update the kerneldoc for this struct.

Regards,
Bjorn

> +	bool remote_flow_updated;
>  };
>  
>  int rpmsg_chrdev_eptdev_destroy(struct device *dev, void *data)
> @@ -116,6 +119,18 @@ static int rpmsg_ept_cb(struct rpmsg_device *rpdev, void *buf, int len,
>  	return 0;
>  }
>  
> +static int rpmsg_ept_flow_cb(struct rpmsg_device *rpdev, void *priv, bool enable)
> +{
> +	struct rpmsg_eptdev *eptdev = priv;
> +
> +	eptdev->remote_flow = enable;
> +	eptdev->remote_flow_updated = true;
> +
> +	wake_up_interruptible(&eptdev->readq);
> +
> +	return 0;
> +}
> +
>  static int rpmsg_eptdev_open(struct inode *inode, struct file *filp)
>  {
>  	struct rpmsg_eptdev *eptdev = cdev_to_eptdev(inode->i_cdev);
> @@ -152,6 +167,7 @@ static int rpmsg_eptdev_open(struct inode *inode, struct file *filp)
>  		return -EINVAL;
>  	}
>  
> +	ept->flow_cb = rpmsg_ept_flow_cb;
>  	eptdev->ept = ept;
>  	filp->private_data = eptdev;
>  	mutex_unlock(&eptdev->ept_lock);
> @@ -172,6 +188,7 @@ static int rpmsg_eptdev_release(struct inode *inode, struct file *filp)
>  		eptdev->ept = NULL;
>  	}
>  	mutex_unlock(&eptdev->ept_lock);
> +	eptdev->remote_flow_updated = false;
>  
>  	/* Discard all SKBs */
>  	skb_queue_purge(&eptdev->queue);
> @@ -285,6 +302,9 @@ static __poll_t rpmsg_eptdev_poll(struct file *filp, poll_table *wait)
>  	if (!skb_queue_empty(&eptdev->queue))
>  		mask |= EPOLLIN | EPOLLRDNORM;
>  
> +	if (eptdev->remote_flow_updated)
> +		mask |= EPOLLPRI;
> +
>  	mutex_lock(&eptdev->ept_lock);
>  	mask |= rpmsg_poll(eptdev->ept, filp, wait);
>  	mutex_unlock(&eptdev->ept_lock);
> @@ -297,14 +317,31 @@ static long rpmsg_eptdev_ioctl(struct file *fp, unsigned int cmd,
>  {
>  	struct rpmsg_eptdev *eptdev = fp->private_data;
>  
> -	if (cmd != RPMSG_DESTROY_EPT_IOCTL)
> -		return -EINVAL;
> +	bool set;
> +	int ret;
>  
> -	/* Don't allow to destroy a default endpoint. */
> -	if (eptdev->default_ept)
> -		return -EINVAL;
> +	switch (cmd) {
> +	case RPMSG_GET_OUTGOING_FLOWCONTROL:
> +		eptdev->remote_flow_updated = false;
> +		ret = put_user(eptdev->remote_flow, (int __user *)arg);
> +		break;
> +	case RPMSG_SET_INCOMING_FLOWCONTROL:
> +		set = !!arg;
> +		ret = rpmsg_set_flow_control(eptdev->ept, set, eptdev->chinfo.dst);
> +		break;
> +	case RPMSG_DESTROY_EPT_IOCTL:
> +		/* Don't allow to destroy a default endpoint. */
> +		if (eptdev->default_ept) {
> +			ret = -EINVAL;
> +			break;
> +		}
> +		ret = rpmsg_chrdev_eptdev_destroy(&eptdev->dev, NULL);
> +		break;
> +	default:
> +		ret = -EINVAL;
> +	}
>  
> -	return rpmsg_chrdev_eptdev_destroy(&eptdev->dev, NULL);
> +	return ret;
>  }
>  
>  static const struct file_operations rpmsg_eptdev_fops = {
> diff --git a/include/uapi/linux/rpmsg.h b/include/uapi/linux/rpmsg.h
> index 1637e68..c955e27 100644
> --- a/include/uapi/linux/rpmsg.h
> +++ b/include/uapi/linux/rpmsg.h
> @@ -10,7 +10,6 @@
>  #include <linux/types.h>
>  
>  #define RPMSG_ADDR_ANY		0xFFFFFFFF
> -
>  /**
>   * struct rpmsg_endpoint_info - endpoint info representation
>   * @name: name of service
> @@ -43,4 +42,14 @@ struct rpmsg_endpoint_info {
>   */
>  #define RPMSG_RELEASE_DEV_IOCTL	_IOW(0xb5, 0x4, struct rpmsg_endpoint_info)
>  
> +/**
> + * Set the flow control for the remote rpmsg char device.
> + */
> +#define RPMSG_GET_OUTGOING_FLOWCONTROL _IOW(0xb5, 0x5, struct rpmsg_endpoint_info)
> +
> +/**
> + * Set the flow control for the local rpmsg char device.
> + */
> +#define RPMSG_SET_INCOMING_FLOWCONTROL _IOW(0xb5, 0x6, struct rpmsg_endpoint_info)
> +
>  #endif
> -- 
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> a Linux Foundation Collaborative Project
> 

Re: [PATCH V7 1/3] rpmsg: core: Add signal API support

[Bjorn Andersson]

On Sat, Apr 22, 2023 at 04:12:05PM +0530, Sarannya S wrote:
> From: Deepak Kumar Singh <quic_deesin@quicinc.com>
> 
> Some transports like Glink support the state notifications between
> clients using flow control signals similar to serial protocol signals.
> Local glink client drivers can send and receive flow control status
> to glink clients running on remote processors.
> 
> Add APIs to support sending and receiving of flow control status by
> rpmsg clients.
> 
> Signed-off-by: Deepak Kumar Singh <quic_deesin@quicinc.com>
> Signed-off-by: Sarannya S <quic_sarannya@quicinc.com>
> ---
>  drivers/rpmsg/rpmsg_core.c     | 21 +++++++++++++++++++++
>  drivers/rpmsg/rpmsg_internal.h |  2 ++
>  include/linux/rpmsg.h          | 15 +++++++++++++++
>  3 files changed, 38 insertions(+)
> 
> diff --git a/drivers/rpmsg/rpmsg_core.c b/drivers/rpmsg/rpmsg_core.c
> index a2207c0..e8bbe05 100644
> --- a/drivers/rpmsg/rpmsg_core.c
> +++ b/drivers/rpmsg/rpmsg_core.c
> @@ -331,6 +331,25 @@ int rpmsg_trysend_offchannel(struct rpmsg_endpoint *ept, u32 src, u32 dst,
>  EXPORT_SYMBOL(rpmsg_trysend_offchannel);
>  
>  /**
> + * rpmsg_set_flow_control() - sets/clears serial flow control signals
> + * @ept:	the rpmsg endpoint
> + * @enable:	pause/resume incoming data flow	

As shown in the discussion, it's still not clear what true/false means.
Also, let's try to clarify that it's a request for the other side to do
something:

* rpmsg_set_flow_control() - request remote to pause/resume transmission
* ...
* @enable: flow restricted
* ...


PS. There's a stray space at the end of the line.

> + * @dst:	destination address of the endpoint
> + *
> + * Return: 0 on success and an appropriate error value on failure.
> + */
> +int rpmsg_set_flow_control(struct rpmsg_endpoint *ept, bool enable, u32 dst)
> +{
> +	if (WARN_ON(!ept))
> +		return -EINVAL;
> +	if (!ept->ops->set_flow_control)
> +		return -ENXIO;
> +
> +	return ept->ops->set_flow_control(ept, enable, dst);
> +}
> +EXPORT_SYMBOL_GPL(rpmsg_set_flow_control);
> +
> +/**
>   * rpmsg_get_mtu() - get maximum transmission buffer size for sending message.
>   * @ept: the rpmsg endpoint
>   *
> @@ -539,6 +558,8 @@ static int rpmsg_dev_probe(struct device *dev)
>  
>  		rpdev->ept = ept;
>  		rpdev->src = ept->addr;
> +
> +		ept->flow_cb = rpdrv->flowcontrol;
>  	}
>  
>  	err = rpdrv->probe(rpdev);
> diff --git a/drivers/rpmsg/rpmsg_internal.h b/drivers/rpmsg/rpmsg_internal.h
> index 39b646d..b6efd3e 100644
> --- a/drivers/rpmsg/rpmsg_internal.h
> +++ b/drivers/rpmsg/rpmsg_internal.h
> @@ -55,6 +55,7 @@ struct rpmsg_device_ops {
>   * @trysendto:		see @rpmsg_trysendto(), optional
>   * @trysend_offchannel:	see @rpmsg_trysend_offchannel(), optional
>   * @poll:		see @rpmsg_poll(), optional
> + * @set_flow_control:	see @rpmsg_set_flow_control(), optional
>   * @get_mtu:		see @rpmsg_get_mtu(), optional
>   *
>   * Indirection table for the operations that a rpmsg backend should implement.
> @@ -75,6 +76,7 @@ struct rpmsg_endpoint_ops {
>  			     void *data, int len);
>  	__poll_t (*poll)(struct rpmsg_endpoint *ept, struct file *filp,
>  			     poll_table *wait);
> +	int (*set_flow_control)(struct rpmsg_endpoint *ept, bool enable, u32 dst);
>  	ssize_t (*get_mtu)(struct rpmsg_endpoint *ept);
>  };
>  
> diff --git a/include/linux/rpmsg.h b/include/linux/rpmsg.h
> index 523c98b..a0e9d38 100644
> --- a/include/linux/rpmsg.h
> +++ b/include/linux/rpmsg.h
> @@ -64,12 +64,14 @@ struct rpmsg_device {
>  };
>  
>  typedef int (*rpmsg_rx_cb_t)(struct rpmsg_device *, void *, int, void *, u32);
> +typedef int (*rpmsg_flowcontrol_cb_t)(struct rpmsg_device *, void *, bool);
>  
>  /**
>   * struct rpmsg_endpoint - binds a local rpmsg address to its user
>   * @rpdev: rpmsg channel device
>   * @refcount: when this drops to zero, the ept is deallocated
>   * @cb: rx callback handler
> + * @flow_cb: remote flow control callback handler
>   * @cb_lock: must be taken before accessing/changing @cb
>   * @addr: local rpmsg address
>   * @priv: private data for the driver's use
> @@ -92,6 +94,7 @@ struct rpmsg_endpoint {
>  	struct rpmsg_device *rpdev;
>  	struct kref refcount;
>  	rpmsg_rx_cb_t cb;
> +	rpmsg_flowcontrol_cb_t flow_cb;
>  	struct mutex cb_lock;
>  	u32 addr;
>  	void *priv;
> @@ -106,6 +109,7 @@ struct rpmsg_endpoint {
>   * @probe: invoked when a matching rpmsg channel (i.e. device) is found
>   * @remove: invoked when the rpmsg channel is removed
>   * @callback: invoked when an inbound message is received on the channel
> + * @flowcontrol: invoked when remote side flow control status is received

s/status/request/

Regards,
Bjorn

>   */
>  struct rpmsg_driver {
>  	struct device_driver drv;
> @@ -113,6 +117,7 @@ struct rpmsg_driver {
>  	int (*probe)(struct rpmsg_device *dev);
>  	void (*remove)(struct rpmsg_device *dev);
>  	int (*callback)(struct rpmsg_device *, void *, int, void *, u32);
> +	int (*flowcontrol)(struct rpmsg_device *, void *, bool);
>  };
>  
>  static inline u16 rpmsg16_to_cpu(struct rpmsg_device *rpdev, __rpmsg16 val)
> @@ -192,6 +197,8 @@ __poll_t rpmsg_poll(struct rpmsg_endpoint *ept, struct file *filp,
>  
>  ssize_t rpmsg_get_mtu(struct rpmsg_endpoint *ept);
>  
> +int rpmsg_set_flow_control(struct rpmsg_endpoint *ept, bool enable, u32 dst);
> +
>  #else
>  
>  static inline int rpmsg_register_device_override(struct rpmsg_device *rpdev,
> @@ -316,6 +323,14 @@ static inline ssize_t rpmsg_get_mtu(struct rpmsg_endpoint *ept)
>  	return -ENXIO;
>  }
>  
> +static inline int rpmsg_set_flow_control(struct rpmsg_endpoint *ept, bool enable, u32 dst)
> +{
> +	/* 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 */
> -- 
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> a Linux Foundation Collaborative Project
> 

Re: [PATCH V7 1/3] rpmsg: core: Add signal API support

[Arnaud POULIQUEN]

Hi,

On 6/14/23 17:24, Bjorn Andersson wrote:
> On Mon, Apr 24, 2023 at 02:49:29PM +0200, Arnaud POULIQUEN wrote:
>> Hello,
>>
>> On 4/22/23 12:42, Sarannya S wrote:
>>> From: Deepak Kumar Singh <quic_deesin@quicinc.com>
>>>
>>> Some transports like Glink support the state notifications between
>>> clients using flow control signals similar to serial protocol signals.
>>> Local glink client drivers can send and receive flow control status
>>> to glink clients running on remote processors.
>>>
>>> Add APIs to support sending and receiving of flow control status by
>>> rpmsg clients.
>>>
>>> Signed-off-by: Deepak Kumar Singh <quic_deesin@quicinc.com>
>>> Signed-off-by: Sarannya S <quic_sarannya@quicinc.com>
>>> ---
>>>  drivers/rpmsg/rpmsg_core.c     | 21 +++++++++++++++++++++
>>>  drivers/rpmsg/rpmsg_internal.h |  2 ++
>>>  include/linux/rpmsg.h          | 15 +++++++++++++++
>>>  3 files changed, 38 insertions(+)
>>>
>>> diff --git a/drivers/rpmsg/rpmsg_core.c b/drivers/rpmsg/rpmsg_core.c
>>> index a2207c0..e8bbe05 100644
>>> --- a/drivers/rpmsg/rpmsg_core.c
>>> +++ b/drivers/rpmsg/rpmsg_core.c
>>> @@ -331,6 +331,25 @@ int rpmsg_trysend_offchannel(struct rpmsg_endpoint *ept, u32 src, u32 dst,
>>>  EXPORT_SYMBOL(rpmsg_trysend_offchannel);
>>>  
>>>  /**
>>> + * rpmsg_set_flow_control() - sets/clears serial flow control signals
>>> + * @ept:	the rpmsg endpoint
>>> + * @enable:	pause/resume incoming data flow	
>>> + * @dst:	destination address of the endpoint
>>> + *
>>> + * Return: 0 on success and an appropriate error value on failure.
>>> + */
>>> +int rpmsg_set_flow_control(struct rpmsg_endpoint *ept, bool enable, u32 dst)
>>> +{
>>> +	if (WARN_ON(!ept))
>>> +		return -EINVAL;
>>> +	if (!ept->ops->set_flow_control)
>>> +		return -ENXIO;
>>
>> Here we return an error if the backend does not implement the ops.
>> But the set_flow_control ops is optional.
>> Should we return 0 instead with a debug message?
>>
> 
> It seems reasonable to allow the software to react to the absence of
> flow control support, so a debug message wouldn't help.
> 
> But advertising that more explicitly by returning something like
> EOPNOTSUPP seems better.

Right, this seems more reliable.

Thanks,
Arnaud

> 
> Regards,
> Bjorn

Re: [PATCH V7 1/3] rpmsg: core: Add signal API support

[Arnaud POULIQUEN]

On 6/14/23 17:54, Bjorn Andersson wrote:
> On Sat, Apr 22, 2023 at 04:12:05PM +0530, Sarannya S wrote:
>> From: Deepak Kumar Singh <quic_deesin@quicinc.com>
>>
>> Some transports like Glink support the state notifications between
>> clients using flow control signals similar to serial protocol signals.
>> Local glink client drivers can send and receive flow control status
>> to glink clients running on remote processors.
>>
>> Add APIs to support sending and receiving of flow control status by
>> rpmsg clients.
>>
>> Signed-off-by: Deepak Kumar Singh <quic_deesin@quicinc.com>
>> Signed-off-by: Sarannya S <quic_sarannya@quicinc.com>
>> ---
>>  drivers/rpmsg/rpmsg_core.c     | 21 +++++++++++++++++++++
>>  drivers/rpmsg/rpmsg_internal.h |  2 ++
>>  include/linux/rpmsg.h          | 15 +++++++++++++++
>>  3 files changed, 38 insertions(+)
>>
>> diff --git a/drivers/rpmsg/rpmsg_core.c b/drivers/rpmsg/rpmsg_core.c
>> index a2207c0..e8bbe05 100644
>> --- a/drivers/rpmsg/rpmsg_core.c
>> +++ b/drivers/rpmsg/rpmsg_core.c
>> @@ -331,6 +331,25 @@ int rpmsg_trysend_offchannel(struct rpmsg_endpoint *ept, u32 src, u32 dst,
>>  EXPORT_SYMBOL(rpmsg_trysend_offchannel);
>>  
>>  /**
>> + * rpmsg_set_flow_control() - sets/clears serial flow control signals
>> + * @ept:	the rpmsg endpoint
>> + * @enable:	pause/resume incoming data flow	
> 
> As shown in the discussion, it's still not clear what true/false means.
> Also, let's try to clarify that it's a request for the other side to do
> something:
> 
> * rpmsg_set_flow_control() - request remote to pause/resume transmission
> * ...
> * @enable: flow restricted
> * ...
> 
> 
> PS. There's a stray space at the end of the line.

The notion of flow restricted seems to me also ambiguous. It does
not specify if the stream is limited in term of bandwidth or stopped.

What about using XON/XOFF as specified in software flow control[1]

XOFF	Pause transmission
XON	Resume transmission

or simply pause/resume definitions

[1]https://en.wikipedia.org/wiki/Software_flow_control

Regards,
Arnaud

> 
>> + * @dst:	destination address of the endpoint
>> + *
>> + * Return: 0 on success and an appropriate error value on failure.
>> + */
>> +int rpmsg_set_flow_control(struct rpmsg_endpoint *ept, bool enable, u32 dst)
>> +{
>> +	if (WARN_ON(!ept))
>> +		return -EINVAL;
>> +	if (!ept->ops->set_flow_control)
>> +		return -ENXIO;
>> +
>> +	return ept->ops->set_flow_control(ept, enable, dst);
>> +}
>> +EXPORT_SYMBOL_GPL(rpmsg_set_flow_control);
>> +
>> +/**
>>   * rpmsg_get_mtu() - get maximum transmission buffer size for sending message.
>>   * @ept: the rpmsg endpoint
>>   *
>> @@ -539,6 +558,8 @@ static int rpmsg_dev_probe(struct device *dev)
>>  
>>  		rpdev->ept = ept;
>>  		rpdev->src = ept->addr;
>> +
>> +		ept->flow_cb = rpdrv->flowcontrol;
>>  	}
>>  
>>  	err = rpdrv->probe(rpdev);
>> diff --git a/drivers/rpmsg/rpmsg_internal.h b/drivers/rpmsg/rpmsg_internal.h
>> index 39b646d..b6efd3e 100644
>> --- a/drivers/rpmsg/rpmsg_internal.h
>> +++ b/drivers/rpmsg/rpmsg_internal.h
>> @@ -55,6 +55,7 @@ struct rpmsg_device_ops {
>>   * @trysendto:		see @rpmsg_trysendto(), optional
>>   * @trysend_offchannel:	see @rpmsg_trysend_offchannel(), optional
>>   * @poll:		see @rpmsg_poll(), optional
>> + * @set_flow_control:	see @rpmsg_set_flow_control(), optional
>>   * @get_mtu:		see @rpmsg_get_mtu(), optional
>>   *
>>   * Indirection table for the operations that a rpmsg backend should implement.
>> @@ -75,6 +76,7 @@ struct rpmsg_endpoint_ops {
>>  			     void *data, int len);
>>  	__poll_t (*poll)(struct rpmsg_endpoint *ept, struct file *filp,
>>  			     poll_table *wait);
>> +	int (*set_flow_control)(struct rpmsg_endpoint *ept, bool enable, u32 dst);
>>  	ssize_t (*get_mtu)(struct rpmsg_endpoint *ept);
>>  };
>>  
>> diff --git a/include/linux/rpmsg.h b/include/linux/rpmsg.h
>> index 523c98b..a0e9d38 100644
>> --- a/include/linux/rpmsg.h
>> +++ b/include/linux/rpmsg.h
>> @@ -64,12 +64,14 @@ struct rpmsg_device {
>>  };
>>  
>>  typedef int (*rpmsg_rx_cb_t)(struct rpmsg_device *, void *, int, void *, u32);
>> +typedef int (*rpmsg_flowcontrol_cb_t)(struct rpmsg_device *, void *, bool);
>>  
>>  /**
>>   * struct rpmsg_endpoint - binds a local rpmsg address to its user
>>   * @rpdev: rpmsg channel device
>>   * @refcount: when this drops to zero, the ept is deallocated
>>   * @cb: rx callback handler
>> + * @flow_cb: remote flow control callback handler
>>   * @cb_lock: must be taken before accessing/changing @cb
>>   * @addr: local rpmsg address
>>   * @priv: private data for the driver's use
>> @@ -92,6 +94,7 @@ struct rpmsg_endpoint {
>>  	struct rpmsg_device *rpdev;
>>  	struct kref refcount;
>>  	rpmsg_rx_cb_t cb;
>> +	rpmsg_flowcontrol_cb_t flow_cb;
>>  	struct mutex cb_lock;
>>  	u32 addr;
>>  	void *priv;
>> @@ -106,6 +109,7 @@ struct rpmsg_endpoint {
>>   * @probe: invoked when a matching rpmsg channel (i.e. device) is found
>>   * @remove: invoked when the rpmsg channel is removed
>>   * @callback: invoked when an inbound message is received on the channel
>> + * @flowcontrol: invoked when remote side flow control status is received
> 
> s/status/request/
> 
> Regards,
> Bjorn
> 
>>   */
>>  struct rpmsg_driver {
>>  	struct device_driver drv;
>> @@ -113,6 +117,7 @@ struct rpmsg_driver {
>>  	int (*probe)(struct rpmsg_device *dev);
>>  	void (*remove)(struct rpmsg_device *dev);
>>  	int (*callback)(struct rpmsg_device *, void *, int, void *, u32);
>> +	int (*flowcontrol)(struct rpmsg_device *, void *, bool);
>>  };
>>  
>>  static inline u16 rpmsg16_to_cpu(struct rpmsg_device *rpdev, __rpmsg16 val)
>> @@ -192,6 +197,8 @@ __poll_t rpmsg_poll(struct rpmsg_endpoint *ept, struct file *filp,
>>  
>>  ssize_t rpmsg_get_mtu(struct rpmsg_endpoint *ept);
>>  
>> +int rpmsg_set_flow_control(struct rpmsg_endpoint *ept, bool enable, u32 dst);
>> +
>>  #else
>>  
>>  static inline int rpmsg_register_device_override(struct rpmsg_device *rpdev,
>> @@ -316,6 +323,14 @@ static inline ssize_t rpmsg_get_mtu(struct rpmsg_endpoint *ept)
>>  	return -ENXIO;
>>  }
>>  
>> +static inline int rpmsg_set_flow_control(struct rpmsg_endpoint *ept, bool enable, u32 dst)
>> +{
>> +	/* 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 */
>> -- 
>> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
>> a Linux Foundation Collaborative Project
>>

Re: [PATCH V7 1/3] rpmsg: core: Add signal API support

[Bjorn Andersson]

On Thu, Jun 15, 2023 at 11:01:14AM +0200, Arnaud POULIQUEN wrote:
> 
> 
> On 6/14/23 17:54, Bjorn Andersson wrote:
> > On Sat, Apr 22, 2023 at 04:12:05PM +0530, Sarannya S wrote:
> >> From: Deepak Kumar Singh <quic_deesin@quicinc.com>
> >>
> >> Some transports like Glink support the state notifications between
> >> clients using flow control signals similar to serial protocol signals.
> >> Local glink client drivers can send and receive flow control status
> >> to glink clients running on remote processors.
> >>
> >> Add APIs to support sending and receiving of flow control status by
> >> rpmsg clients.
> >>
> >> Signed-off-by: Deepak Kumar Singh <quic_deesin@quicinc.com>
> >> Signed-off-by: Sarannya S <quic_sarannya@quicinc.com>
> >> ---
> >>  drivers/rpmsg/rpmsg_core.c     | 21 +++++++++++++++++++++
> >>  drivers/rpmsg/rpmsg_internal.h |  2 ++
> >>  include/linux/rpmsg.h          | 15 +++++++++++++++
> >>  3 files changed, 38 insertions(+)
> >>
> >> diff --git a/drivers/rpmsg/rpmsg_core.c b/drivers/rpmsg/rpmsg_core.c
> >> index a2207c0..e8bbe05 100644
> >> --- a/drivers/rpmsg/rpmsg_core.c
> >> +++ b/drivers/rpmsg/rpmsg_core.c
> >> @@ -331,6 +331,25 @@ int rpmsg_trysend_offchannel(struct rpmsg_endpoint *ept, u32 src, u32 dst,
> >>  EXPORT_SYMBOL(rpmsg_trysend_offchannel);
> >>  
> >>  /**
> >> + * rpmsg_set_flow_control() - sets/clears serial flow control signals
> >> + * @ept:	the rpmsg endpoint
> >> + * @enable:	pause/resume incoming data flow	
> > 
> > As shown in the discussion, it's still not clear what true/false means.
> > Also, let's try to clarify that it's a request for the other side to do
> > something:
> > 
> > * rpmsg_set_flow_control() - request remote to pause/resume transmission
> > * ...
> > * @enable: flow restricted
> > * ...
> > 
> > 
> > PS. There's a stray space at the end of the line.
> 
> The notion of flow restricted seems to me also ambiguous. It does
> not specify if the stream is limited in term of bandwidth or stopped.
> 
> What about using XON/XOFF as specified in software flow control[1]
> 
> XOFF	Pause transmission
> XON	Resume transmission
> 
> or simply pause/resume definitions
> 

I agree, that's still ambiguous.

I was concerned about expressing it such that the reader would assume
that calling this means there will be no more data coming, but there
might be things in the queues etc. Expressing it in terms of the state
of transmission is clearer.


/*
 * rpmsg_set_flow_control() - request remote to pause/resume transmission
 ...
 * @enable: Pause transmission
 ...
 */

Does that sound okay and clear to you?

Thanks,
Bjorn

> [1]https://en.wikipedia.org/wiki/Software_flow_control
> 
> Regards,
> Arnaud
> 
> > 
> >> + * @dst:	destination address of the endpoint
> >> + *
> >> + * Return: 0 on success and an appropriate error value on failure.
> >> + */
> >> +int rpmsg_set_flow_control(struct rpmsg_endpoint *ept, bool enable, u32 dst)
> >> +{
> >> +	if (WARN_ON(!ept))
> >> +		return -EINVAL;
> >> +	if (!ept->ops->set_flow_control)
> >> +		return -ENXIO;
> >> +
> >> +	return ept->ops->set_flow_control(ept, enable, dst);
> >> +}
> >> +EXPORT_SYMBOL_GPL(rpmsg_set_flow_control);
> >> +
> >> +/**
> >>   * rpmsg_get_mtu() - get maximum transmission buffer size for sending message.
> >>   * @ept: the rpmsg endpoint
> >>   *
> >> @@ -539,6 +558,8 @@ static int rpmsg_dev_probe(struct device *dev)
> >>  
> >>  		rpdev->ept = ept;
> >>  		rpdev->src = ept->addr;
> >> +
> >> +		ept->flow_cb = rpdrv->flowcontrol;
> >>  	}
> >>  
> >>  	err = rpdrv->probe(rpdev);
> >> diff --git a/drivers/rpmsg/rpmsg_internal.h b/drivers/rpmsg/rpmsg_internal.h
> >> index 39b646d..b6efd3e 100644
> >> --- a/drivers/rpmsg/rpmsg_internal.h
> >> +++ b/drivers/rpmsg/rpmsg_internal.h
> >> @@ -55,6 +55,7 @@ struct rpmsg_device_ops {
> >>   * @trysendto:		see @rpmsg_trysendto(), optional
> >>   * @trysend_offchannel:	see @rpmsg_trysend_offchannel(), optional
> >>   * @poll:		see @rpmsg_poll(), optional
> >> + * @set_flow_control:	see @rpmsg_set_flow_control(), optional
> >>   * @get_mtu:		see @rpmsg_get_mtu(), optional
> >>   *
> >>   * Indirection table for the operations that a rpmsg backend should implement.
> >> @@ -75,6 +76,7 @@ struct rpmsg_endpoint_ops {
> >>  			     void *data, int len);
> >>  	__poll_t (*poll)(struct rpmsg_endpoint *ept, struct file *filp,
> >>  			     poll_table *wait);
> >> +	int (*set_flow_control)(struct rpmsg_endpoint *ept, bool enable, u32 dst);
> >>  	ssize_t (*get_mtu)(struct rpmsg_endpoint *ept);
> >>  };
> >>  
> >> diff --git a/include/linux/rpmsg.h b/include/linux/rpmsg.h
> >> index 523c98b..a0e9d38 100644
> >> --- a/include/linux/rpmsg.h
> >> +++ b/include/linux/rpmsg.h
> >> @@ -64,12 +64,14 @@ struct rpmsg_device {
> >>  };
> >>  
> >>  typedef int (*rpmsg_rx_cb_t)(struct rpmsg_device *, void *, int, void *, u32);
> >> +typedef int (*rpmsg_flowcontrol_cb_t)(struct rpmsg_device *, void *, bool);
> >>  
> >>  /**
> >>   * struct rpmsg_endpoint - binds a local rpmsg address to its user
> >>   * @rpdev: rpmsg channel device
> >>   * @refcount: when this drops to zero, the ept is deallocated
> >>   * @cb: rx callback handler
> >> + * @flow_cb: remote flow control callback handler
> >>   * @cb_lock: must be taken before accessing/changing @cb
> >>   * @addr: local rpmsg address
> >>   * @priv: private data for the driver's use
> >> @@ -92,6 +94,7 @@ struct rpmsg_endpoint {
> >>  	struct rpmsg_device *rpdev;
> >>  	struct kref refcount;
> >>  	rpmsg_rx_cb_t cb;
> >> +	rpmsg_flowcontrol_cb_t flow_cb;
> >>  	struct mutex cb_lock;
> >>  	u32 addr;
> >>  	void *priv;
> >> @@ -106,6 +109,7 @@ struct rpmsg_endpoint {
> >>   * @probe: invoked when a matching rpmsg channel (i.e. device) is found
> >>   * @remove: invoked when the rpmsg channel is removed
> >>   * @callback: invoked when an inbound message is received on the channel
> >> + * @flowcontrol: invoked when remote side flow control status is received
> > 
> > s/status/request/
> > 
> > Regards,
> > Bjorn
> > 
> >>   */
> >>  struct rpmsg_driver {
> >>  	struct device_driver drv;
> >> @@ -113,6 +117,7 @@ struct rpmsg_driver {
> >>  	int (*probe)(struct rpmsg_device *dev);
> >>  	void (*remove)(struct rpmsg_device *dev);
> >>  	int (*callback)(struct rpmsg_device *, void *, int, void *, u32);
> >> +	int (*flowcontrol)(struct rpmsg_device *, void *, bool);
> >>  };
> >>  
> >>  static inline u16 rpmsg16_to_cpu(struct rpmsg_device *rpdev, __rpmsg16 val)
> >> @@ -192,6 +197,8 @@ __poll_t rpmsg_poll(struct rpmsg_endpoint *ept, struct file *filp,
> >>  
> >>  ssize_t rpmsg_get_mtu(struct rpmsg_endpoint *ept);
> >>  
> >> +int rpmsg_set_flow_control(struct rpmsg_endpoint *ept, bool enable, u32 dst);
> >> +
> >>  #else
> >>  
> >>  static inline int rpmsg_register_device_override(struct rpmsg_device *rpdev,
> >> @@ -316,6 +323,14 @@ static inline ssize_t rpmsg_get_mtu(struct rpmsg_endpoint *ept)
> >>  	return -ENXIO;
> >>  }
> >>  
> >> +static inline int rpmsg_set_flow_control(struct rpmsg_endpoint *ept, bool enable, u32 dst)
> >> +{
> >> +	/* 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 */
> >> -- 
> >> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> >> a Linux Foundation Collaborative Project
> >>

Re: [PATCH V7 1/3] rpmsg: core: Add signal API support

[Arnaud POULIQUEN]

On 6/15/23 16:50, Bjorn Andersson wrote:
> On Thu, Jun 15, 2023 at 11:01:14AM +0200, Arnaud POULIQUEN wrote:
>>
>>
>> On 6/14/23 17:54, Bjorn Andersson wrote:
>>> On Sat, Apr 22, 2023 at 04:12:05PM +0530, Sarannya S wrote:
>>>> From: Deepak Kumar Singh <quic_deesin@quicinc.com>
>>>>
>>>> Some transports like Glink support the state notifications between
>>>> clients using flow control signals similar to serial protocol signals.
>>>> Local glink client drivers can send and receive flow control status
>>>> to glink clients running on remote processors.
>>>>
>>>> Add APIs to support sending and receiving of flow control status by
>>>> rpmsg clients.
>>>>
>>>> Signed-off-by: Deepak Kumar Singh <quic_deesin@quicinc.com>
>>>> Signed-off-by: Sarannya S <quic_sarannya@quicinc.com>
>>>> ---
>>>>  drivers/rpmsg/rpmsg_core.c     | 21 +++++++++++++++++++++
>>>>  drivers/rpmsg/rpmsg_internal.h |  2 ++
>>>>  include/linux/rpmsg.h          | 15 +++++++++++++++
>>>>  3 files changed, 38 insertions(+)
>>>>
>>>> diff --git a/drivers/rpmsg/rpmsg_core.c b/drivers/rpmsg/rpmsg_core.c
>>>> index a2207c0..e8bbe05 100644
>>>> --- a/drivers/rpmsg/rpmsg_core.c
>>>> +++ b/drivers/rpmsg/rpmsg_core.c
>>>> @@ -331,6 +331,25 @@ int rpmsg_trysend_offchannel(struct rpmsg_endpoint *ept, u32 src, u32 dst,
>>>>  EXPORT_SYMBOL(rpmsg_trysend_offchannel);
>>>>  
>>>>  /**
>>>> + * rpmsg_set_flow_control() - sets/clears serial flow control signals
>>>> + * @ept:	the rpmsg endpoint
>>>> + * @enable:	pause/resume incoming data flow	
>>>
>>> As shown in the discussion, it's still not clear what true/false means.
>>> Also, let's try to clarify that it's a request for the other side to do
>>> something:
>>>
>>> * rpmsg_set_flow_control() - request remote to pause/resume transmission
>>> * ...
>>> * @enable: flow restricted
>>> * ...
>>>
>>>
>>> PS. There's a stray space at the end of the line.
>>
>> The notion of flow restricted seems to me also ambiguous. It does
>> not specify if the stream is limited in term of bandwidth or stopped.
>>
>> What about using XON/XOFF as specified in software flow control[1]
>>
>> XOFF	Pause transmission
>> XON	Resume transmission
>>
>> or simply pause/resume definitions
>>
> 
> I agree, that's still ambiguous.
> 
> I was concerned about expressing it such that the reader would assume
> that calling this means there will be no more data coming, but there
> might be things in the queues etc. Expressing it in terms of the state
> of transmission is clearer.
> 
> 
> /*
>  * rpmsg_set_flow_control() - request remote to pause/resume transmission
>  ...
>  * @enable: Pause transmission
>  ...
>  */
> 
> Does that sound okay and clear to you?

Much better! I still have a nitpicking point :)
What about replacing @enable variable by @pause to align the variable with the
usage?
 /*
  * rpmsg_set_flow_control() - request remote to pause/resume transmission
  ...
  * @pause: set to 1 to pause transmission, to 0 to resume the transmission
  ...
  */

Thanks,
Arnaud

> 
> Thanks,
> Bjorn
> 
>> [1]https://en.wikipedia.org/wiki/Software_flow_control
>>
>> Regards,
>> Arnaud
>>
>>>
>>>> + * @dst:	destination address of the endpoint
>>>> + *
>>>> + * Return: 0 on success and an appropriate error value on failure.
>>>> + */
>>>> +int rpmsg_set_flow_control(struct rpmsg_endpoint *ept, bool enable, u32 dst)
>>>> +{
>>>> +	if (WARN_ON(!ept))
>>>> +		return -EINVAL;
>>>> +	if (!ept->ops->set_flow_control)
>>>> +		return -ENXIO;
>>>> +
>>>> +	return ept->ops->set_flow_control(ept, enable, dst);
>>>> +}
>>>> +EXPORT_SYMBOL_GPL(rpmsg_set_flow_control);
>>>> +
>>>> +/**
>>>>   * rpmsg_get_mtu() - get maximum transmission buffer size for sending message.
>>>>   * @ept: the rpmsg endpoint
>>>>   *
>>>> @@ -539,6 +558,8 @@ static int rpmsg_dev_probe(struct device *dev)
>>>>  
>>>>  		rpdev->ept = ept;
>>>>  		rpdev->src = ept->addr;
>>>> +
>>>> +		ept->flow_cb = rpdrv->flowcontrol;
>>>>  	}
>>>>  
>>>>  	err = rpdrv->probe(rpdev);
>>>> diff --git a/drivers/rpmsg/rpmsg_internal.h b/drivers/rpmsg/rpmsg_internal.h
>>>> index 39b646d..b6efd3e 100644
>>>> --- a/drivers/rpmsg/rpmsg_internal.h
>>>> +++ b/drivers/rpmsg/rpmsg_internal.h
>>>> @@ -55,6 +55,7 @@ struct rpmsg_device_ops {
>>>>   * @trysendto:		see @rpmsg_trysendto(), optional
>>>>   * @trysend_offchannel:	see @rpmsg_trysend_offchannel(), optional
>>>>   * @poll:		see @rpmsg_poll(), optional
>>>> + * @set_flow_control:	see @rpmsg_set_flow_control(), optional
>>>>   * @get_mtu:		see @rpmsg_get_mtu(), optional
>>>>   *
>>>>   * Indirection table for the operations that a rpmsg backend should implement.
>>>> @@ -75,6 +76,7 @@ struct rpmsg_endpoint_ops {
>>>>  			     void *data, int len);
>>>>  	__poll_t (*poll)(struct rpmsg_endpoint *ept, struct file *filp,
>>>>  			     poll_table *wait);
>>>> +	int (*set_flow_control)(struct rpmsg_endpoint *ept, bool enable, u32 dst);
>>>>  	ssize_t (*get_mtu)(struct rpmsg_endpoint *ept);
>>>>  };
>>>>  
>>>> diff --git a/include/linux/rpmsg.h b/include/linux/rpmsg.h
>>>> index 523c98b..a0e9d38 100644
>>>> --- a/include/linux/rpmsg.h
>>>> +++ b/include/linux/rpmsg.h
>>>> @@ -64,12 +64,14 @@ struct rpmsg_device {
>>>>  };
>>>>  
>>>>  typedef int (*rpmsg_rx_cb_t)(struct rpmsg_device *, void *, int, void *, u32);
>>>> +typedef int (*rpmsg_flowcontrol_cb_t)(struct rpmsg_device *, void *, bool);
>>>>  
>>>>  /**
>>>>   * struct rpmsg_endpoint - binds a local rpmsg address to its user
>>>>   * @rpdev: rpmsg channel device
>>>>   * @refcount: when this drops to zero, the ept is deallocated
>>>>   * @cb: rx callback handler
>>>> + * @flow_cb: remote flow control callback handler
>>>>   * @cb_lock: must be taken before accessing/changing @cb
>>>>   * @addr: local rpmsg address
>>>>   * @priv: private data for the driver's use
>>>> @@ -92,6 +94,7 @@ struct rpmsg_endpoint {
>>>>  	struct rpmsg_device *rpdev;
>>>>  	struct kref refcount;
>>>>  	rpmsg_rx_cb_t cb;
>>>> +	rpmsg_flowcontrol_cb_t flow_cb;
>>>>  	struct mutex cb_lock;
>>>>  	u32 addr;
>>>>  	void *priv;
>>>> @@ -106,6 +109,7 @@ struct rpmsg_endpoint {
>>>>   * @probe: invoked when a matching rpmsg channel (i.e. device) is found
>>>>   * @remove: invoked when the rpmsg channel is removed
>>>>   * @callback: invoked when an inbound message is received on the channel
>>>> + * @flowcontrol: invoked when remote side flow control status is received
>>>
>>> s/status/request/
>>>
>>> Regards,
>>> Bjorn
>>>
>>>>   */
>>>>  struct rpmsg_driver {
>>>>  	struct device_driver drv;
>>>> @@ -113,6 +117,7 @@ struct rpmsg_driver {
>>>>  	int (*probe)(struct rpmsg_device *dev);
>>>>  	void (*remove)(struct rpmsg_device *dev);
>>>>  	int (*callback)(struct rpmsg_device *, void *, int, void *, u32);
>>>> +	int (*flowcontrol)(struct rpmsg_device *, void *, bool);
>>>>  };
>>>>  
>>>>  static inline u16 rpmsg16_to_cpu(struct rpmsg_device *rpdev, __rpmsg16 val)
>>>> @@ -192,6 +197,8 @@ __poll_t rpmsg_poll(struct rpmsg_endpoint *ept, struct file *filp,
>>>>  
>>>>  ssize_t rpmsg_get_mtu(struct rpmsg_endpoint *ept);
>>>>  
>>>> +int rpmsg_set_flow_control(struct rpmsg_endpoint *ept, bool enable, u32 dst);
>>>> +
>>>>  #else
>>>>  
>>>>  static inline int rpmsg_register_device_override(struct rpmsg_device *rpdev,
>>>> @@ -316,6 +323,14 @@ static inline ssize_t rpmsg_get_mtu(struct rpmsg_endpoint *ept)
>>>>  	return -ENXIO;
>>>>  }
>>>>  
>>>> +static inline int rpmsg_set_flow_control(struct rpmsg_endpoint *ept, bool enable, u32 dst)
>>>> +{
>>>> +	/* 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 */
>>>> -- 
>>>> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
>>>> a Linux Foundation Collaborative Project
>>>>

Re: [PATCH V7 1/3] rpmsg: core: Add signal API support

[Bjorn Andersson]

On Thu, Jun 15, 2023 at 06:19:37PM +0200, Arnaud POULIQUEN wrote:
> 
> 
> On 6/15/23 16:50, Bjorn Andersson wrote:
> > On Thu, Jun 15, 2023 at 11:01:14AM +0200, Arnaud POULIQUEN wrote:
> >>
> >>
> >> On 6/14/23 17:54, Bjorn Andersson wrote:
> >>> On Sat, Apr 22, 2023 at 04:12:05PM +0530, Sarannya S wrote:
> >>>> From: Deepak Kumar Singh <quic_deesin@quicinc.com>
> >>>>
> >>>> Some transports like Glink support the state notifications between
> >>>> clients using flow control signals similar to serial protocol signals.
> >>>> Local glink client drivers can send and receive flow control status
> >>>> to glink clients running on remote processors.
> >>>>
> >>>> Add APIs to support sending and receiving of flow control status by
> >>>> rpmsg clients.
> >>>>
> >>>> Signed-off-by: Deepak Kumar Singh <quic_deesin@quicinc.com>
> >>>> Signed-off-by: Sarannya S <quic_sarannya@quicinc.com>
> >>>> ---
> >>>>  drivers/rpmsg/rpmsg_core.c     | 21 +++++++++++++++++++++
> >>>>  drivers/rpmsg/rpmsg_internal.h |  2 ++
> >>>>  include/linux/rpmsg.h          | 15 +++++++++++++++
> >>>>  3 files changed, 38 insertions(+)
> >>>>
> >>>> diff --git a/drivers/rpmsg/rpmsg_core.c b/drivers/rpmsg/rpmsg_core.c
> >>>> index a2207c0..e8bbe05 100644
> >>>> --- a/drivers/rpmsg/rpmsg_core.c
> >>>> +++ b/drivers/rpmsg/rpmsg_core.c
> >>>> @@ -331,6 +331,25 @@ int rpmsg_trysend_offchannel(struct rpmsg_endpoint *ept, u32 src, u32 dst,
> >>>>  EXPORT_SYMBOL(rpmsg_trysend_offchannel);
> >>>>  
> >>>>  /**
> >>>> + * rpmsg_set_flow_control() - sets/clears serial flow control signals
> >>>> + * @ept:	the rpmsg endpoint
> >>>> + * @enable:	pause/resume incoming data flow	
> >>>
> >>> As shown in the discussion, it's still not clear what true/false means.
> >>> Also, let's try to clarify that it's a request for the other side to do
> >>> something:
> >>>
> >>> * rpmsg_set_flow_control() - request remote to pause/resume transmission
> >>> * ...
> >>> * @enable: flow restricted
> >>> * ...
> >>>
> >>>
> >>> PS. There's a stray space at the end of the line.
> >>
> >> The notion of flow restricted seems to me also ambiguous. It does
> >> not specify if the stream is limited in term of bandwidth or stopped.
> >>
> >> What about using XON/XOFF as specified in software flow control[1]
> >>
> >> XOFF	Pause transmission
> >> XON	Resume transmission
> >>
> >> or simply pause/resume definitions
> >>
> > 
> > I agree, that's still ambiguous.
> > 
> > I was concerned about expressing it such that the reader would assume
> > that calling this means there will be no more data coming, but there
> > might be things in the queues etc. Expressing it in terms of the state
> > of transmission is clearer.
> > 
> > 
> > /*
> >  * rpmsg_set_flow_control() - request remote to pause/resume transmission
> >  ...
> >  * @enable: Pause transmission
> >  ...
> >  */
> > 
> > Does that sound okay and clear to you?
> 
> Much better! I still have a nitpicking point :)
> What about replacing @enable variable by @pause to align the variable with the
> usage?
>  /*
>   * rpmsg_set_flow_control() - request remote to pause/resume transmission
>   ...
>   * @pause: set to 1 to pause transmission, to 0 to resume the transmission

It's a boolean, so I think with your name change suggestion, together
with the function description, it should be clear enough what the two
states (true/false) means.

* @pause: Pause transmission

Thanks,
Bjorn

Re: [PATCH V7 1/3] rpmsg: core: Add signal API support

[Arnaud POULIQUEN]

On 6/15/23 18:45, Bjorn Andersson wrote:
> On Thu, Jun 15, 2023 at 06:19:37PM +0200, Arnaud POULIQUEN wrote:
>>
>>
>> On 6/15/23 16:50, Bjorn Andersson wrote:
>>> On Thu, Jun 15, 2023 at 11:01:14AM +0200, Arnaud POULIQUEN wrote:
>>>>
>>>>
>>>> On 6/14/23 17:54, Bjorn Andersson wrote:
>>>>> On Sat, Apr 22, 2023 at 04:12:05PM +0530, Sarannya S wrote:
>>>>>> From: Deepak Kumar Singh <quic_deesin@quicinc.com>
>>>>>>
>>>>>> Some transports like Glink support the state notifications between
>>>>>> clients using flow control signals similar to serial protocol signals.
>>>>>> Local glink client drivers can send and receive flow control status
>>>>>> to glink clients running on remote processors.
>>>>>>
>>>>>> Add APIs to support sending and receiving of flow control status by
>>>>>> rpmsg clients.
>>>>>>
>>>>>> Signed-off-by: Deepak Kumar Singh <quic_deesin@quicinc.com>
>>>>>> Signed-off-by: Sarannya S <quic_sarannya@quicinc.com>
>>>>>> ---
>>>>>>  drivers/rpmsg/rpmsg_core.c     | 21 +++++++++++++++++++++
>>>>>>  drivers/rpmsg/rpmsg_internal.h |  2 ++
>>>>>>  include/linux/rpmsg.h          | 15 +++++++++++++++
>>>>>>  3 files changed, 38 insertions(+)
>>>>>>
>>>>>> diff --git a/drivers/rpmsg/rpmsg_core.c b/drivers/rpmsg/rpmsg_core.c
>>>>>> index a2207c0..e8bbe05 100644
>>>>>> --- a/drivers/rpmsg/rpmsg_core.c
>>>>>> +++ b/drivers/rpmsg/rpmsg_core.c
>>>>>> @@ -331,6 +331,25 @@ int rpmsg_trysend_offchannel(struct rpmsg_endpoint *ept, u32 src, u32 dst,
>>>>>>  EXPORT_SYMBOL(rpmsg_trysend_offchannel);
>>>>>>  
>>>>>>  /**
>>>>>> + * rpmsg_set_flow_control() - sets/clears serial flow control signals
>>>>>> + * @ept:	the rpmsg endpoint
>>>>>> + * @enable:	pause/resume incoming data flow	
>>>>>
>>>>> As shown in the discussion, it's still not clear what true/false means.
>>>>> Also, let's try to clarify that it's a request for the other side to do
>>>>> something:
>>>>>
>>>>> * rpmsg_set_flow_control() - request remote to pause/resume transmission
>>>>> * ...
>>>>> * @enable: flow restricted
>>>>> * ...
>>>>>
>>>>>
>>>>> PS. There's a stray space at the end of the line.
>>>>
>>>> The notion of flow restricted seems to me also ambiguous. It does
>>>> not specify if the stream is limited in term of bandwidth or stopped.
>>>>
>>>> What about using XON/XOFF as specified in software flow control[1]
>>>>
>>>> XOFF	Pause transmission
>>>> XON	Resume transmission
>>>>
>>>> or simply pause/resume definitions
>>>>
>>>
>>> I agree, that's still ambiguous.
>>>
>>> I was concerned about expressing it such that the reader would assume
>>> that calling this means there will be no more data coming, but there
>>> might be things in the queues etc. Expressing it in terms of the state
>>> of transmission is clearer.
>>>
>>>
>>> /*
>>>  * rpmsg_set_flow_control() - request remote to pause/resume transmission
>>>  ...
>>>  * @enable: Pause transmission
>>>  ...
>>>  */
>>>
>>> Does that sound okay and clear to you?
>>
>> Much better! I still have a nitpicking point :)
>> What about replacing @enable variable by @pause to align the variable with the
>> usage?
>>  /*
>>   * rpmsg_set_flow_control() - request remote to pause/resume transmission
>>   ...
>>   * @pause: set to 1 to pause transmission, to 0 to resume the transmission
> 
> It's a boolean, so I think with your name change suggestion, together
> with the function description, it should be clear enough what the two
> states (true/false) means.
> 
> * @pause: Pause transmission

Ok for me

Thanks,
Arnaud

> 
> Thanks,
> Bjorn