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

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

[Sarannya S]

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>
---
 arch/arm64/configs/defconfig   |  2 ++
 drivers/rpmsg/rpmsg_core.c     | 20 ++++++++++++++++++++
 drivers/rpmsg/rpmsg_internal.h |  2 ++
 include/linux/rpmsg.h          | 15 +++++++++++++++
 4 files changed, 39 insertions(+)

diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index 0b6af33..2df3778 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -26,6 +26,8 @@ CONFIG_CGROUP_CPUACCT=y
 CONFIG_CGROUP_PERF=y
 CONFIG_CGROUP_BPF=y
 CONFIG_USER_NS=y
+CONFIG_RPMSG=y
+CONFIG_RPMSG_CHAR=y
 CONFIG_SCHED_AUTOGROUP=y
 CONFIG_BLK_DEV_INITRD=y
 CONFIG_KALLSYMS_ALL=y
diff --git a/drivers/rpmsg/rpmsg_core.c b/drivers/rpmsg/rpmsg_core.c
index d6dde00e..0c5bf67 100644
--- a/drivers/rpmsg/rpmsg_core.c
+++ b/drivers/rpmsg/rpmsg_core.c
@@ -331,6 +331,24 @@ 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:	enable or disable serial flow control
+ *
+ * Return: 0 on success and an appropriate error value on failure.
+ */
+int rpmsg_set_flow_control(struct rpmsg_endpoint *ept, bool enable)
+{
+	if (WARN_ON(!ept))
+		return -EINVAL;
+	if (!ept->ops->set_flow_control)
+		return -ENXIO;
+
+	return ept->ops->set_flow_control(ept, enable);
+}
+EXPORT_SYMBOL(rpmsg_set_flow_control);
+
+/**
  * rpmsg_get_mtu() - get maximum transmission buffer size for sending message.
  * @ept: the rpmsg endpoint
  *
@@ -539,6 +557,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..4fea45a 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);
 	ssize_t (*get_mtu)(struct rpmsg_endpoint *ept);
 };
 
diff --git a/include/linux/rpmsg.h b/include/linux/rpmsg.h
index 523c98b..cc7a917 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);
+
 #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)
+{
+	/* 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 V4 2/3] rpmsg: glink: Add support to handle signals command

[Sarannya S]

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 | 63 +++++++++++++++++++++++++++++++++++++++
 1 file changed, 63 insertions(+)

diff --git a/drivers/rpmsg/qcom_glink_native.c b/drivers/rpmsg/qcom_glink_native.c
index 115c0a1..01d0a49 100644
--- a/drivers/rpmsg/qcom_glink_native.c
+++ b/drivers/rpmsg/qcom_glink_native.c
@@ -17,6 +17,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>
 
@@ -203,9 +204,15 @@ static const struct rpmsg_endpoint_ops glink_endpoint_ops;
 #define RPM_CMD_TX_DATA_CONT		12
 #define RPM_CMD_READ_NOTIF		13
 #define RPM_CMD_RX_DONE_W_REUSE		14
+#define RPM_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,
@@ -1001,6 +1008,57 @@ 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
+ *
+ * Return: 0 on success or standard Linux error code.
+ */
+static int qcom_glink_set_flow_control(struct rpmsg_endpoint *ept, bool enable)
+{
+	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(RPM_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;
+}
+
 static irqreturn_t qcom_glink_native_intr(int irq, void *data)
 {
 	struct qcom_glink *glink = data;
@@ -1065,6 +1123,10 @@ static irqreturn_t qcom_glink_native_intr(int irq, void *data)
 			qcom_glink_handle_intent_req_ack(glink, param1, param2);
 			qcom_glink_rx_advance(glink, ALIGN(sizeof(msg), 8));
 			break;
+		case RPM_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;
@@ -1440,6 +1502,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 V4 3/3] rpmsg: char: Add TIOCMGET/TIOCMSET ioctl support

[Sarannya S]

Add TICOMGET and TIOCMSET 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 | 60 +++++++++++++++++++++++++++++++++++++++-------
 1 file changed, 52 insertions(+), 8 deletions(-)

diff --git a/drivers/rpmsg/rpmsg_char.c b/drivers/rpmsg/rpmsg_char.c
index 3e0b8f3..d44c8a6 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;
 
+	u32 remote_signals;
+	bool signals_pending;
 };
 
 int rpmsg_chrdev_eptdev_destroy(struct device *dev, void *data)
@@ -109,7 +112,22 @@ static int rpmsg_ept_cb(struct rpmsg_device *rpdev, void *buf, int len,
 	skb_queue_tail(&eptdev->queue, skb);
 	spin_unlock(&eptdev->queue_lock);
 
-	/* wake up any blocking processes, waiting for new data */
+	wake_up_interruptible(&eptdev->readq);
+
+	return 0;
+}
+
+static int rpmsg_ept_flow_cb(struct rpmsg_device *rpdev, void *priv, bool enable)
+{
+	struct rpmsg_eptdev *eptdev = priv;
+
+	if (enable)
+		eptdev->remote_signals = TIOCM_DSR | TIOCM_CTS;
+	else
+		eptdev->remote_signals = 0;
+	
+	eptdev->signals_pending = true;
+
 	wake_up_interruptible(&eptdev->readq);
 
 	return 0;
@@ -146,6 +164,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);
@@ -166,6 +185,7 @@ static int rpmsg_eptdev_release(struct inode *inode, struct file *filp)
 		eptdev->ept = NULL;
 	}
 	mutex_unlock(&eptdev->ept_lock);
+	eptdev->signals_pending = false;
 
 	/* Discard all SKBs */
 	skb_queue_purge(&eptdev->queue);
@@ -279,6 +299,9 @@ static __poll_t rpmsg_eptdev_poll(struct file *filp, poll_table *wait)
 	if (!skb_queue_empty(&eptdev->queue))
 		mask |= EPOLLIN | EPOLLRDNORM;
 
+	if (eptdev->signals_pending)
+		mask |= EPOLLPRI;
+
 	mask |= rpmsg_poll(eptdev->ept, filp, wait);
 
 	return mask;
@@ -289,14 +312,35 @@ 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;
-
-	/* Don't allow to destroy a default endpoint. */
-	if (eptdev->default_ept)
-		return -EINVAL;
+	bool set;
+	u32 val;
+	int ret;
+	
+	switch (cmd) {
+	case TIOCMGET:
+		eptdev->signals_pending = false;
+		ret = put_user(eptdev->remote_signals, (int __user *)arg);
+		break;
+	case TIOCMSET:
+		ret = get_user(val, (int __user *)arg);
+		if (ret)
+			break;
+		set = (val & (TIOCM_DTR | TIOCM_RTS)) ? true : false;
+		ret = rpmsg_set_flow_control(eptdev->ept, set);
+		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 = {
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

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

[Krzysztof Kozlowski]

On 28/11/2022 14:28, Sarannya S wrote:
> 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>
> ---
>  arch/arm64/configs/defconfig   |  2 ++

Thank you for your patch. There is something to discuss/improve.

defconfig changes are not related with code, please keep separate with
their own explanation.

>  drivers/rpmsg/rpmsg_core.c     | 20 ++++++++++++++++++++
>  drivers/rpmsg/rpmsg_internal.h |  2 ++
>  include/linux/rpmsg.h          | 15 +++++++++++++++
>  4 files changed, 39 insertions(+)
> 
> diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
> index 0b6af33..2df3778 100644
> --- a/arch/arm64/configs/defconfig
> +++ b/arch/arm64/configs/defconfig
> @@ -26,6 +26,8 @@ CONFIG_CGROUP_CPUACCT=y
>  CONFIG_CGROUP_PERF=y
>  CONFIG_CGROUP_BPF=y
>  CONFIG_USER_NS=y
> +CONFIG_RPMSG=y
> +CONFIG_RPMSG_CHAR=y

Why? It is already =m
I don't think this is correct patch hunk...

Best regards,
Krzysztof

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

[Krzysztof Kozlowski]

On 28/11/2022 14:32, Krzysztof Kozlowski wrote:
> On 28/11/2022 14:28, Sarannya S wrote:
>> 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>
>> ---

One more problem - SoB does not match From field, so DCO chain is broken
here.

Best regards,
Krzysztof

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

[Mathieu Poirier]

Please send another revision with a proper cover letter that details
the changes made between the last version.

On Mon, 28 Nov 2022 at 06:28, Sarannya S <quic_sarannya@quicinc.com> wrote:
>
> 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>
> ---
>  arch/arm64/configs/defconfig   |  2 ++
>  drivers/rpmsg/rpmsg_core.c     | 20 ++++++++++++++++++++
>  drivers/rpmsg/rpmsg_internal.h |  2 ++
>  include/linux/rpmsg.h          | 15 +++++++++++++++
>  4 files changed, 39 insertions(+)
>
> diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
> index 0b6af33..2df3778 100644
> --- a/arch/arm64/configs/defconfig
> +++ b/arch/arm64/configs/defconfig
> @@ -26,6 +26,8 @@ CONFIG_CGROUP_CPUACCT=y
>  CONFIG_CGROUP_PERF=y
>  CONFIG_CGROUP_BPF=y
>  CONFIG_USER_NS=y
> +CONFIG_RPMSG=y
> +CONFIG_RPMSG_CHAR=y
>  CONFIG_SCHED_AUTOGROUP=y
>  CONFIG_BLK_DEV_INITRD=y
>  CONFIG_KALLSYMS_ALL=y
> diff --git a/drivers/rpmsg/rpmsg_core.c b/drivers/rpmsg/rpmsg_core.c
> index d6dde00e..0c5bf67 100644
> --- a/drivers/rpmsg/rpmsg_core.c
> +++ b/drivers/rpmsg/rpmsg_core.c
> @@ -331,6 +331,24 @@ 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:    enable or disable serial flow control
> + *
> + * Return: 0 on success and an appropriate error value on failure.
> + */
> +int rpmsg_set_flow_control(struct rpmsg_endpoint *ept, bool enable)
> +{
> +       if (WARN_ON(!ept))
> +               return -EINVAL;
> +       if (!ept->ops->set_flow_control)
> +               return -ENXIO;
> +
> +       return ept->ops->set_flow_control(ept, enable);
> +}
> +EXPORT_SYMBOL(rpmsg_set_flow_control);
> +
> +/**
>   * rpmsg_get_mtu() - get maximum transmission buffer size for sending message.
>   * @ept: the rpmsg endpoint
>   *
> @@ -539,6 +557,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..4fea45a 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);
>         ssize_t (*get_mtu)(struct rpmsg_endpoint *ept);
>  };
>
> diff --git a/include/linux/rpmsg.h b/include/linux/rpmsg.h
> index 523c98b..cc7a917 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);
> +
>  #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)
> +{
> +       /* 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 V4 1/3] rpmsg: core: Add signal API support

[Arnaud POULIQUEN]

On 1/4/23 17:30, Bjorn Andersson wrote:
> On Tue, Jan 03, 2023 at 02:50:13PM +0100, Arnaud POULIQUEN wrote:
>> Hello,
>>
>> On 12/27/22 16:32, Bjorn Andersson wrote:
>>> On Wed, Dec 21, 2022 at 05:12:22PM +0100, Arnaud POULIQUEN wrote:
>>>> Hello,
>>>>
>>>> On 12/7/22 14:04, Sarannya S wrote:
>>>>> 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 d6dde00e..77aeba0 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:	enable or disable serial flow control
>>>>
>>>> What does it mean "enable and disable serial flow control"?
>>>> Do you speak about the flow control feature or the data flow itself?
>>>>
>>>
>>> Good point, the purpose of the boolean is to "request throttling of the
>>> incoming data flow".
>>>
>>>> I guess it is the activation/deactivation of the data stream
>>>> regarding Bjorn's comment in V1:
>>>>
>>>> "I therefore asked Deepak to change it so the rpmsg api would contain a
>>>> single "pause incoming data"/"resume incoming data" - given that this is
>>>> a wish that we've seen in a number of discussions."
>>>>
>>>> For me this is the software flow control:
>>>> https://en.wikipedia.org/wiki/Software_flow_control
>>>>
>>>> I would suggest not limiting the control only to activation/deactivation but to
>>>> offer more flexibility in terms of services. replace the boolean by a bitmap
>>>> would allow to extend it later.
>>>>
>>>> For instance by introducing 2 definitions:
>>>>
>>>> /* RPMSG pause transmission request:
>>>>  * sent to the remote endpoint to request to suspend its transmission */
>>>>  */
>>>> #define RPMSG_FC_PT_REQ  (1 << 0)
>>>
>>> enable = true
>>>
>>>>
>>>> /* RPMSG resume transmission request
>>>>  * sent to the remote endpoint to allow to resume its transmission
>>>>  */
>>>> #define RPMSG_FC_RT_REQ  (1 << 1)
>>>>
>>>
>>> enable = false
>>
>> Do you mean that it should be only one definition? If yes you are right
>> only one definition is sufficient for the pause/resume
>>
> 
> Yes, I envision this being used for cases such as rpmsg_char being able
> to send a "I already have 1MB of data in my sk_buf_head queue, please
> don't send me any more data for now".
> 
>>>
>>>> Then we could add (in a next step) some other flow controls such as
>>>> /* RPMSG pause transmission information
>>>>  * Sent to the remote endpoint to inform that no more data will be sent
>>>>  * until the reception of RPMSG_FC_RT_INFO
>>>>  */
>>>> #define RPMSG_FC_PT_INFO  (1 << 16)
>>>> #define RPMSG_FC_RT_INFO  (1 << 16)
>>>>
>>>
>>> I presume you're looking for a usage pattern where the client would send
>>> this to the remote and then the flow control mechanism would be used for
>>> the remote end to request more data.
>>>
>>> I find Deepak's (adjusted) proposal to be generic and to the point, and
>>> your proposal builds unnecessary "flexibility" into this same mechanism.
>>>
>>> If you have a rpmsg protocol where the client is expected to sit
>>> waiting, and upon a request from the remote side send another piece of
>>> data, why don't you just build this into the application protocol?  That
>>> way your application would work over both transports with and without
>>> flow control...
>>>
>>>
>>> Perhaps I'm misunderstanding what you're asking for?
>>
>> With the RPMSG_FC_PT_INFO example I had in mind the possibility to implement PM
>> runtime.
>>
> 
> Which device/part are you going to runtime PM suspend using this?

I have not concrete device yet to show. For now I more in the step of figuring
out what would be the use of flow control. I can see 2 use cases:
- management of the congestion in reception
- management of the transmission pause/resume

This implementation implements only the congestion or mix both in one.
And both seem to me flow control that have to be implemented at service level.

For instance, if we have a request-answer communication from the main processor
to the remoteproc processor with some delay constraint. The management of the
pause resume transmission ( on PM or system suspend) can be used to inform the
coprocessor that the main processor suspend the communication and will not send
request. This information can be used by the coprocessor for some power
management optimizations.


> 
>> But my main point here is to allow to extend the flow control in future.
>> or instance an comment in OpenAMP PR part [1] was:
>>
>> "ON/OFF info isn't enough in the advanced flow control since the additional info
>> is required(e.g. the slide window, round trip delay, congestion etc..)."
>>
>> [1]https://github.com/OpenAMP/open-amp/pull/394#discussion_r878363627
> 
> We don't have a way to apply back pressure today, so I have a hard time
> imagining the use cases and the implementation of such advanced flow
> control.
> 
> Reading your proposal again, I don't think that's flow control, that's a
> mechanism for requesting notifications. Either way, the mechanism seems
> orthogonal to rpmsg_set_flow_control() - even if they were implemented
> using the same mechanism in the underlying transport.
> 
>>
>> Using a @enable boolean would imply to create new ops if someone want to extend
>> the flow control (to keep legacy compatibility). Using a bit map for the
>> parameter could ease a future extension.
>>
> 
> This is a kernel-internal API, a boolean "flow or now flow" is
> sufficient for what Qualcomm is asking and the ioctl is the only new
> external mechanism introduced.
> 
> I have no concerns extending or altering this as the use cases appear.

Hoping that extension does not impact the IPC implemented for the signaling.

For the virtio rpmsg, (with an implementation based on a rpmsg channel or rpmsg
header flags) it will probably be more sustainable to not use boolean. But as
you mention it should be addressed in rpmsg_virtio backend.

So let's forget my suggestion.

Thanks,
Arnaud


> 
> Regards,
> Bjorn

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

[Bjorn Andersson]

On Tue, Jan 03, 2023 at 02:50:13PM +0100, Arnaud POULIQUEN wrote:
> Hello,
> 
> On 12/27/22 16:32, Bjorn Andersson wrote:
> > On Wed, Dec 21, 2022 at 05:12:22PM +0100, Arnaud POULIQUEN wrote:
> >> Hello,
> >>
> >> On 12/7/22 14:04, Sarannya S wrote:
> >>> 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 d6dde00e..77aeba0 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:	enable or disable serial flow control
> >>
> >> What does it mean "enable and disable serial flow control"?
> >> Do you speak about the flow control feature or the data flow itself?
> >>
> > 
> > Good point, the purpose of the boolean is to "request throttling of the
> > incoming data flow".
> > 
> >> I guess it is the activation/deactivation of the data stream
> >> regarding Bjorn's comment in V1:
> >>
> >> "I therefore asked Deepak to change it so the rpmsg api would contain a
> >> single "pause incoming data"/"resume incoming data" - given that this is
> >> a wish that we've seen in a number of discussions."
> >>
> >> For me this is the software flow control:
> >> https://en.wikipedia.org/wiki/Software_flow_control
> >>
> >> I would suggest not limiting the control only to activation/deactivation but to
> >> offer more flexibility in terms of services. replace the boolean by a bitmap
> >> would allow to extend it later.
> >>
> >> For instance by introducing 2 definitions:
> >>
> >> /* RPMSG pause transmission request:
> >>  * sent to the remote endpoint to request to suspend its transmission */
> >>  */
> >> #define RPMSG_FC_PT_REQ  (1 << 0)
> > 
> > enable = true
> > 
> >>
> >> /* RPMSG resume transmission request
> >>  * sent to the remote endpoint to allow to resume its transmission
> >>  */
> >> #define RPMSG_FC_RT_REQ  (1 << 1)
> >>
> > 
> > enable = false
> 
> Do you mean that it should be only one definition? If yes you are right
> only one definition is sufficient for the pause/resume
> 

Yes, I envision this being used for cases such as rpmsg_char being able
to send a "I already have 1MB of data in my sk_buf_head queue, please
don't send me any more data for now".

> > 
> >> Then we could add (in a next step) some other flow controls such as
> >> /* RPMSG pause transmission information
> >>  * Sent to the remote endpoint to inform that no more data will be sent
> >>  * until the reception of RPMSG_FC_RT_INFO
> >>  */
> >> #define RPMSG_FC_PT_INFO  (1 << 16)
> >> #define RPMSG_FC_RT_INFO  (1 << 16)
> >>
> > 
> > I presume you're looking for a usage pattern where the client would send
> > this to the remote and then the flow control mechanism would be used for
> > the remote end to request more data.
> > 
> > I find Deepak's (adjusted) proposal to be generic and to the point, and
> > your proposal builds unnecessary "flexibility" into this same mechanism.
> > 
> > If you have a rpmsg protocol where the client is expected to sit
> > waiting, and upon a request from the remote side send another piece of
> > data, why don't you just build this into the application protocol?  That
> > way your application would work over both transports with and without
> > flow control...
> > 
> > 
> > Perhaps I'm misunderstanding what you're asking for?
> 
> With the RPMSG_FC_PT_INFO example I had in mind the possibility to implement PM
> runtime.
> 

Which device/part are you going to runtime PM suspend using this?

> But my main point here is to allow to extend the flow control in future.
> or instance an comment in OpenAMP PR part [1] was:
> 
> "ON/OFF info isn't enough in the advanced flow control since the additional info
> is required(e.g. the slide window, round trip delay, congestion etc..)."
> 
> [1]https://github.com/OpenAMP/open-amp/pull/394#discussion_r878363627

We don't have a way to apply back pressure today, so I have a hard time
imagining the use cases and the implementation of such advanced flow
control.

Reading your proposal again, I don't think that's flow control, that's a
mechanism for requesting notifications. Either way, the mechanism seems
orthogonal to rpmsg_set_flow_control() - even if they were implemented
using the same mechanism in the underlying transport.

> 
> Using a @enable boolean would imply to create new ops if someone want to extend
> the flow control (to keep legacy compatibility). Using a bit map for the
> parameter could ease a future extension.
> 

This is a kernel-internal API, a boolean "flow or now flow" is
sufficient for what Qualcomm is asking and the ioctl is the only new
external mechanism introduced.

I have no concerns extending or altering this as the use cases appear.

Regards,
Bjorn

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

[Arnaud POULIQUEN]

Hello,

On 12/27/22 16:32, Bjorn Andersson wrote:
> On Wed, Dec 21, 2022 at 05:12:22PM +0100, Arnaud POULIQUEN wrote:
>> Hello,
>>
>> On 12/7/22 14:04, Sarannya S wrote:
>>> 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 d6dde00e..77aeba0 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:	enable or disable serial flow control
>>
>> What does it mean "enable and disable serial flow control"?
>> Do you speak about the flow control feature or the data flow itself?
>>
> 
> Good point, the purpose of the boolean is to "request throttling of the
> incoming data flow".
> 
>> I guess it is the activation/deactivation of the data stream
>> regarding Bjorn's comment in V1:
>>
>> "I therefore asked Deepak to change it so the rpmsg api would contain a
>> single "pause incoming data"/"resume incoming data" - given that this is
>> a wish that we've seen in a number of discussions."
>>
>> For me this is the software flow control:
>> https://en.wikipedia.org/wiki/Software_flow_control
>>
>> I would suggest not limiting the control only to activation/deactivation but to
>> offer more flexibility in terms of services. replace the boolean by a bitmap
>> would allow to extend it later.
>>
>> For instance by introducing 2 definitions:
>>
>> /* RPMSG pause transmission request:
>>  * sent to the remote endpoint to request to suspend its transmission */
>>  */
>> #define RPMSG_FC_PT_REQ  (1 << 0)
> 
> enable = true
> 
>>
>> /* RPMSG resume transmission request
>>  * sent to the remote endpoint to allow to resume its transmission
>>  */
>> #define RPMSG_FC_RT_REQ  (1 << 1)
>>
> 
> enable = false

Do you mean that it should be only one definition? If yes you are right
only one definition is sufficient for the pause/resume

> 
>> Then we could add (in a next step) some other flow controls such as
>> /* RPMSG pause transmission information
>>  * Sent to the remote endpoint to inform that no more data will be sent
>>  * until the reception of RPMSG_FC_RT_INFO
>>  */
>> #define RPMSG_FC_PT_INFO  (1 << 16)
>> #define RPMSG_FC_RT_INFO  (1 << 16)
>>
> 
> I presume you're looking for a usage pattern where the client would send
> this to the remote and then the flow control mechanism would be used for
> the remote end to request more data.
> 
> I find Deepak's (adjusted) proposal to be generic and to the point, and
> your proposal builds unnecessary "flexibility" into this same mechanism.
> 
> If you have a rpmsg protocol where the client is expected to sit
> waiting, and upon a request from the remote side send another piece of
> data, why don't you just build this into the application protocol?  That
> way your application would work over both transports with and without
> flow control...
> 
> 
> Perhaps I'm misunderstanding what you're asking for?

With the RPMSG_FC_PT_INFO example I had in mind the possibility to implement PM
runtime.

But my main point here is to allow to extend the flow control in future.
or instance an comment in OpenAMP PR part [1] was:

"ON/OFF info isn't enough in the advanced flow control since the additional info
is required(e.g. the slide window, round trip delay, congestion etc..)."

[1]https://github.com/OpenAMP/open-amp/pull/394#discussion_r878363627

Using a @enable boolean would imply to create new ops if someone want to extend
the flow control (to keep legacy compatibility). Using a bit map for the
parameter could ease a future extension.

Regards,
Arnaud

> 
> Regards,
> Bjorn
> 
>>> + * @dst:	destination address of the endpoint
>>
>> Thanks to have integrated this in your patch!
>>
>> Regards,
>> Arnaud
>>
>>> + *
>>> + * 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(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 */

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

[Bjorn Andersson]

On Wed, Dec 21, 2022 at 05:12:22PM +0100, Arnaud POULIQUEN wrote:
> Hello,
> 
> On 12/7/22 14:04, Sarannya S wrote:
> > 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 d6dde00e..77aeba0 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:	enable or disable serial flow control
> 
> What does it mean "enable and disable serial flow control"?
> Do you speak about the flow control feature or the data flow itself?
> 

Good point, the purpose of the boolean is to "request throttling of the
incoming data flow".

> I guess it is the activation/deactivation of the data stream
> regarding Bjorn's comment in V1:
> 
> "I therefore asked Deepak to change it so the rpmsg api would contain a
> single "pause incoming data"/"resume incoming data" - given that this is
> a wish that we've seen in a number of discussions."
> 
> For me this is the software flow control:
> https://en.wikipedia.org/wiki/Software_flow_control
> 
> I would suggest not limiting the control only to activation/deactivation but to
> offer more flexibility in terms of services. replace the boolean by a bitmap
> would allow to extend it later.
> 
> For instance by introducing 2 definitions:
> 
> /* RPMSG pause transmission request:
>  * sent to the remote endpoint to request to suspend its transmission */
>  */
> #define RPMSG_FC_PT_REQ  (1 << 0)

enable = true

> 
> /* RPMSG resume transmission request
>  * sent to the remote endpoint to allow to resume its transmission
>  */
> #define RPMSG_FC_RT_REQ  (1 << 1)
> 

enable = false

> Then we could add (in a next step) some other flow controls such as
> /* RPMSG pause transmission information
>  * Sent to the remote endpoint to inform that no more data will be sent
>  * until the reception of RPMSG_FC_RT_INFO
>  */
> #define RPMSG_FC_PT_INFO  (1 << 16)
> #define RPMSG_FC_RT_INFO  (1 << 16)
> 

I presume you're looking for a usage pattern where the client would send
this to the remote and then the flow control mechanism would be used for
the remote end to request more data.

I find Deepak's (adjusted) proposal to be generic and to the point, and
your proposal builds unnecessary "flexibility" into this same mechanism.

If you have a rpmsg protocol where the client is expected to sit
waiting, and upon a request from the remote side send another piece of
data, why don't you just build this into the application protocol?  That
way your application would work over both transports with and without
flow control...


Perhaps I'm misunderstanding what you're asking for?

Regards,
Bjorn

> > + * @dst:	destination address of the endpoint
> 
> Thanks to have integrated this in your patch!
> 
> Regards,
> Arnaud
> 
> > + *
> > + * 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(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 */

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

[Arnaud POULIQUEN]

Hello,

On 12/7/22 14:04, Sarannya S wrote:
> 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 d6dde00e..77aeba0 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:	enable or disable serial flow control

What does it mean "enable and disable serial flow control"?
Do you speak about the flow control feature or the data flow itself?

I guess it is the activation/deactivation of the data stream
regarding Bjorn's comment in V1:

"I therefore asked Deepak to change it so the rpmsg api would contain a
single "pause incoming data"/"resume incoming data" - given that this is
a wish that we've seen in a number of discussions."

For me this is the software flow control:
https://en.wikipedia.org/wiki/Software_flow_control

I would suggest not limiting the control only to activation/deactivation but to
offer more flexibility in terms of services. replace the boolean by a bitmap
would allow to extend it later.

For instance by introducing 2 definitions:

/* RPMSG pause transmission request:
 * sent to the remote endpoint to request to suspend its transmission */
 */
#define RPMSG_FC_PT_REQ  (1 << 0)

/* RPMSG resume transmission request
 * sent to the remote endpoint to allow to resume its transmission
 */
#define RPMSG_FC_RT_REQ  (1 << 1)

Then we could add (in a next step) some other flow controls such as
/* RPMSG pause transmission information
 * Sent to the remote endpoint to inform that no more data will be sent
 * until the reception of RPMSG_FC_RT_INFO
 */
#define RPMSG_FC_PT_INFO  (1 << 16)
#define RPMSG_FC_RT_INFO  (1 << 16)

> + * @dst:	destination address of the endpoint

Thanks to have integrated this in your patch!

Regards,
Arnaud

> + *
> + * 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(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 */

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

[Sarannya S]

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 d6dde00e..77aeba0 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:	enable or disable serial flow control
+ * @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(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

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

[Sarannya S]

On 11/30/2022 11:53 PM, Mathieu Poirier wrote:
> On Tue, 29 Nov 2022 at 02:29, Arnaud POULIQUEN
> <arnaud.pouliquen@foss.st.com> wrote:
>>
>> Hi Sarannya,
>>
>> On 11/28/22 19:02, Sarannya S wrote:
>>> 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     | 20 ++++++++++++++++++++
>>>   drivers/rpmsg/rpmsg_internal.h |  2 ++
>>>   include/linux/rpmsg.h          | 15 +++++++++++++++
>>>   3 files changed, 37 insertions(+)
>>>
>>> diff --git a/drivers/rpmsg/rpmsg_core.c b/drivers/rpmsg/rpmsg_core.c
>>> index d6dde00e..0c5bf67 100644
>>> --- a/drivers/rpmsg/rpmsg_core.c
>>> +++ b/drivers/rpmsg/rpmsg_core.c
>>> @@ -331,6 +331,24 @@ 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:  enable or disable serial flow control
>>> + *
>>> + * Return: 0 on success and an appropriate error value on failure.
>>> + */
>>> +int rpmsg_set_flow_control(struct rpmsg_endpoint *ept, bool enable)
>>
>> Seems that you did not take into account comment in your V3 asking you to
>> add the destination address of the endpoint as parameter
> 
> I will not review this patchset until Arnaud's comment is addressed or
> a reason for the omission is provided.
> 
Arnaud, Mathieu,
Sorry, I did not find this comment in V3 patch.
I will update the patch by adding destination address as parameter.

Regards,
Sarannya
>>
>> Regards,
>> Arnaud
>>
>>> +{
>>> +     if (WARN_ON(!ept))
>>> +             return -EINVAL;
>>> +     if (!ept->ops->set_flow_control)
>>> +             return -ENXIO;
>>> +
>>> +     return ept->ops->set_flow_control(ept, enable);
>>> +}
>>> +EXPORT_SYMBOL(rpmsg_set_flow_control);
>>> +
>>> +/**
>>>    * rpmsg_get_mtu() - get maximum transmission buffer size for sending message.
>>>    * @ept: the rpmsg endpoint
>>>    *
>>> @@ -539,6 +557,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..4fea45a 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);
>>>        ssize_t (*get_mtu)(struct rpmsg_endpoint *ept);
>>>   };
>>>
>>> diff --git a/include/linux/rpmsg.h b/include/linux/rpmsg.h
>>> index 523c98b..cc7a917 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);
>>> +
>>>   #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)
>>> +{
>>> +     /* 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 V4 1/3] rpmsg: core: Add signal API support

[Mathieu Poirier]

On Tue, 29 Nov 2022 at 02:29, Arnaud POULIQUEN
<arnaud.pouliquen@foss.st.com> wrote:
>
> Hi Sarannya,
>
> On 11/28/22 19:02, Sarannya S wrote:
> > 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     | 20 ++++++++++++++++++++
> >  drivers/rpmsg/rpmsg_internal.h |  2 ++
> >  include/linux/rpmsg.h          | 15 +++++++++++++++
> >  3 files changed, 37 insertions(+)
> >
> > diff --git a/drivers/rpmsg/rpmsg_core.c b/drivers/rpmsg/rpmsg_core.c
> > index d6dde00e..0c5bf67 100644
> > --- a/drivers/rpmsg/rpmsg_core.c
> > +++ b/drivers/rpmsg/rpmsg_core.c
> > @@ -331,6 +331,24 @@ 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:  enable or disable serial flow control
> > + *
> > + * Return: 0 on success and an appropriate error value on failure.
> > + */
> > +int rpmsg_set_flow_control(struct rpmsg_endpoint *ept, bool enable)
>
> Seems that you did not take into account comment in your V3 asking you to
> add the destination address of the endpoint as parameter

I will not review this patchset until Arnaud's comment is addressed or
a reason for the omission is provided.

>
> Regards,
> Arnaud
>
> > +{
> > +     if (WARN_ON(!ept))
> > +             return -EINVAL;
> > +     if (!ept->ops->set_flow_control)
> > +             return -ENXIO;
> > +
> > +     return ept->ops->set_flow_control(ept, enable);
> > +}
> > +EXPORT_SYMBOL(rpmsg_set_flow_control);
> > +
> > +/**
> >   * rpmsg_get_mtu() - get maximum transmission buffer size for sending message.
> >   * @ept: the rpmsg endpoint
> >   *
> > @@ -539,6 +557,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..4fea45a 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);
> >       ssize_t (*get_mtu)(struct rpmsg_endpoint *ept);
> >  };
> >
> > diff --git a/include/linux/rpmsg.h b/include/linux/rpmsg.h
> > index 523c98b..cc7a917 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);
> > +
> >  #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)
> > +{
> > +     /* 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 V4 1/3] rpmsg: core: Add signal API support

[Arnaud POULIQUEN]

Hi Sarannya,

On 11/28/22 19:02, Sarannya S wrote:
> 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     | 20 ++++++++++++++++++++
>  drivers/rpmsg/rpmsg_internal.h |  2 ++
>  include/linux/rpmsg.h          | 15 +++++++++++++++
>  3 files changed, 37 insertions(+)
> 
> diff --git a/drivers/rpmsg/rpmsg_core.c b/drivers/rpmsg/rpmsg_core.c
> index d6dde00e..0c5bf67 100644
> --- a/drivers/rpmsg/rpmsg_core.c
> +++ b/drivers/rpmsg/rpmsg_core.c
> @@ -331,6 +331,24 @@ 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:	enable or disable serial flow control
> + *
> + * Return: 0 on success and an appropriate error value on failure.
> + */
> +int rpmsg_set_flow_control(struct rpmsg_endpoint *ept, bool enable)

Seems that you did not take into account comment in your V3 asking you to
add the destination address of the endpoint as parameter

Regards,
Arnaud

> +{
> +	if (WARN_ON(!ept))
> +		return -EINVAL;
> +	if (!ept->ops->set_flow_control)
> +		return -ENXIO;
> +
> +	return ept->ops->set_flow_control(ept, enable);
> +}
> +EXPORT_SYMBOL(rpmsg_set_flow_control);
> +
> +/**
>   * rpmsg_get_mtu() - get maximum transmission buffer size for sending message.
>   * @ept: the rpmsg endpoint
>   *
> @@ -539,6 +557,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..4fea45a 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);
>  	ssize_t (*get_mtu)(struct rpmsg_endpoint *ept);
>  };
>  
> diff --git a/include/linux/rpmsg.h b/include/linux/rpmsg.h
> index 523c98b..cc7a917 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);
> +
>  #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)
> +{
> +	/* 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 */

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

[Sarannya S]

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     | 20 ++++++++++++++++++++
 drivers/rpmsg/rpmsg_internal.h |  2 ++
 include/linux/rpmsg.h          | 15 +++++++++++++++
 3 files changed, 37 insertions(+)

diff --git a/drivers/rpmsg/rpmsg_core.c b/drivers/rpmsg/rpmsg_core.c
index d6dde00e..0c5bf67 100644
--- a/drivers/rpmsg/rpmsg_core.c
+++ b/drivers/rpmsg/rpmsg_core.c
@@ -331,6 +331,24 @@ 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:	enable or disable serial flow control
+ *
+ * Return: 0 on success and an appropriate error value on failure.
+ */
+int rpmsg_set_flow_control(struct rpmsg_endpoint *ept, bool enable)
+{
+	if (WARN_ON(!ept))
+		return -EINVAL;
+	if (!ept->ops->set_flow_control)
+		return -ENXIO;
+
+	return ept->ops->set_flow_control(ept, enable);
+}
+EXPORT_SYMBOL(rpmsg_set_flow_control);
+
+/**
  * rpmsg_get_mtu() - get maximum transmission buffer size for sending message.
  * @ept: the rpmsg endpoint
  *
@@ -539,6 +557,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..4fea45a 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);
 	ssize_t (*get_mtu)(struct rpmsg_endpoint *ept);
 };
 
diff --git a/include/linux/rpmsg.h b/include/linux/rpmsg.h
index 523c98b..cc7a917 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);
+
 #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)
+{
+	/* 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